On Wed, Dec 17, 2008 at 02:46:35PM -0600, Manoj Srivastava wrote: > > * Why does releasing despite DFSG violations require a 3:1 majority now > > when it didn't for etch? It's the same secretary in both cases. What > > changed? I didn't find any of the explanations offered for this very > > satisfying.
> The proposal we used before is choice 5 in the current > ballot, and that does indeed have a 1:1 majority like we did > before. The devil lies in the details (and I have explained the details > before too) -- which is that we state that the fiormware blob be > released under a DFSG free licence. This means we explictly conform to > the DFSG, While I accept that this was your understanding as a seconder of the etch GR and proposer of choice 5 on the current GR, this was definitely *not* how I understood the etch GR, either as a seconder or as RM for etch, because the language quite distinctly refers to DFSG-compliance of the license and not of the software. This language was no accident, it was deliberately crafted to *not* say that firmware had to comply with DFSG#4's requirements for source inclusion. I'm sorry if you understood otherwise when setting the supermajority requirements for that vote, or when seconding/voting, but we intentionally *did* release etch with firmware in main that wasn't DFSG-compliant, and http://www.debian.org/vote/2006/vote_007 was the justification for doing so. We certainly weren't pretending that binary microcode firmware was its own source! So if that's not what you mean to say for lenny, I suggest that you propose different language than what you currently have for choice 5 on the ballot. > Without that clause, in choice 2, we are just accepting any firmware blob, > with any license, which means that we are allowing for the DFSG to be > violated I happen to be opposed to such an exception, not because there's a qualitative difference in whether or not we're overriding the DFSG, but because it's broader than the one used for etch and I don't think there's any excuse for regressing. If we're going to relax the firmware requirements even further, then we *should* amend the DFSG explicitly since there's no sense in pretending we're actually trying to close the gap. > I do not think we released before with known violations. We > released with things we strongly suspected as being violations; since > we strongly suspect the blob was not the preferred form of > modification, but we do not know for a fact. By your reasoning, http://www.debian.org/vote/2006/vote_007 was a useless no-op. The release team certainly didn't need to be told it was ok to ship binary firmware in main if we had a good-faith belief that the binary was the preferred form of modification. That sure isn't why I seconded it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
