Re: Call for votes
On Wed, Sep 27, 2006 at 08:21:21AM +0200, Sven Luther wrote:
> Two questions here.
> First, this means that this proposal needs seconds, right ? Or can Frederik
> just incorporate it into his proposal ?
Frederik does have the option of incorporating it into his proposal, in
which case all of the sponsors have the choice of renewing their second for
the changed resolution, or rejecting the change and becoming the new
proposer of Frederik's original resolution.
> > ,----
> > | 1. We affirm that our Priorities are our users and the free software
> > | community (Social Contract #4);
> > | 2. We acknowledge that there is a lot of progress in the kernel
> > | firmware issue; however, it is not yet finally sorted out;
> > | 3. We give priority to the timely release of Etch over sorting every
> > | bit out; for this reason, we will treat removal of sourceless
> > | firmware as a best-effort process, and deliver firmware in udebs as
> > | long as it is necessary for installation (like all udebs), and
> > | firmware included in the kernel itself as part of Debian Etch,
> > | as long as we are legally allowed to do so, and the formware is
> > | distributed under a DFSG free license.
> > `----
> I will let Frederik comment, but this ammendment is a total reversal of the
> proposition, doesn't allow for a "timely release of etch", so contradicts
> itself, and is just the status quo anyway.
What are you claiming is the status quo -- that we're not legally allowed to
distribute the firmware in question, or that it's not made available under a
DFSG-compliant license?
If they're illegal to distribute, the project can pass GRs until they're
collectively blue in the face, and it won't matter to me -- I'm not going to
give my ok as RM to releasing something that I *know* is a violation of
someone's copyright.
If you think that the firmware at issue is not distributed under a
DFSG-compliant *license*, then you and I seem to be looking at different
firmware. Of the binary firmware that Larry Doolittle has identified as
still included in the Debian kernel (as of 2.6.17), only three drivers use
blobs that don't have a DFSG-compliant license: an appletalk driver, a token
ring driver, and a USB audio driver.
So if we trust for the moment that everyone involved is acting in good faith
and the "GPL" blobs are intended to be distributable and modifiable even
though they don't include source, a simple "sourceless firmware is ok for
main" exemption gives us 100% coverage of the firmware that matters to the
installer, and 85% coverage of *all* the redistributable binary firmware in
the kernel packages today, including those readded in 2.6.18. That leaves
"only" 15% of the firmware that the kernel team would have to decide how
to support for etch, and that includes those drivers that were *already*
dropped before sarge's release and just now readded.
And if 2 1/2 months isn't long enough to solve just the kernel question of
how to package and distribute these drivers/firmware when we know they
aren't needed by the installer, then I can expect you to be suitably ashamed
of having blamed the debian-installer team for all the delays, right?
Then again, I guess the difference between "sourceless" and "non-free" is
"just words", and I shouldn't expect you to pay any attention to me until I
start drawing Venn diagrams for you.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: