Re: Bug#239952: kernel-source-2.6.4: qla2xxx contains non-free firmware
Chris Cheney wrote:
> On Thu, Mar 25, 2004 at 07:29:49PM +1100, Herbert Xu wrote:
>> On Thu, Mar 25, 2004 at 01:45:22AM +0100, Adrian Bunk wrote:
>> > Package: kernel-source-2.6.4
>> > Severity: grave
>> >
>> > It seems the following files of the qla2xxx driver contain non-free
>> > firmware:
>> > ./drivers/scsi/qla2xxx/ql2100_fw.c
>> > ./drivers/scsi/qla2xxx/ql6322_fw.c
>> > ./drivers/scsi/qla2xxx/ql2300_fw.c
>> > ./drivers/scsi/qla2xxx/ql2200_fw.c
>> > ./drivers/scsi/qla2xxx/ql6312_fw.c
>> > ./drivers/scsi/qla2xxx/ql2322_fw.c
>>
>> I presume you're objecting to these firmware on the basis that they
>> are being distributed as machine code.
>>
>> I personally find this attitude to be extreme. However, I have in
>> the past removed a number of drivers for exactly this reason at the
>> request of other developers.
>>
>> I would like the opinion of all Debian developers on the general issue
>> of firmware in the kernel-source package.
>>
>> If we do decide to remove them, then we can remove quite a number of
>> other drivers for the same reason, I can think of qlogicisp and tg3
>> off the top of my head.
>>
>> I recall that when this issue was first raised with the keyspan drivers,
>> some of the people advocating their removal promised to modify the
>> drivers so that the firmware could be loaded from userspace (just like
>> how the anti-non-free camp promised to host non-free packages), it
>> appears that after three years this support still has not materialised.
>>
>> Perhaps the easiest solution is to move all kernel packages into
>> non-free.
>>
>> PS I'm deliberately avoiding debian-legal as the inhabitants there tend
>> to have views that are not necessarily representative of the project
>> as a whole.
>
> For this "binary firmware is not preferred form of source" issue to be
> resolved coherently all sources that include binary firmware and all
> drivers that include undocumented magic numbers and strings must be
> removed since of course undocumented magic numbers and strings are not
> preferred form of source either! Hence all or at a least a large amount
> of reverse engineered drivers would need to be removed at minimum,
> besides the drivers vendors provide with binary firmware. I know the
> driver I wrote for the linux kernel uses magic strings which might be
> firmware, I don't know, and so its certainly not the preferred form of
> source. The company making the product never provided documentation on
> the device at all nevermind the source for the supposed firmware.
Not the issue in question....
There are several cases which have been discussed here.
(1) drivers/firmware released under GPL, with the same source used by the
copyright holders to make new releases (whether this is a binary blob, or
much more likely assembler or C code).
These are fine.
(1a) If the appropriate tools needed for compliation/assembly are not
free, they need to go in 'contrib';
(1b) if the tools are free, they can go in 'main'.
(2) drivers/firmware released only "under the GPL" as binary blobs, where
the copyright holders have secret source code hidden away somewhere.
These cannot legally be distributed, at all, because the terms of the GPL
cannot be satisfied.
(3) (This case apparently hasn't actually happened.) Drivers/firmware
released under a DFSG-free license which *doesn't* require source
distribution -- without source.
These can go in "non-free"; the absence of source means they aren't
DFSG-free, I think.
(4) drivers/firmware released only under non-DFSG-free licenses.
These must be removed from 'main'; if freely distributable, they can go in
'non-free'.
Distinguishing between (1) and (2) is best done by simply *asking* the
copyright holders if the firmware was written directly in machine code
(perhaps using some kind of specialized machine-code editor) or not. I
think it's fair to assume that most of the really large binary blobs
weren't, unless the copyright holders claim explicitly that they were,
because it just seems very, very unlikely that they were.
--
Make sure your vote will count.
http://www.verifiedvoting.org/
Reply to: