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