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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
