more files with licenses that aren't GPL-compatible
While I don't want to jump into the usual Debian wankfest whether Linux as GPL'ed project can distribute hex-images of firmware at all there are a few firmware C headers files that have a license statement that aren't GPL-compatible at all, namely the keyspan firmware in drivers/usb/serial/keyspan*_fw.h with the following license text:
---------------------------- snip ----------------------------
The firmware contained herein as keyspan_mpr_fw.h is
Copyright (C) 1999-2001
Keyspan, A division of InnoSys Incorporated ("Keyspan")
as an unpublished work. This notice does not imply unrestricted or public access to the source code from which this firmware image is derived. Except as noted below this firmware image may not be reproduced, used, sold or transferred to any third party without Keyspan's prior written consent. All Rights Reserved.
Permission is hereby granted for the distribution of this firmware image as part of a Linux or other Open Source operating system kernel in text or binary form as required.
This firmware may not be modified and may only be used with Keyspan hardware. Distribution and/or Modification of the keyspan.c driver which includes this firmware, in whole or in part, requires the inclusion of this statement."
---------------------------- snip ----------------------------
which makes the kernel as whole unredistributable. A similar license was according to Greg also recently granted for drivers/usb/misc/emi62_fw_*.h which currently has even worse license statements in there.
Does someone have good contacts to keyspan to get it under a more suitable license?
Quoted 5 lines · Christoph Hellwig
While I don't want to jump into the usual Debian wankfest whether Linux as GPL'ed project can distribute hex-images of firmware at all there are a few firmware C headers files that have a license statement that aren't GPL-compatible at all, namely the keyspan firmware in
drivers/usb/serial/keyspan*_fw.hwith the following license text:
--*snip*--
Quoted 10 lines
Permission is hereby granted for the distribution of this firmware image as part of a Linux or other Open Source operating system kernel in text or binary form as required.
This firmware may not be modified and may only be used with Keyspan hardware. Distribution and/or Modification of the
keyspan.cdriver which includes this firmware, in whole or in part, requires the inclusion of this statement."
---------------------------- snip ----------------------------
Quoted 4 lines
which makes the kernel as whole unredistributable. A similar license was according to Greg also recently granted for
drivers/usb/misc/emi62_fw_*.hwhich currently has even worse license statements in there.
Unredistributable? Am I mistaken? It says permission is given to redistribute this piece as part of the linux kernel. You just can't modify it. Although it is unquestionably not a very permissive license, it's inclusion is not detrimental to the kernel.
Please correct me if I am wrong.
Quoted 4 lines · Eric
Quoted 3 lines · Christoph Hellwig
Permission is hereby granted for the distribution of this firmware image as part of a Linux or other Open Source operating system kernel in text or binary form as required.
Permission is legally granted
Quoted 4 lines
Quoted 4 lines
This firmware may not be modified and may only be used with Keyspan hardware. Distribution and/or Modification of the
keyspan.cdriver which includes this firmware, in whole or in part, requires the inclusion of this statement."
But we can't actually distribute this file under GPL because we are not allowed to modify it. They own the copyright, so they can release it under any terms that they want. One of their terms is that we can make copies and give them to people. The other term is that nobody but them can change it. The two aren't incompatible, but the second is anti-GPL.
Quoted 4 lines
Unredistributable? Am I mistaken? It says permission is given to redistribute this piece as part of the linux kernel. You just can't modify it. Although it is unquestionably not a very permissive license, it's inclusion is not detrimental to the kernel.
Unfortunately the GPL requires that everybody has the right to *modify* and distribute *modified* copies of any files released under it. If a file is to be distributed as a part of the GPLed Linux kernel must also follow GPL.
The relevant portion of the GPL:
Quoted 9 lines
[...snip...]
You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
[...snip...]
Quoted 8 lines
b) You must cause any work that you distribute or publish, that in whole or
in part contains or is derived from the Program or any part thereof,
to be
licensed as a whole at no charge to all third parties under the terms
of
this License.[...snip...]
Cheers,
Kyle Moffett
Quoted 5 lines
Quoted 5 lines
Permission is hereby granted for the distribution of this firmware image as part of a Linux or other Open Source operating
system kernel
in text or binary form as required.
They can't grant that permission. Every single person who had contributed
to the Linux kernel would have to agree. The GPL prohibits including software that isn't itself GPL'd from being combined with GPL'd software. The issue is not permission to distribute this driver, the issue is permission to distribute the *kernel*. The kernel's license prohibits distrubiting it in combination with works that have licenses more restrictive than the GPL.
Quoted 2 lines
Quoted 2 lines
This firmware may not be modified and may only be used with Keyspan hardware.
That's more restrictive than the GPL. So if you link this with a GPL'd
work, the entirety must be distributed under the GPL, which you can't do since you can't authorize the unrestricted use of the firmware
Quoted 1 line
Quoted 1 line
which makes the kernel as whole unredistributable. A similar license
Bingo.
Quoted 6 lines
Unredistributable? Am I mistaken? It says permission is given to redistribute
this piece as part of the linux kernel. You just can't modify it. Although it
is unquestionably not a very permissive license, it's inclusion is not detrimental to the kernel.
He didn't say this made the firmware unredistributable, he said it made the
*kernel* unredistributable. Since you can't GPL the firmware, the kernel as a whole is not GPL. You cannot distribute a non-GPL Linux kernel because the GPL prohibits it as the GPL applies to everything else in the kernel.
Quoted 1 line
Please correct me if I am wrong.
You *definitely* are wrong. The entirety of the GPL would be negated if you
were correct.
DS
Quoted 7 lines · David Schwartz
Quoted 6 lines
Quoted 6 lines
Permission is hereby granted for the distribution of this firmware image as part of a Linux or other Open Source operating
system kernel
in text or binary form as required.
Quoted 7 lines
They can't grant that permission. Every single person who had contributed
to the Linux kernel would have to agree. The GPL prohibits including software that isn't itself GPL'd from being combined with GPL'd software. The issue is not permission to distribute this driver, the issue is permission to distribute the *kernel*. The kernel's license prohibits distrubiting it in combination with works that have licenses more restrictive than the GPL.
That better be bogus, or else vendors are going to be very upset that they can't ship the kernel with, say, trademarked images. For example, Mozilla's trademark on their artwork is fairly restrictive, or the Mandrake Firewall product (if that's even still around - I don't keep up).
-Erik
Quoted 40 lines
Quoted 3 lines
Quoted 3 lines
This firmware may not be modified and may only be used with Keyspan hardware.
That's more restrictive than the GPL. So if you link this with a GPL'd
work, the entirety must be distributed under the GPL, which you can't do since you can't authorize the unrestricted use of the firmwareQuoted 1 line
Quoted 1 line
which makes the kernel as whole unredistributable. A similar license
Bingo.
Quoted 6 lines
Unredistributable? Am I mistaken? It says permission is given to redistribute
this piece as part of the linux kernel. You just can't modify it. Although it
is unquestionably not a very permissive license, it's inclusion is not detrimental to the kernel.He didn't say this made the firmware unredistributable, he said it made the
*kernel* unredistributable. Since you can't GPL the firmware, the kernel as a whole is not GPL. You cannot distribute a non-GPL Linux kernel because the GPL prohibits it as the GPL applies to everything else in the kernelQuoted 1 line
Please correct me if I am wrong.
You *definitely* are wrong. The entirety of the GPL would be negated if you
were correct.DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · Erik Harrison
Quoted 7 lines
They can't grant that permission. Every single person who had contributed
to the Linux kernel would have to agree. The GPL prohibits including software that isn't itself GPL'd from being combined with GPL'd software. The issue is not permission to distribute this driver, the issue is permission to distribute the *kernel*. The kernel's license prohibits distrubiting it in combination with works that have licenses more restrictive than the GPL.
Quoted 5 lines
That better be bogus, or else vendors are going to be very upset that they can't ship the kernel with, say, trademarked images. For example, Mozilla's trademark on their artwork is fairly restrictive, or the Mandrake Firewall product (if that's even still around - I don't keep up).
The trademark doesn't matter at all. If want to include a logo in the kernel source and license it under some GPL-incompatible license, yes they can't redistribute it.
Quoted 14 lines
Quoted 9 lines · David Schwartz
They can't grant that permission. Every single person
who had contributed
to the Linux kernel would have to agree. The GPL prohibits including software that isn't itself GPL'd from being combined with GPL'd software.
The issue is not permission to distribute this driver, the issue is permission to distribute the *kernel*. The kernel's license prohibits distrubiting it in combination with works that have licenses more restrictive than the GPL.
Quoted 5 lines
That better be bogus, or else vendors are going to be very upset that they can't ship the kernel with, say, trademarked images. For example, Mozilla's trademark on their artwork is fairly restrictive, or the Mandrake Firewall product (if that's even still around - I don't keep up).
I can't speak to the trademark issue. I don't know enough about how the GPL
deals with possible trademark issues. I believe you could not embed trademarked images into the kernel and distribute the result either.
However, this is a pure copyright issue. You cannot combine GPL'd code with
code that has a more restrictive license and distribute the resulting binaries. Read GPL section 2b:
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet *all* of these conditions:
...
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
How can you cause the Linux kernel combined with this firmware to be
licensed under the terms of the GPL? (And, by the way, I think this prohibits trademark as well, which is very interesting.)
DS
Am Mittwoch, 16. Juni 2004 23:21 schrieb David Schwartz:
Quoted 8 lines
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
How can you cause the Linux kernel combined with this firmware to be licensed under the terms of the GPL? (And, by the way, I think this prohibits trademark as well, which is very interesting.)
This all boils down to the question of whether fimware is code or not. As this question is extremely unlikely to be resolved on this list and was discussed here several times already, I kindly request that you take this discussion to a legalistic list and confine traffic of this kind on this list to clear and technical issues.
TIA
Oliver
Quoted 9 lines
Am Mittwoch, 16. Juni 2004 23:21 schrieb David Schwartz:
Quoted 5 lines
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
Quoted 6 lines
Quoted 4 lines
How can you cause the Linux kernel combined with this firmware to be
licensed under the terms of the GPL? (And, by the way, I think this prohibits trademark as well, which is very interesting.)This all boils down to the question of whether fimware is code or not.
Perhaps I'm missing something. Can you explain why you think that matters?
I'll repeat the GPL section I'm talking about:
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
First, this says, "any work", it's not limited to code. It says, "in whole
or in part contains or is derived from the Program" -- a binary of the Linux kernel is clearly derived from the Linux kernel source. And it says "licensed *as a whole* ... under the terms of *this* license".
So where's the gray area you seem to be imagining?
Quoted 4 lines
As this question is extremely unlikely to be resolved on this list and was discussed here several times already, I kindly request that you take this discussion to a legalistic list and confine traffic of this kind on this list to clear and technical issues.
This is a different issue. This isn't about distributing firmware and
whether the firmware itself is a derived work. This is about distributing the Linux kernel as a work containing non-GPL'd elements with use restrictions. GPL section 2b authoritatively prohibits this. There is no gray area here.
This is a clear issue, but not a technical one. However, being unable to
distribute binaries of the Linux kernel would present numerous technical problems.
DS
Quoted 5 lines · David Schwartz
First, this says, "any work", it's not limited to code. It says, "in whole
or in part contains or is derived from the Program" -- a binary of the Linux kernel is clearly derived from the Linux kernel source. And it says "licensed *as a whole* ... under the terms of *this* license".
Ok, so this means that the given binary table which represents the firmware is forced to be under a GPL license. Let's also say, for the circumstances, that what amounts to a hex dump is the "preferred form" of the firmware.
Does that make everyone happy?
Then get the vendor the say that "the binary form of the firmware" can be converted to GPL as necessary.
Now, this may open them up to reverse engineering, but so what.
Quoted 10 lines
Quoted 6 lines · David Schwartz
First, this says, "any work", it's not limited to code. It says, "in whole
or in part contains or is derived from the Program" -- a binary of the Linux
kernel is clearly derived from the Linux kernel source. And it says "licensed *as a whole* ... under the terms of *this* license".
Quoted 6 lines
Ok, so this means that the given binary table which represents the firmware is forced to be under a GPL license. Let's also say, for the circumstances, that what amounts to a hex dump is the "preferred form" of the firmware.
Does that make everyone happy?
That would satisfy me.
Quoted 4 lines
Then get the vendor the say that "the binary form of the firmware" can be converted to GPL as necessary.
Now, this may open them up to reverse engineering, but so what.
This would mean that they would have to permit people to modify the
firmware, reverse engineer the firmware, and use the firmware with other products.
DS
Quoted 7 lines · David Schwartz
Quoted 2 lines
Now, this may open them up to reverse engineering, but so what.
This would mean that they would have to permit people to modify the
firmware, reverse engineer the firmware, and use the firmware with other products.
Them's the breaks. That's the risk you take any time you open up any IP as open source. This is why nVidia and ATI (lately) do not want to publish register references for their chips. This exposes things which competitors might benefit from in some way (whether in engineering or marketing).
How do you do open source AND protect your IP investment at the same time? That's one of the tough issues with the GPL.
Quoted 1 line · Oliver Neukum
This all boils down to the question of whether fimware is code or not.
No, that's exactly the political discussion we don't want to discuss here. The keyspan case is worse where a file used in the kernel built has a GPL-incompatible license.
Am Donnerstag, 17. Juni 2004 09:59 schrieb Christoph Hellwig:
Quoted 6 lines · Oliver Neukum
Quoted 1 line
This all boils down to the question of whether fimware is code or not.
No, that's exactly the political discussion we don't want to discuss here. The keyspan case is worse where a file used in the kernel built has a GPL-incompatible license.
Then go hence and convert the driver to the sysfs firmware interface, but please, please take the legalese off this list.
Regards
Oliver
Quoted 10 lines · Oliver Neukum
Am Donnerstag, 17. Juni 2004 09:59 schrieb Christoph Hellwig:
Quoted 6 lines · Oliver Neukum
Quoted 1 line
This all boils down to the question of whether fimware is code or not.
No, that's exactly the political discussion we don't want to discuss here. The keyspan case is worse where a file used in the kernel built has a GPL-incompatible license.
Then go hence and convert the driver to the sysfs firmware interface, but please, please take the legalese off this list.
Umm, we ship something that isn't GPL-compatible. Whenever I found something like that (GFDL documentation, headers from vendor SDKs, strange license text) we got that solved easily. Now because it's the magic firmware crap we shouldn't care anymore.
And no, I'm not going to convert it. I'm not a usb person and I couldn't test it. If one of you usb guys want to convert it that's fine, if we get the files relicensed under a GPL-compatible license that's fine aswell, else I'll send a removal patch to Linus.
Stop beeing sloppy about copyrights.
Quoted 8 lines · Christoph Hellwig
Quoted 1 line · Oliver Neukum
This all boils down to the question of whether fimware is code or not.
No, that's exactly the political discussion we don't want to discuss here. The keyspan case is worse where a file used in the kernel built has a GPL-incompatible license.
From a technical point of view I'm just wondering how it comes this
firmware is derived from the Linux kernel? I mean this is running on an 8-bit microcontroller with some 4KiB of memory so it sounds pretty much impossible to me.
If anybody would have a point calling this a derived work from Linux, I'd be very concerned about SCO might have a point with their claims wrt. Linux being derived from their IP =(:-(
Quoted 1 line
From the maintenance POV of course it would be much better not to have it
aggregated with the kernel sources.
SCNR
Martin
Quoted 8 lines · Martin Diehl
Quoted 1 line
From a technical point of view I'm just wondering how it comes this
firmware is derived from the Linux kernel? I mean this is running on an 8-bit microcontroller with some 4KiB of memory so it sounds pretty much impossible to me.
If anybody would have a point calling this a derived work from Linux, I'd be very concerned about SCO might have a point with their claims wrt. Linux being derived from their IP =(:-(
It doesn't matter and that's not what we're discussing here. There are whole C source files in the build with a license that doesn't allow modification. Firmware or not doesn't matter at all.
Quoted 4 lines · Martin Diehl
From a technical point of view I'm just wondering how it comes this firmware is derived from the Linux kernel? I mean this is running on an 8-bit microcontroller with some 4KiB of memory so it sounds pretty much impossible to me.
I'm not sure that the point of your question is. It's _obviously_ not derived from the Linux kernel; it can be reasonably considered an independent and separate work in itself. This is part of what the GPL has to say about such things:
"These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
Unfortunately, you seem to have stopped reading there. You should have read the rest of the paragraph, and also the following paragraph:
" ... But when you distribute the same sections as
part of a whole which is a work based on the Program, the
distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire
whole, and thus to each and every part regardless of who wrote
it.
"Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program."
Note the use of the phrase 'derivative OR COLLECTIVE works'. Please don't confuse the issue by talking only about derivation, when that's not all that's relevant in the context of the GPL.
To pick another example -- the binary-only module distributed by Linksys/Cisco in their wireless router products is of dubious legality by itself since it may or may not be a derived work -- but that's not really relevant when it's distributed in their product's firmware as part of a collective work which is based on the Linux kernel. In that situation it's clearly a copyright violation.
Signature · 1 line
dwmw2
Quoted 12 lines · Oliver Neukum
Am Mittwoch, 16. Juni 2004 23:21 schrieb David Schwartz:
Quoted 8 lines
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
How can you cause the Linux kernel combined with this firmware to be
licensed under the terms of the GPL? (And, by the way, I think this prohibits trademark as well, which is very interesting.)
Quoted 5 lines
This all boils down to the question of whether fimware is code or not. As this question is extremely unlikely to be resolved on this list and was discussed here several times already, I kindly request that you take this discussion to a legalistic list and confine traffic of this kind on this list to clear and technical issues.
If you consider firmware to be "part of the hardware", then it's no different from having a table of register values to write to a peripheral whose meaning just isn't documented anywhere.
Remember the big up-roar about how Sun would not release information to one of the BSD teams so that they could port to UltraSparc III? Well, they'd given that information to a Linux developer, and you can look at the source code if you like, but it isn't MEANINGFUL in a way that lets someone examine it to understand it to be able to reimplement it for a different OS.
With the case of the firmware, since the code there is only meaningful to the hardware you load it into, and that code doesn't execute on the host processor, this may create a sort of conceptual barrier which insulates the firmware code from NEEDING to be "open source".
Or to put it another way, you might consider a hex representation of the firmware that is embedded in the kernel to be the "preferred form", and its license is no more relevant than the license applied to the Verilog source to an ASIC for which you DON'T have to load firmware.
Lawyers could have a great fun time with this. :)
Quoted 16 lines · Erik Harrison
Quoted 7 lines · David Schwartz
Quoted 6 lines
Quoted 6 lines
Permission is hereby granted for the distribution of this firmware image as part of a Linux or other Open Source operating
system kernel
in text or binary form as required.Quoted 7 lines
They can't grant that permission. Every single person who had contributed
to the Linux kernel would have to agree. The GPL prohibits including software that isn't itself GPL'd from being combined with GPL'd software. The issue is not permission to distribute this driver, the issue is permission to distribute the *kernel*. The kernel's license prohibits distrubiting it in combination with works that have licenses more restrictive than the GPL.
Quoted 5 lines
That better be bogus, or else vendors are going to be very upset that they can't ship the kernel with, say, trademarked images. For example, Mozilla's trademark on their artwork is fairly restrictive, or the Mandrake Firewall product (if that's even still around - I don't keep up).
Not bogus, but the solutions are simple:
1. don't _link_ the proprietary file into the kernel, ship firmware & logo as separate files along with the distro. No problem.
2. Release drivers under the GPL instead of restrictive licence, provide GPL'ed logos instead of the trademarked ones.
Helge Hafting
Quoted 2 lines · Helge Hafting
1. don't _link_ the proprietary file into the kernel, ship firmware & logo as separate files along with the distro. No problem.
USB serial drivers could be implemented in userspace given a 2.6 version of Rogier Wolff's userspace serial patch:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.1/att-1075/01-patch-2.4.20.trueport-12-mrt
We currently have a lot of USB drivers in the kernel that could be implemented in userspace. I'm thinking of drivers/usb/image, misc, and serial particularly. If there was a userspace API to do for video capture what SANE does for scanners, drivers/usb/media would be mostly unneeded as well.
If vendors noticed that this was possible, we'd probably get more binary userspace drivers for USB devices. I pass no judgement here as to whether this would be good or bad.
- Adrian Cox
Humboldt Solutions Ltd.
Quoted 3 lines · Adrian Cox
USB serial drivers could be implemented in userspace given a 2.6 version of Rogier Wolff's userspace serial patch:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.1/att-1075/01-patch-2.4.20.trueport-12-mrt
I'd rather not. I use my USB serial device for a boot console, support for which is currently in 2.6. With userspace USB serial drivers I would need to wait for userspace to come up, useless if I want to watch boot output.
Cheers,
Kyle Moffett