Re: Call for votes
On Wed, Sep 27, 2006 at 02:06:50AM -0700, Steve Langasek wrote:
> 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?
both.
The above say we have legally the right to distribute those firmwares, and
that it should be DFSG free to be in main, which is what the current social
contract sayus.
> 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.
Even if that someone is lost in space like in the acenic case, or if it is a
manifest error on the licencing ? Like it is most probably for all the
imlpicit GPLEd firmwares, and was solved with qlogic and broadcom last fall.
> 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.
Yes, and our intention is to not remove them for etch, since world+dog also
distributes it, and to work for etch+1 on solving all these issues.
> 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
No, that is not the case, the most probable case is that those firmwares are
under GPL by error, and they will become non-free in the future. In any case,
those are non-distributable.
> 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.
Like said, there are 5 or so firmware thus concerned.
> 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?
Err, it is less than 2 and a half month now, and the kernel will need to be
frozen for the d-i test cycle well before that.
> 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.
a sourceless firmware is considered non-free as per the DFSG, so i really
don't understand the folk who insist on using the sourceless term instead of
the non-free one. Please reread the DFSG.
Friendly,
Sven Luther
Reply to: