On Mon, Mar 10, 2014 at 07:38:10AM +0000, Jonathan Dowland wrote: > On Mon, Mar 10, 2014 at 04:12:50AM +0100, Bas Wijnen wrote: > > Yes, this is the discussion. Or more accurately, what we want the > > rules to be. > > Do we hold off uploading anything until we've determined consensus? I wouldn't think so. Until we decide on something, there's no reason to stall anything. However, in the case of Red Eclipse, I think it would be good to ask ftpmasters whether they think it is acceptable for main before uploading it there. While sneaking it past them might work, that's not the way to go. > Should the team be polled, perhaps, to see what consensus is, or are we > relying on rough consensus based on participation in this mailing list > thread (in which case, we should be careful about subjects) My mail was intended to be such a poll. I agree about the subject; I've changed it. If you (or anyone else) feels a different action is appropriate, of course you're free to propose (or do, if possible) that. On Mon, Mar 10, 2014 at 12:03:15PM +0000, Jonathan Dowland wrote: > On Mon, Mar 10, 2014 at 07:38:10AM +0000, Jonathan Dowland wrote: > > > * A file is editable if every aspect of it can be reasonably edited > > > using only programs from main. > > > > For the record, I object to this point. > > Just to expand on this point a bit, I object for two reasons: firstly, > main is not and will never be a comprehensive collection of F/OSS and so > this is not a reasonable approximation of "can be edited with DFSG-free > software". I see no difference with code here. We require all compilers not just to be free, but to be in main, even if they are not used during the package build. The reason is that we want users not only to have the theoretical freedom to recompile their code, but also the practical ability to do this. Debian is meant to be a closed system in that sense: you shouldn't need anything outside it to benefit from all the good things we try to provide, including the freedoms. Things which are themselves free, but need non-Debian things (which may or may not be free) to compile or function, are placed in contrib. They may not be any less free, but they can't go in main. > It's even a smidgin arrogant. This statement surprises me. It suggests that you feel that a package being accepted in main is some sort of certification about its freeness. Well, it is, of course. But why is it arrogant to say that to deserve this certificate, the software needs to be editable on a (pure) Debian system? Is it unfair to say that "giving us the right to edit isn't enough, we want the ability as well"? It means that if you have data in a format which requires a special editor, you need to package that editor if you want the data to be in main. Which is no different from code: if you have source in a format which requires a special compiler, you need to package that compiler if you want that code to be in main. Note that I'm not arguing that "the editor that upstream prefers to use" must be in main. It is well possible to create free works with a non-free editor. But the freedom to edit is only useful if you have an editor. It doesn't need to be the one upstream uses, but it must exist, and be free, and in Debian (main). > Secondly: where no DFSG-free editor is available for a primary source, > I do not believe that the good will of a content creator should be > ignored (really, rejected), and their contribution not considered > open. Note that contrib is meant for free packages. As policy 2.2.2 gives an example for what goes into contrib: > free packages which require contrib, non-free packages or packages > which are not in our archive at all for compilation or execution Data which was generated (or "compiled") totally fits this definition. Even if it was compiled by hand in an editor. But if upstream feels hurt that we don't consider their data free, because we aren't able to edit it, then that's a good thing! Hopefully it convinces them to use a different format. You are not suggesting that games which require Adobe Flash or Microsoft Silverlight to run are acceptable, right? Even if they are licensed under a free license? No, if people want their things in Debian, they have to choose formats (programming language, and data formats) that we accept. And something we can't edit, compile, or run, is not acceptable. > It's an opportunity for the community to step up and provide > such an editor. Yes. Or if it exists, to package it. Which is exactly what I hope people will do if they want to package a game with data that cannot be edited. Just as there is no disagreement (right?) that they need to do that to get code into main when the compiler is not packaged yet. > By my estimation, if this were amongst the criterion we used for our own > packages, freedoom would need removing from Debian at least (nothing in > main can edit the level component of .wad files. I would agree with that. However, instead of removing it, I would prefer to package an editor. > *"yadex" is one F/OSS level editor that used to be in Debian and > Darren Salt maintains outside of the archive. "WadC" is a F/OSS level > generator (can't edit existing levels) also not in the archive.); Given that these programs exist, and are even packaged, what's stopping us from adding them to main? I'm not proposing to remove everything from main and then try to get it back in. I'm proposing to make this a reason for an RC bug, which should be fixed by packaging the editor. And to preempt complaints that I'm telling other people to do work they didn't agree to: yes, I am telling them (us ;-) ) they need to do work, but they did agree to it IMO. Making sure build dependencies are in main is part of the job of a package maintainer. Thanks, Bas
Attachment:
signature.asc
Description: Digital signature