Ean Schuessler <e...@brainfood.com> writes: > What you are avoiding is that the FTP masters or the Technical Committee > *is* option D in your scheme. They are the final arbitrators of DFSG > compliance.
I see nothing in the constitution that empowers the TC to rule on licensing issues except when they're explicitly delegated to the TC. Licensing issues are clearly (at least in my view) not technical; they're legal. Likewise, interpreting the DFSG is clearly not a technical action or judgement. I therefore also don't believe the TC could overrule the ftp-masters on licensing calls. It would need to be done via GR. I do agree that to some extent the ftp-masters currently are the final arbitrators of DFSG compliance, but they're not constitutionally empowered to be that. They're doing that in the course of their work on Debian. This is relevant because it means that they have no particular power to overrule the release team and hence aren't entirely final arbitrators in the sense of settling a question for the entire project. They can do that negatively (by refusing to accept something into the archive) but not positively (saying that it's definitely free). > As we've seen, that scheme has led to friction during the last few > release cycles. I don't believe the scheme is the cause of the friction. I think the cause of the friction is aptly illustrated by the outcome of every vote that we've had on this topic: we have an approximate majority in favor of kicking the can down the road for each release, but we do not have a project consensus on the correct action and we do not have a 3:1 majority in either direction. In other words, the project is split. So we have friction. I doubt there are procedural changes that will remove the friction as long as the project remains split. The most that we can do is control the effects of the tension and not have it explode in ways that make Debian less fun for everyone, such as the huge fight over the last firmware vote. > At the same time, you yourself note your disatisfaction with the > firmware decision. I am suggesting that we must lower the pain > threshhold on marking software non-free so that we can correctly > classify bytes we are distributing without it becoming an all out war. Which requires someone go actually do work. I'm all in favor of people doing work. :) I personally don't have time to work on this given all the other stuff I'm currently doing for Debian, and I expect that's the case for a lot of people in this discussion. Saying "we should improve our technical capabilities here" is, while almost certainly true, not horribly helpful unless you're also able to go do that. In this case, this seems to be happening over time. Hopefully eventually the people who have time to do work will make these discussions thankfully moot. However, I will note... > If there is *any* serious doubt about the compliance of a piece of > software then we must be able to mark it non-free without it being the > end of the world. ...that this really seems contrary to the social contract to me. non-free is intended to *not be Debian*, and this is realistically going to have consequences. It *should* have consequences, or otherwise why are we saying non-free isn't part of Debian? In other words, if non-free is just another archive section, why do we have this whole distinction? And while we're maintaining this distinction, I think it's clear that moving something into non-free is never going to be an action people are willing to take lightly. Since, after all, that means, in the words of the social contract, the software is being removed from Debian. > Please, acknowledge that what you are suggesting by "option B" would be > more clearly labeled as "FTP masters and/or Technical Committee are the > final authority for DFSG compliance" with a corrollary that "it is > acceptable to leave non-free binaries in main on an ongoing basis if > authorized by TC/FTP". As above, I don't believe that's what option B means. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org