On Wed, Apr 25, 2001 at 10:50:43PM -0700, Greg KH wrote: > - The license on the files keyspan_usa*_fw.h is the only files > effected by the Keyspan license. This license was drawn up by > Keyspan's lawyers after consulting other firmware licenses in > the kernel, talking to me, the driver's author Hugh Blemings, > and Linus. In the end, Linus accepted the current wording on > the files, Keyspan was happy, Hugh and I were happy that we > got some new drivers in the kernel, and users were happy to > see more devices supported. I'm confused. Is the code in that file GPL'd, or is it not? > Keyspan has been very helpful in development of the Linux drivers. They > offered specs to Hugh and support. This enabled Linux to have support > for devices before other os's did (like the Mac and Windows.) Acknowledged, but not directly relevant. > - This isn't the only firmware file in the kernel that has a "odd" > license. Read the file fore200e_firmware_copyright in drivers/atm > and let me know what you think. There are others in the tree, like > this last time I checked. It's VERY weird: These microcode data are placed under the terms of the GNU General Public License. We would prefer you not to distribute modified versions of it and not to ask for assembly or other microcode source. Copyright (c) 1995-2000 FORE Systems, Inc., as an unpublished work. This notice does not imply unrestricted or public access to these materials which are a trade secret of FORE Systems, Inc. or its subsidiaries or affiliates (together referred to as "FORE"), and which may not be reproduced, used, sold or transferred to any third party without FORE's prior written consent. All rights reserved. Sounds like it's dual-licensed. But I'm not sure what the legalities of putting a _binary_ under the GPL are. > - Since this Keyspan license seems to be objectionable, what kind of > license can/should a company put on its binary firmware image that > has to be included in the Linux kernel. Anything that meets http://www.debian.org/social_contract#guidelines and is GPL-compatable. Typically that implies some kind of X/BSD style license, but I don't see why the GPL is inappropriate here. Now, for some commentary.... Mentally, I reduce this whole debate to whether software is free if it is complied from secret source and the binary is released under the GPL. I'm pretty sure that it isn't free software. The source obligations of the GPL v2, however, confuse me: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) An interesting hypothetical question is: what if there is no source code? While impractical, I could quite concievably write a program just by entering its machine code into a hex editor. How would the GPL's restrictions bind me? The more relevant question is what happens when a binary is compiled from source, but the binary is GPL'd and not the source code, which is never made public. It would seem from the above quoted text that that you are required to make available the source code, whether it is public or not. But then again, you have to make it available whether it _exists_ or not if you take the text literally. Unfortuantely, the GPL does not make any sort of explicit statement that it can only be applied directly onto source code: 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". So far, I've been refering to the GPL's conditions and concluded that it is probably a violation of the GPL to include such "strings" in Linux, even if that "data" is licensed under the GPL in its compiled form. One could possibly design a sly argument to try and defeat this, taking advantage of the fact that a program could be considered as its own source code, but I am confident that the spirit of the GPL is against the current situation being viewed as acceptable. Anyway, we should ask RMS. GPL'd or not, I'm sorry Greg but the firmware is non-free software. 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Who cares if it's under a free license when it doesn't comply with the terms of that license, namely that the source code must be publically available? And when the source code isn't available, the software is directly violating rule 2 of the DFSG. I think I've heard some arguments that the firmware is really data rather than software since it is not run on the main CPU. Sorry, but I do not think this is a valid argument at all. Debian distributes software that can be run on embedded systems. Just because they aren't personal computers, does it exempt software that runs on them from meeting the DFSG? The chips that excecute the firmware are part of a computer, and then run the firmware. That makes the firmware code (although I do admit that the line is blurry). This chip could be viewed as a secondary processor of a personal computer. Sorry, but I don't see anything saying or implying that only software intended for the primary CPU's of a computer have to meet the DFSG.
Attachment:
pgpGHIyvzgljs.pgp
Description: PGP signature