Kurt Roeckx wrote in http://lists.debian.org/debian-vote/2006/08/msg00205.htm > I'm not sure about those 46 that already use request_firmware()
I see no reason to take them out. I listed them as a measure of success, at least with recently added drivers. > It would be interestig to know if any of those other 46 are currently in > non-free, or what their license is. I don't understand the question. If you are asking about how a debian user should get the firmware needed by those 46 request_firmware()-ified drivers, I can only answer for a few cases. There is support for the ipw3945 and some qlogic adapters in firmware-nonfree (a package in experimental). I have not tested this myself. Bill Allombert wrote in http://lists.debian.org/debian-vote/2006/08/msg00225.html > I consider a lack of licence or license prohibiting modification to be > much more problematic that a lack of source. In my inventory, many files with firmware in them did not themselves include a license. In those cases, I chose to assume that its license followed the file that #included or otherwise used the data. > I had made research on the topic of binary blob in linux 2.4.18 in the > past I thank you for that! It was a good starting point, and I reference your work. > I don't remember seeing a single firmware with all of: > 1) A detailed copyright notice. (Not just a blob put inside a GPL file > without any hint about how the blob was derivated and who actually wrote > it). > 2) A license that allows redistribution without source (i.e not the GPL) > 3) A license that allows modification, redistribution and all of DFSG > 1,3-10. > 4) No source available. Most of the 59 sourceless-firmware-contaminated files I found do not pass all your tests, mostly (44 of them) because they are (at least superficially) GPL'd. The cases that pass all your tests the best are: drivers/net/tg3.c drivers/net/typhoon-firmware.h drivers/scsi/advansys.c In addition, the drivers/scsi/qla2xxx/ql*_fw.c files do pretty well, except the Linux kernel managed to not include the required LICENSE.qla2xxx file. If they (we) did, its terms are acceptable for non-free. > The conclusion is that the proposed GR would have had little effect on > linux 2.4.18. I think the point of Steve's GR is to allow distribution of the sourceless-firmware-contaminated files that are GPL'd. To me, that's intrinsically not possible. DD opinions on how to interpret the SC have no bearing on the legal problems of satisfying the terms of the GPL. The fact that Red Hat distributes these files in the Linux kernel is IMHO irrelevant -- they not only have lawyers to evaluate the system, they have lawyers to defend themselves, and a pretty big pot of money with which to settle out of court. OTOH, it might be an interesting experiment for a paying Red Hat customer to ask for the source to drivers/usb/serial/io_fw_boot2.h . Marco d'Itri wrote in http://lists.debian.org/debian-vote/2006/08/msg00204.html > And http://kerneltrap.org/node/6550: > Theo de Raadt: [...] But in the end, if we wish to support any such > devices, we must be practical. We must accept the risk that there is a > flaw in the firmware. OK, Marco, you're right on this one. I reread material from Theo, and he does (mistakenly, from my point of view) make a distinction between binary blobs that run on the host processor (which he forbids in OpenBSD) and those that run on peripheral processors (which he calls firmware, and accepts into OpenBSD if they have a suitable license). Note that he doesn't have to deal with GPL'd code to the extent we do, nor is he expected to uphold Debian's SC. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]