[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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: