On Sun, Feb 23, 2014 at 06:24:12PM +0100, Markus Koschany wrote: > However it seems both of you interpret the result differently. I should > mention that the vote failed (you seem to be under the impression that > it succeeded) and option 2 "Further discussion" was chosen. Oh, right! I did check, but I must have overlooked that. Thanks for pointing it out. In that case, we're still at "whatever the maintainer thinks is right". That doesn't really make much difference, I think, because policy and the SC talk about "software", and opinions vary about whether or not artwork is software. > Apparently we haven't found this consensus yet. I think we aren't too far off either. Do you have a clear idea about which points we still disagree on? > However speaking with one voice could allow us to appear more united > in front of bug reporters, invisible rules would become more > transparent to outsiders and it would help new contributors to find > the right and wrongs for maintaining games packages more quickly. Yes. And if a team like ours states its position, that may also help to form consensus in all of Debian. > > I agree that we should be consistent. But that doesn't mean > > automatically throwing everything in main. It means making a decision, > > and possibly removing those other things from main. > > I don't intend to to make everything equal. Not all packages are wrongly > in contrib or non-free. Obviously. > But free engines and interpreters should whenever possible be part of > main because with a little bit of imagination you can add useful > documentation or content to them and give them a reason to exist in > main. That depends on the engine. If there is a free editor[1], the engine should go in main even without free content; in that case it is reasonable to say that people may want to use the editor to create things, and the engine to use their creations. If there is no free editor, and there is no free content, IMO the engine belongs in contrib. It then fits perfectly with Policy's definition of "The Recommends field should list packages that would be found together with this one in all but unusual installations." So it should have a Recommends relation with a non-free package (editor, content, or both), which makes it contrib. Also, your description "you can add useful ... content to them" is not true if there is no editor. (I removed the documentation, because an engine without an editor and content is useless, no matter how documented). If there is free content, but no editor, like with ScummVM (AFAIK), it can go into main: it is free, and is usable with only other things from main. So the only debatable part is whether content that cannot be edited in a reasonable way can be considered DFSG-free. If not, then those games should not be in main, and if they aren't, and there isn't an editor, ScummVM itself doesn't belong there either. Thanks, Bas [1] An engine that uses a format that can be edited with general purpose programs like text and image editors obviously always has an editor. Therefore, if there would be a compiler for Scumm games which turns text files and regular graphics/sound files into a format it understands, I think that would also be enough. I wouldn't be surprised if such a compiler exists. And a decomiler as well. That would be nice; it would allow people to edit those free-without-source games.
Attachment:
signature.asc
Description: Digital signature