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.
pgp6pKRq4ZA5d.pgp
Description: PGP signature
