On Wed, 19. Feb 17:59 Simon McVittie <smcv@debian.org> wrote: [...] > > I fail to understand why software like residualvm has to stay in > > contrib although the program is free and fully functional just > > because there is no current input for it. > > Packages that can be characterized as "interpreter/viewer for content > in a highly specialized format" are in a bit of a grey area. In > descending order of "main-ness": I think the whole point of classifying is not helpful. I know you put main-ness in quotation marks but the words grey area, main-ness and your examples describe the current situation appropriately. In my opinion the interpreter is either free software or not. The affiliation of a package to main or contrib is often not decided by its license or if it can be compiled or executed without non-free software but it is often a matter of subjective and arbitrary beliefs of single individuals and those are error-prone. I think there is a great opportunity as a team to make a decision and to decide that we would like to see free software in main and that we are willing to defend that decision. Residualvm was once part of main. So it got approved by the ftp-masters but it was moved to contrib because of https://bugs.debian.org/705702. Again the reason was the "to function"-clause. You could easily argue against the submitter's claims. The software functions, it just needs input. In fact that means residualvm will get less attention by fellow contributors and users and no security support for no good reason. What do we gain by making this interpreter a second-class citizen? Why do we ship scottfree in main? My main concern is that we act not consistently. That leads to the strange situation where neither maintainers nor users care about the distinction between main or contrib anymore. "Just enable contrib, it's free anyway". I believe we could simplify and improve the current situation by being more consistent, by moving packages from contrib to main which abide by the most important rule: free license, does not need non-free software for compilation and execution. Just the grey area remains: What does to function mean? Nobody expects ioquake3 to be a game, it's an engine. That's because the documentation is sufficient, so that everyone is able to understand it. The same should apply to other pieces of software. ioquake3 is an outstanding game engine. Even without OpenArena it would be a great piece of software to study but this should happen in main, in the Debian distribution. What is source in regard to artwork? ==================================== Here I see the same inconsistencies across all games packages in Debian. The same rules that are deemed appropriate for Red Eclipse are not applied to all games in the archive. I can give you countless examples where upstream prefers lossless png or even bmp files as the preferred form of modification. How do you know that all artwork in OpenArena is accompanied by the preferred form of modification? It's probably because you trust those authors because there is no way for you to tell whether the artwork in the source tarball is really intended to be the preferred form of modification unless you have talked to them and know their intentions. Instead of excluding users from free artwork (again non-free is not part of Debian), I suggest we promote outstanding games that provide blend or xcf files. You could easily create a metapackage with Blends to achieve that. We could also create a front page / web site that highlights excellent free software games in the archive. Moving redeclipse-data to non-free, although it is free and it could help someone in Debian, is counter-productive in my opinion and does not serve anybody. Markus
Attachment:
signature.asc
Description: Digital signature