late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)
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
Reply to: