Re: First call for votes for the Lenny release GR
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/
slangasek@ubuntu.com vorlon@debian.org
Reply to: