late for party (was Re: Proposal: The DFSG do not require ..

Hi -

Sorry I'm late for the party. I'm on travel, with less than
ideal 'net connections. Reading 147 messages on d-v over
a hotel's erratic wireless link was not fun.

Moritz Muehlenhoff wrote in
http://lists.debian.org/debian-vote/2006/08/msg00117.html
> None of the trolls demanding the removal of firmware from main has
> ever done significant work to resolve this upstream.

As one of the trolls who points out that non-free firmware doesn't
belong in main, I wish to also point out that Debian's etch release
plan doesn't permit this to be resolved upstream, since 2.6.18 is
nearly out, and that's what Debian's etch kernel will be based on.
My understanding is that upstream has not been entirely receptive
to patches that remove non-free firmware from it. Maybe that's
because they don't have an established firmware-nonfree project
(like Debian does) into which to move that firmware?

Matthew Garrett wrote in
http://lists.debian.org/debian-vote/2006/08/msg00116.html:
> Do you believe that hardware with the firmware in ROM is preferable
> (from a pure freedom point of view) to hardware with firmware loaded by
> the OS?

Hardware that is shipped with defective firmware in EEPROM
is defective, and can be returned to the manufacturer under
warranty.

The owner of hardware that is useless because of defective
firmware shipped in the Linux kernel has no such recourse.

Florian Weimer wrote in
http://lists.debian.org/debian-vote/2006/08/msg00068.html
> A completely different issue is whether we take upstream's word
> for GPL compability, or if we claim that something is not
> redistributable because it contains a firmware blob *and*
> is licensed under the GPL as a whole.

A consensus of DD that "firmware is not software" carries no
legal weight. 44 of the sourceless-firmware-contaminated
files in the Linux kernel are claimed to be covered by the GPL.
There is no legal way for Debian to redistribute those files,
since we can't provide that source to people who attempt to
exercise their GPL-mandated rights.

The best that a GR could do would be to permit Debian to
distribute the 12 BSD-ish licensed sourceless-firmware-contaminated
files to be distributed in main instead of non-free.
Better might be to relabel the Linux kernel non-free.

Before you ask, no, 44+12 != 59. There are three s-f-c Linux
kernel files that are neither GPL nor BSD-ish. Check out for
yourself if you think Debian should redistribute them.

I have research in progress that I hope will start the ball
rolling to find out which of those s-f-c GPL's programs could
be relicensed. Sorry, nothing to report yet. Watch for it in d-k.

Mike Hommey wrote in
http://lists.debian.org/debian-vote/2006/08/msg00171.html
> Note that there are more and more applications trying to use
> the power of the GPU for computation. The hole should not be
> left open in the GR.

Right.

Here's a thought experiment for those who would call non-free
firmware suitable for main: if Macromedia^WAdobe distributed
a Linux Flash plug-in that only worked on nVidia graphics
cards, because it downloaded critical parts of the Flash
interpreter (in binary form, without source code, of course)
to the GPU and executed it there, would you consider that
program valid for Debian main?

Pierre Habouzit wrote in
http://lists.debian.org/debian-vote/2006/08/msg00159.html
> * if there is no source, but that the blob is modifiable,
redistribuable, ... then we tolerate it in main.

Hmm. Case 1: the blob is under the GPL. You can't distribute
it, even under non-free, and even if you split out the firmware,
because you can't satisfy requests for source. Case 2: the blob
is under BSD-ish terms. Why _not_ move the firmware to non-free?
Keeping it under free is disingenuous, since it doesn't satisfy DFSG.
The license is entirely compatible into a (free source/nonfree
firmware) architecture, just like 47 other extant drivers in the
Linux kernel.

Marco d'Itri wrote in
http://lists.debian.org/debian-vote/2006/08/msg00166.html
> > I think we should learn from OpenBSD on this front.
> I agree. Indeed, the OpenBSD project not only distributes
> sourceless firmwares, but also sourceless firmwares with a
> license which forbids modifications and reverse engineering.

Care to back up that statement? It runs 180 degrees counter
to my understanding of OpenBSD.

Sven Luther wrote in
http://lists.debian.org/debian-vote/2006/08/msg00125.html
> I would indeed vote for a solution including a non-free hardware,
> or even better an additional CD, which contained a non-free
> version of d-i (which need to include certain non-free firmwares
> and drivers in the images), and all the additional non-free
> firmware stuff.
> This way, we could add a list of pci ids needding non-fre
> hardware, and do a check pretty early in the installer, and
> if those non-free hardware is found, inform the user about it,
> and use the non-free installer CD instead, and all
> the rest would be taken care for him.

Nice idea, Sven. Do you really think that can work reliably
for etch, in December?

While Steve's proposal item (4) is just plain false, I can
certainly see the argument to continue to make a firmware
exception for etch. I would support such a plan only if it
was explicitly etch-only, and linux-2.6 only, and there was
a commitment to rip out superficially illegal GPL/s-f-c files
the day after etch releases.

Kurt wrote in
http://lists.debian.org/debian-vote/2006/08/msg00167.html
> It would also be useful to have a list of firmwares we're
> currently are talking about, and what license they have.
> Are there any that only fail DFSG 2, or will this part of
> GR have no effect at all?

http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html

- Larry


--
To UNSUBSCRIBE, email to debian-vote-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

On Thu, Aug 24, 2006 at 09:56:49PM -0700, ldoolitt.DeleteThis@recycle.lbl.gov wrote:
> Sven Luther wrote in
> http://lists.debian.org/debian-vote/2006/08/msg00125.html
> > I would indeed vote for a solution including a non-free hardware,
> > or even better an additional CD, which contained a non-free
> > version of d-i (which need to include certain non-free firmwares
> > and drivers in the images), and all the additional non-free
> > firmware stuff.
> > This way, we could add a list of pci ids needding non-fre
> > hardware, and do a check pretty early in the installer, and
> > if those non-free hardware is found, inform the user about it,
> > and use the non-free installer CD instead, and all
> > the rest would be taken care for him.
>
> Nice idea, Sven. Do you really think that can work reliably
> for etch, in December?

No, it is already too late. The time to work on this was quickly after the
sarge release last fall, but upstream was not ready, the kernel team was hard
working on things like the common package, and the devfs removal / ramdisk
generator issues, and in general to bringing a more timely release schedule
in action. Other teams clearly dismissed the issue and are now also blocking
point.

As thus, the most reasonable way, would be to delay the issue until etch+1,
which gives us time to work on it in tranquility, be able to make more
adventursome choices and experiments, without the fear of breakage that comes
at a moment where major component affected (kernel, d-i) are already frozen.

> While Steve's proposal item (4) is just plain false, I can
> certainly see the argument to continue to make a firmware
> exception for etch. I would support such a plan only if it
> was explicitly etch-only, and linux-2.6 only, and there was
> a commitment to rip out superficially illegal GPL/s-f-c files
> the day after etch releases.

Well, not the day after the etch release, but shortly thereafter.

I do believe that there is a certain rythm to a release schedule. At first
after a release is a time of rest, where the pression of the release is
evacuated, and it is a time for thought and reflexion over what went badly,
and what could be improved. Then is a time for more adventursome changes, new
implementations, and so on, then once the choices are implemented, they are
validated through a time of testing, and then we enter in the pre-release
fine-tuning phase culminating with the release.

We are now in that last phase, and it is too late for a solution to the
non-free firmware issue for etch, and our best guess would be to get it out of
the way quickly, and be able to concentrate on it post etch.

The problem also was that a certain amount of developers had trouble with the
above rythm, and kind of believed they where already in the no-major-change
fine-tuning period immediately after sarge, most prominent among them the d-i
team, probably due to lack of man power after the post-sarge defection.

Friendly,

Sven Luther


--
To UNSUBSCRIBE, email to debian-vote-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org