LinuxLists.cc - more files with licenses that aren't GPL-compatible

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Jun 15, 2004, at 20:38, Eric wrote:
> On Tuesday 15 June 2004 03:57 pm, Christoph Hellwig wrote:
>> 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

>> 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."

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.

> 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:
> [...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...]
>
> 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

2004-06-16 04:12:04

[permalink] [raw]

Subject: RE: more files with licenses that aren't GPL-compatible

> > 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.

> > 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

> > which makes the kernel as whole unredistributable. A similar license

Bingo.

> 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.

> Please correct me if I am wrong.

You *definitely* are wrong. The entirety of the GPL would be negated if you
were correct.

DS

2004-06-16 20:34:49

by Erik Harrison

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Tue, 15 Jun 2004 21:11:00 -0700, David Schwartz <[email protected]> wrote:
>
>
> > > 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.

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
>
> > > 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
>
> > > which makes the kernel as whole unredistributable. A similar license
>
> Bingo.
>
> > 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
>
> > 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/
>

2004-06-16 20:37:55

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Wed, Jun 16, 2004 at 04:34:25PM -0400, Erik Harrison wrote:
> > 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).

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.

2004-06-16 21:22:59

[permalink] [raw]

Subject: RE: more files with licenses that aren't GPL-compatible

> On Tue, 15 Jun 2004 21:11:00 -0700, David Schwartz
> <[email protected]> wrote:

> > 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).

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

2004-06-16 22:45:32

by Oliver Neukum

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

Am Mittwoch, 16. Juni 2004 23:21 schrieb David Schwartz:
> ? ? 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

2004-06-16 22:48:09

by Helge Hafting

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Wed, Jun 16, 2004 at 04:34:25PM -0400, Erik Harrison wrote:
> On Tue, 15 Jun 2004 21:11:00 -0700, David Schwartz <[email protected]> wrote:
> >
> >
> > > > 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.
>
> 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

2004-06-16 23:45:39

[permalink] [raw]

Subject: RE: more files with licenses that aren't GPL-compatible

> Am Mittwoch, 16. Juni 2004 23:21 schrieb David Schwartz:

> > ? ? 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.

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?

> 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

2004-06-16 23:49:17

by Wichmann, Mats D

[permalink] [raw]

Subject: RE: more files with licenses that aren't GPL-compatible

>> > 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).

Please keep distinct "ship with" in the sense of /inside/ the
kernel and "ship with" in the sense of on the same distribution
media. The GPL also has explicit wording for the latter
(you've already been quoted the words on the former):

"In addition, mere aggregation of another work not based on the
Program with the Program (or with a work based on the Program)
on a volume of a storage or distribution medium does not bring
the other work under the scope of this License. "

I can't imagine anyone putting the Mozilla logo inside the
kernel, but if they do, as mentioned, that's a problem if
its license is not GPL.

-- mats

Normal disclaimers apply: not a lawyer, not speaking on behalf
of my employer, etc. etc.

2004-06-17 01:18:18

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Jun 16, 2004, at 19:47, Wichmann, Mats D wrote:
> Please keep distinct "ship with" in the sense of /inside/ the
> kernel and "ship with" in the sense of on the same distribution
> media. The GPL also has explicit wording for the latter
> (you've already been quoted the words on the former):

Well the firmware is compiled to bytes within the _same_file_ as
the rest of the kernel. That would match the usage of "inside" the
kernel. Even if it's just a file with firmware bytes distributed in the
same tar file it's still very iffy.

> "In addition, mere aggregation of another work not based on the
> Program with the Program (or with a work based on the Program)
> on a volume of a storage or distribution medium does not bring
> the other work under the scope of this License. "

But we're not talking about an instance of aggregation here, this
is a derivative work.

Cheers,
Kyle Moffett

2004-06-17 07:59:30

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Thu, Jun 17, 2004 at 12:45:32AM +0200, Oliver Neukum wrote:
> 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.

2004-06-17 08:43:45

by Oliver Neukum

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

Am Donnerstag, 17. Juni 2004 09:59 schrieb Christoph Hellwig:
> On Thu, Jun 17, 2004 at 12:45:32AM +0200, Oliver Neukum wrote:
> > 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

2004-06-17 08:47:58

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Thu, Jun 17, 2004 at 10:43:40AM +0200, Oliver Neukum wrote:
> Am Donnerstag, 17. Juni 2004 09:59 schrieb Christoph Hellwig:
> > On Thu, Jun 17, 2004 at 12:45:32AM +0200, Oliver Neukum wrote:
> > > 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.

2004-06-17 10:03:47

by Martin Diehl

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Thu, 17 Jun 2004, Christoph Hellwig wrote:

> On Thu, Jun 17, 2004 at 12:45:32AM +0200, Oliver Neukum wrote:
> > 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 =(:-(

>From the maintenance POV of course it would be much better not to have it
aggregated with the kernel sources.

SCNR
Martin

2004-06-17 10:14:45

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Thu, Jun 17, 2004 at 12:09:23PM +0200, Martin Diehl wrote:
> >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.

2004-06-17 13:47:28

by Timothy Miller

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

Oliver Neukum wrote:
> Am Mittwoch, 16. Juni 2004 23:21 schrieb David Schwartz:
>
>> 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.

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. :)

2004-06-17 13:52:06

by Timothy Miller

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

David Schwartz wrote:

> 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.

2004-06-17 15:36:00

by Adam J. Richter

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On 2004-06-15, Christoph Hellwig wrote:
>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?

I pointed out this problem years ago, during 2.4. Some may
think this was going overboard, but, to avoid legal liability, I
closed the FTP area of the ftp.yggdrasil.com kernel mirror that
included the kernels with the infringing firmware (not that many
people used it then).

At that time, I also posted patches to remove the code
and a GPL'ed utility to automatically load the right firmware
from userland on a hotplug event when the device is plugged in. At
least one person posted that he tried the code and it worked fine.

I believe that Greg Kroah-Hartmann said that the changes
should go into 2.5. I'm still waiting, although I don't know if
I even have a copy of the user level helper code anymore.

I am not a lawyer, so please do not take the following as
legal advice.

I believe that distribution of Linux kernel binaries that
compile in this firmware is direct copyright infringment, and
that distribution of Linux kernel modules that compile in
this firmware is contributory copyright infringement (to the direct
infringmenet that occurs when the image is created in RAM, and
there are US court cases that say that copying into RAM is copying
for the purposes of copyright).

The United States Copyright Office has issued a copyright
registration to Yggdrasil Computing for some software in the Linux
USB serial drivers. Yggdrasil Computing has never given permission
for distribution of GPL-incompatible firmware with that software.

__ ______________
Adam J. Richter \ /
[email protected] | g g d r a s i l

2004-06-17 15:44:34

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

Adam J. Richter writes:

> I believe that distribution of Linux kernel binaries that
> compile in this firmware is direct copyright infringment, and
> that distribution of Linux kernel modules that compile in
> this firmware is contributory copyright infringement (to the direct
> infringmenet that occurs when the image is created in RAM, and
> there are US court cases that say that copying into RAM is copying
> for the purposes of copyright).
>
> The United States Copyright Office has issued a copyright
> registration to Yggdrasil Computing for some software in the Linux
> USB serial drivers. Yggdrasil Computing has never given permission
> for distribution of GPL-incompatible firmware with that software.

The first "official" version of Linux that included USB serial code
that mentioned you (Adam Richter and/or Yggdrasil) was 2.4. That same
version included the same binary firmware you complained about in
2001, and the changelog in usbserial.c makes it clear that *at least*
the WhiteHEAT firmware was already present when you contributed your
code.

Would you explain why your claim of copyright infringement is not
estopped by the pre-existing condition of firmware being present?

Michael Poole

2004-06-17 18:19:25

by Adam J. Richter

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Thu, Jun 17, 2004 at 11:44:29AM -0400, Michael Poole wrote:
> The first "official" version of Linux that included USB serial code
> that mentioned you (Adam Richter and/or Yggdrasil) was 2.4. That same
> version included the same binary firmware you complained about in
> 2001, and the changelog in usbserial.c makes it clear that *at least*
> the WhiteHEAT firmware was already present when you contributed your
> code.
>
> Would you explain why your claim of copyright infringement is not
> estopped by the pre-existing condition of firmware being present?

Why would it be, and what kind of stopping ("estoppel")
are you referring to?

I do not believe that when one contributes to Linux that
one is promising not to pursue other copyright problems anywhere
elsewhere in the code. If you can point to a court decision or law
that says something analogous, I would be interesting in hearing
about it.

I believe the pre-exising condition, if it was pre-existing,
of the firmware being present in a few infringing drivers among many
non-infringing drivers would not mean that permission was granted
to produce a derivative work comingling the few illegal drivers
(or even prove prior knowledge of the few illegal drivers).

I know I have been complaining about the infringing drivers
and asking that people stop infringing approximately since I became
aware of the infringement.

Again, I'm not a lawyer, so please do not use my layman's
opinions as legal advice.

--
__ ______________
Adam J. Richter \ /
[email protected] | g g d r a s i l

2004-06-17 18:43:32

[permalink] [raw]

Subject: RE: more files with licenses that aren't GPL-compatible

> David Schwartz wrote:

> > 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?

That would satisfy me.

> 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

2004-06-17 19:04:41

by Timothy Miller

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

David Schwartz wrote:

>>
>>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.

2004-06-17 19:15:31

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Jun 17, 2004, at 13:09, Adam J. Richter wrote:
> I do not believe that when one contributes to Linux that
> one is promising not to pursue other copyright problems anywhere
> elsewhere in the code. If you can point to a court decision or law
> that says something analogous, I would be interesting in hearing
> about it.

If someone distributes _on_their_own_ (site, CDs, whatever) copies
of Linux with their copyrighted code in it, or contributes copyrighted
code _that_they_own_, they are giving someone a license to use
against them. That is actually one of the difficulties SCO is facing
right now in court; _they_ distributed copies of Linux _including_ any
code that they may claim is copyrighted. Since they have the right to
license such code, any license that appears to be associated with it
when they distribute it becomes valid even if it was not before. If you
distribute a copy of Linux under the GPL that contains code you
claim is violating your copyright, then I don't believe you have a leg
to stand on, legally.

> I believe the pre-exising condition, if it was pre-existing,
> of the firmware being present in a few infringing drivers among many
> non-infringing drivers would not mean that permission was granted
> to produce a derivative work comingling the few illegal drivers
> (or even prove prior knowledge of the few illegal drivers).

I'm not sure what you mean here, could you rephrase it?

> Again, I'm not a lawyer, so please do not use my layman's
> opinions as legal advice.

Same here!

Cheers,
Kyle Moffett

2004-06-17 19:50:35

by Greg KH

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Thu, Jun 17, 2004 at 11:29:55PM -0700, Adam J. Richter wrote:
> I believe that Greg Kroah-Hartmann said that the changes
> should go into 2.5. I'm still waiting, although I don't know if
> I even have a copy of the user level helper code anymore.

No one ever sent me patches to do this during the 2.5 development
series. That's why nothing changed.

thanks,

greg k-h

2004-06-17 19:55:14

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Thu, Jun 17, 2004 at 11:05:08AM -0700, Greg KH wrote:
> On Thu, Jun 17, 2004 at 11:29:55PM -0700, Adam J. Richter wrote:
> > I believe that Greg Kroah-Hartmann said that the changes
> > should go into 2.5. I'm still waiting, although I don't know if
> > I even have a copy of the user level helper code anymore.
>
> No one ever sent me patches to do this during the 2.5 development
> series. That's why nothing changed.

WAKE UP!

We have files in the kernel we can't distribute. We have a copyright
holder in that particular area who told you to stop it. I told you
it's not okay and I'm a major kernel copyright holder to. Do Adam & me
need to ask the vendors and mirrors to take the kernel tarball down
first before you react?

In fact if I see no action in, let's say a week, I'll probably do
exactly that.

2004-06-17 20:22:46

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

Adam J. Richter writes:

> On Thu, Jun 17, 2004 at 11:44:29AM -0400, Michael Poole wrote:
>> The first "official" version of Linux that included USB serial code
>> that mentioned you (Adam Richter and/or Yggdrasil) was 2.4. That same
>> version included the same binary firmware you complained about in
>> 2001, and the changelog in usbserial.c makes it clear that *at least*
>> the WhiteHEAT firmware was already present when you contributed your
>> code.
>>
>> Would you explain why your claim of copyright infringement is not
>> estopped by the pre-existing condition of firmware being present?
>
> Why would it be, and what kind of stopping ("estoppel")
> are you referring to?
[snip]

>From what I can see, the USB serial drivers included firmware images
before you contributed to that code. If you contributed changes with
reckless disregard to their presence (i.e. should have known they were
there and you did not say "I contribute this on the condition that the
maintainers work to remove binary firmware"), I believe that you
accepted their presence.

http://www.ipwatchdog.com/equitable_estoppel.html discusses equitable
estoppel vis-a-vis patent rights (which are treated similarly to
copyrights by many courts). When you contributed your changes to the
USB maintainers, they -- and later redistributors -- inferred that you
would not allege copyright infringement by applying your changes to
the kernel that existed then.

The first binary firmware I found in the kernel was included in linux
2.0, released in June 1996. There might be an earlier case. You
might argue plausible ignorance of that particular driver, but you as
an individual have a harder claim to demonstrate. See below.

> I know I have been complaining about the infringing drivers
> and asking that people stop infringing approximately since I became
> aware of the infringement.

You managed to contribute some significant creative (copyrightable)
change to the USB serial code without noticing that *a quarter* of the
files in that directory were headers that defined firmware? I do not
know if a court would take such a claim seriously, but as a software
developer, I do not.

> Again, I'm not a lawyer, so please do not use my layman's
> opinions as legal advice.

I am aware of several reasons your writings are not legal advice. As
another non-lawyer, though, I wanted to give you a chance to defend
your claims before I decide they are entirely meritless.

Michael

2004-06-17 20:23:42

by Greg KH

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Thu, Jun 17, 2004 at 09:54:58PM +0200, Christoph Hellwig wrote:
> On Thu, Jun 17, 2004 at 11:05:08AM -0700, Greg KH wrote:
> > On Thu, Jun 17, 2004 at 11:29:55PM -0700, Adam J. Richter wrote:
> > > I believe that Greg Kroah-Hartmann said that the changes
> > > should go into 2.5. I'm still waiting, although I don't know if
> > > I even have a copy of the user level helper code anymore.
> >
> > No one ever sent me patches to do this during the 2.5 development
> > series. That's why nothing changed.
>
> WAKE UP!
>
> We have files in the kernel we can't distribute.

I do not agree with that statement. Those files were placed in the
kernel tree in good faith that they could be redistributed. I have the
email trails to prove it. If the wording is somehow not correct to
convey this intent, I will be quite willing to fix it.

> We have a copyright holder in that particular area who told you to
> stop it.

I do not agree that this copyright holder has anything to do with the
code in that area at all. I only see two named copyright holders on the
drivers/usb/serial/keyspan.c file:
(C) Copyright (C) 2000-2001 Hugh Blemings <[email protected]>
(C) Copyright (C) 2002 Greg Kroah-Hartman <[email protected]>

Adam did submit a small patch to the file back in 11/01/2000, but as to
if that constitutes a multiple copyright of that file, I'll leave to the
IP lawyers to decide.

> I told you it's not okay and I'm a major kernel copyright holder to.

For the emi26 firmware image, yes, I agree the wording is not very
clear, but I have documentation that the original owner of the file gave
permission to have these files included in the kernel tree. I will add
the proper wording from the keyspan firmware image to that file in my
tree and send it to Linus in the next series of USB patches.

As for the wording of the keyspan firmware images, I do not agree that
this is not allowed. We have been over this many times in the past, and
I've had IP lawyers look at the current wording and implementation of
these files and they have given me their blessing that it is ok to do
so.

> Do Adam & me need to ask the vendors and mirrors to take the kernel
> tarball down first before you react?

Again, I am reacting to the emi26 image. The keyspan dispute I do not
agree with. We are free to disagree with each other here, but until I
receive a contrary legal opinion, I will insist that these files remain.

thanks,

greg k-h

2004-06-17 20:30:22

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Thu, Jun 17, 2004 at 01:22:08PM -0700, Greg KH wrote:
> > WAKE UP!
> >
> > We have files in the kernel we can't distribute.
>
> I do not agree with that statement. Those files were placed in the
> kernel tree in good faith that they could be redistributed. I have the
> email trails to prove it. If the wording is somehow not correct to
> convey this intent, I will be quite willing to fix it.

You can't fix it. Talk to keyspan and get it a 2clause BSD or GPL
header and the problem is solved.

> > Do Adam & me need to ask the vendors and mirrors to take the kernel
> > tarball down first before you react?
>
> Again, I am reacting to the emi26 image. The keyspan dispute I do not
> agree with. We are free to disagree with each other here, but until I
> receive a contrary legal opinion, I will insist that these files remain.

Read through the license, especially:

--
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.
--

"as part of the linux kerrnel" is a violation of the GPL, because I
can't use it in my kernel fork, or hurd if they ever get usb support.
Also note that it doesn't mention modification at all. There's no
way you can legally link it into a GPL'ed program. I don't know what
you're IP lawyer are smoking, but I could count a few laywers I've
talked to that are active in the Free Software and Creative Commons
world that absolutely disagree with you. What you say is basically
the GPL is void and works under it are placed in the public domain.

Got a paycheck from SCO recently?

2004-06-17 20:45:44

by Flavio Stanchina

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

Kyle Moffett wrote:
> If someone distributes _on_their_own_ (site, CDs, whatever) copies
> of Linux with their copyrighted code in it, or contributes copyrighted
> code _that_they_own_, they are giving someone a license to use
> against them. That is actually one of the difficulties SCO is facing
> right now in court; _they_ distributed copies of Linux _including_ any
> code that they may claim is copyrighted. Since they have the right to
> license such code, any license that appears to be associated with it
> when they distribute it becomes valid even if it was not before. If you
> distribute a copy of Linux under the GPL that contains code you
> claim is violating your copyright, then I don't believe you have a leg
> to stand on, legally.

Your argument applies to the SCO case because their code (if there is
any, which nobody but SCO still believes is the case) did *not* have a
license attached to it that didn't allow modification, redistribution or
whatever else the GPL requires; otherwise they wouldn't have trouble
demonstrating which code it is they're talking about. So any sane person
would understand that they knowingly released it under the GPL: if
they'll try to argue that they didn't know the kernel was covered by the
GPL, I don't think the judge will go for much less than capital
punishment when he stops laughing.

In this case, if I followed the discussion correctly, there are files
and binary blobs in the kernel whose license explicitly disallows some
of the freedoms the GPL grants. So they *have* to get out of the kernel
proper *now*, period. There is no other choice, legally.

Once those files and stuff are out of the kernel, we can think of a
solution that works from both a technical and a legal perspective, such
as loading firmware from external files (which users will have to
download themselves from vendors' sites -- we can't distribute them in
any form if they don't change the license). Modules under a non-GPL
license are a different can of worms: many people believe they are
violating the GPL even if they remain outside of the kernel proper
because they are obviously a derivative work of the kernel. So far AFAIK
nobody sued NVidia, ATI or anyone else for distributing non-GPL modules,
but they can _not_ stay in the kernel. I wonder how and why they were
accepted in the first place.

--
Ciao, Flavio

2004-06-17 20:54:41

by Greg KH

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Thu, Jun 17, 2004 at 10:30:05PM +0200, Christoph Hellwig wrote:
> On Thu, Jun 17, 2004 at 01:22:08PM -0700, Greg KH wrote:
> > > WAKE UP!
> > >
> > > We have files in the kernel we can't distribute.
> >
> > I do not agree with that statement. Those files were placed in the
> > kernel tree in good faith that they could be redistributed. I have the
> > email trails to prove it. If the wording is somehow not correct to
> > convey this intent, I will be quite willing to fix it.
>
> You can't fix it. Talk to keyspan and get it a 2clause BSD or GPL
> header and the problem is solved.

I don't believe that is necessary.

> > > Do Adam & me need to ask the vendors and mirrors to take the kernel
> > > tarball down first before you react?
> >
> > Again, I am reacting to the emi26 image. The keyspan dispute I do not
> > agree with. We are free to disagree with each other here, but until I
> > receive a contrary legal opinion, I will insist that these files remain.
>
> Read through the license, especially:
>
> --
> 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.
> --
>
> "as part of the linux kerrnel" is a violation of the GPL, because I
> can't use it in my kernel fork, or hurd if they ever get usb support.

"other Open Source operating system kernel" does allow this.

Remember, the point here is that this is code that does not run on the
same processor that Linux runs on. It is a blob that we copy down to
the other processor on the device.

> Also note that it doesn't mention modification at all.

Because there's nothing here you can modify.

> There's no way you can legally link it into a GPL'ed program.

I see we disagree on this point, and that's fine.

> I don't know what you're IP lawyer are smoking, but I could count a
> few laywers I've talked to that are active in the Free Software and
> Creative Commons world that absolutely disagree with you. What you
> say is basically the GPL is void and works under it are placed in the
> public domain.

Again, I am not saying that at all, never did. My position stands until
either Linus changes his mind about the issue, or a lawyer that I trust
tells me otherwise. As you are neither, I accept the fact that we will
disagree on this.

> Got a paycheck from SCO recently?

And the reason you attack me personally for this is why?

I get a paycheck from the company SCO has brought to court, as everyone
here well knows.

thanks,

greg k-h

2004-06-17 20:53:16

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Jun 17, 2004, at 16:51, Flavio Stanchina wrote:
> Your argument applies to the SCO case because their code (if there is
> any, which nobody but SCO still believes is the case) did *not* have a
> license attached to it that didn't allow modification, redistribution
> or whatever else the GPL requires; otherwise they wouldn't have
> trouble demonstrating which code it is they're talking about. So any
> sane person would understand that they knowingly released it under the
> GPL: if they'll try to argue that they didn't know the kernel was
> covered by the GPL, I don't think the judge will go for much less than
> capital punishment when he stops laughing.

I wasn't discussing those particular firmware files. I definitely
agree that they must get out of the kernel immediately. I was
discussing a different piece of code someone was suing over,
sorry for the confusion.

Cheers,
Kyle Moffett

2004-06-17 21:05:29

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

Flavio Stanchina writes:

> In this case, if I followed the discussion correctly, there are files
> and binary blobs in the kernel whose license explicitly disallows some
> of the freedoms the GPL grants. So they *have* to get out of the
> kernel proper *now*, period. There is no other choice, legally.

Sure there is: To the extent that there is a real license problem,
work with the copyright owner(s) for the files and binary blobs to
resolve the problem. If the copyright owner intentionally contributed
them to Linux, they should be willing to resolve it by changing their
license. Contrary to your (and SCO's) allegations, kernel gatekeepers
generally exercise care with respect to new contributions.

If you see a lit match in a movie theater, it is reasonable to ask the
person to put it out *before* you shout "fire" and evacuate.

Michael

2004-06-17 21:10:35

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Thu, Jun 17, 2004 at 05:05:22PM -0400, [email protected] wrote:
> Sure there is: To the extent that there is a real license problem,
> work with the copyright owner(s) for the files and binary blobs to
> resolve the problem. If the copyright owner intentionally contributed
> them to Linux, they should be willing to resolve it by changing their
> license. Contrary to your (and SCO's) allegations, kernel gatekeepers
> generally exercise care with respect to new contributions.
>
> If you see a lit match in a movie theater, it is reasonable to ask the
> person to put it out *before* you shout "fire" and evacuate.

Greg has made it pretty clear that he intentionally accepted a GPL-
incomptible license. So I wouldn't trust your Gatekeeper too much, it
seems some don't of them don't understand the GPL at all.

2004-06-17 21:37:32

by Flavio Stanchina

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

[email protected] wrote:
> Sure there is: To the extent that there is a real license problem,
> work with the copyright owner(s) for the files and binary blobs to
> resolve the problem. [...]

Yes, of course that would be fine. I started with the implicit
assumption that the license could not change, sorry.

This might open another can of worms however. Once you get a binary blob
into the kernel and you know that it really is code for an embedded
microprocessor or such, what is the "preferred form of the work for
making modifications to it"? Wouldn't that be source code in whatever
language that blob is written in? Wouldn't that also require a toolchain
to build it? MY opinion is that it' much better to get it out of the
kernel anyway.

> Contrary to your (and SCO's) allegations, kernel gatekeepers
> generally exercise care with respect to new contributions.

I did not allege anything like that. I never doubted that Linus and most
other maintainers do, in fact, understand legal things quite well,
contrary to what SCO said or implied several times.

--
Ciao, Flavio

2004-06-18 08:05:30

by Adam J. Richter

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Thu, Jun 17, 2004 at 04:22:42PM -0400, [email protected] wrote:
> http://www.ipwatchdog.com/equitable_estoppel.html discusses equitable
> estoppel vis-a-vis patent rights (which are treated similarly to
> copyrights by many courts). When you contributed your changes to the
> USB maintainers, they -- and later redistributors -- inferred that you
> would not allege copyright infringement by applying your changes to
> the kernel that existed then.

From my reading of that web page, it does not seem to me
that one would have a case of either equitable estoppel or implied
license (for example, "silence alone is generally not sufficient
affirmative conduct to give rise to estoppel"). I've made my
opposition to the illegal drivers clear from the time that I've
been aware of them.

If you are not fabricating claims about inferences
by "the USB maintainers [...] and later distributors", I would
be interested in your citing some historical examples of the
"USB mainatiners" stating this inference and not being corrected.

Also, I apologize in advance if I'm unable to justify
prioritizing time to respond to you further. It does not mean
that I necessarily agree with anything you've said.

--
__ ______________
Adam J. Richter \ /
[email protected] | g g d r a s i l

2004-06-18 09:13:59

by Adrian Cox

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

On Wed, 2004-06-16 at 23:49, Helge Hafting wrote:

> 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.

2004-06-18 11:10:05

[permalink] [raw]

Subject: Re: more files with licenses that aren't GPL-compatible

Adam J. Richter writes:

> On Thu, Jun 17, 2004 at 04:22:42PM -0400, [email protected] wrote:
>> http://www.ipwatchdog.com/equitable_estoppel.html discusses equitable
>> estoppel vis-a-vis patent rights (which are treated similarly to
>> copyrights by many courts). When you contributed your changes to the
>> USB maintainers, they -- and later redistributors -- inferred that you
>> would not allege copyright infringement by applying your changes to
>> the kernel that existed then.
>
> From my reading of that web page, it does not seem to me
> that one would have a case of either equitable estoppel or implied
> license (for example, "silence alone is generally not sufficient
> affirmative conduct to give rise to estoppel"). I've made my
> opposition to the illegal drivers clear from the time that I've
> been aware of them.

Really? I see that one of the previous authors listed on your
copyright filing is Hugh Blemings, listed as "author of keyspan
support for Linux." I will repeat my question: Did you really do
copyrightable work on the USB serial drivers yet somehow fail to
notice the many firmware header files already there?

> If you are not fabricating claims about inferences
> by "the USB maintainers [...] and later distributors", I would
> be interested in your citing some historical examples of the
> "USB mainatiners" stating this inference and not being corrected.

They need not have stated it explicitly; they just have to have relied
on it. People who are sent patches by the patch's author infer by
that submission that including the patch(es) will not lead to claims
of copyright infringement by that author. This is common sense. If
you have any example where someone rejected a patch from the patch's
author out of concern for copyright infringement claims by that
author, I'd like to see it.

There was recent in-depth discussion on debian-legal about further
reasons that would bar your claim of copyright infringement. Since
you declined to answer all of what I wrote before, I will not bore you
by repeating those arguments here.

Michael

2004-06-18 11:21:59