GPLv2 enforcement

Posted Mar 22, 2007 8:25 UTC (Thu) by bug1 (guest, #7097)
In reply to: GPLv2 enforcement by ekj
Parent article: The Torvalds Transcript (InformationWeek)

The wrapper is probably a derivate work of both Linux and the windows driver.

If it is, then to distribute the wrapper in compliance with GPLv2 you have to have the source to the windows driver as well as Linux.

to post comments

GPLv2 enforcement

Posted Mar 22, 2007 9:09 UTC (Thu) by malor (guest, #2973) [Link] (3 responses)

You're clearly and unambiguously wrong about this.

Say, oh, Broadcom releases Windows drivers for their wireless chips. They work nicely in Windows.

Then the LinuxAnt project comes along and writes a wrapper that allows you to load the the Broadcom driver under Linux. That driver knows nothing about Linux; it thinks it's being loaded under Windows.

LinuxAnt is required to release their source code, because their module is obviously a derived work of the kernel. They are not, however, required to do so with the Broadcom source code, and neither is Broadcom. It wasn't developed for Linux and knows nothing about it, so it cannot be a derived work. It is really that simple.

By your argument, if we write a special wrapper to let Windows itself run under Linux, suddenly Windows becomes a derived work and Microsoft loses the ability to sell it without source code.

You're really trying to go after NVidia's binary blob approach here. I think they are immune; it's my understanding that their binary is just the Windows driver, and they wrap it in a glue layer. That doesn't make the binary blob a derived work.

GPLv2 enforcement

Posted Mar 22, 2007 11:00 UTC (Thu) by Wol (subscriber, #4433) [Link]

Plus it's only a copyright infringement by the DISTRIBUTOR.

If the distribution downloads the blob from NVidia on installation, who's breaking copyright? Not the distro, they never mixed GPL and proprietary. Not NVidia, they own it. And not the user, they had NVidia's permission.

It is PERFECTLY LEGAL to mix GPL and proprietary code. You just can't distribute the result. If I wanted to ship a program that was a mix of proprietary and GPL, I would simply ship a build environment. All the GPL as source, the proprietary as object modules. Get the user to run a make script to build the program. ALL LEGAL AND ABOVE BOARD.

It just wouldn't look good to a user, and I wouldn't do it because I don't think it's in the spirit of the GPL. But it's perfectly legal ...

Cheers,
Wol

GPLv2 enforcement

Posted Mar 22, 2007 11:00 UTC (Thu) by thebluesgnr (guest, #37963) [Link]

If LinuxAnt distributes only the GPL loader and nothing more it is obviously not violating the license.

The problem is distributing the loader and proprietary bits together, as nVidia does.

Also, take for example a distribution that ships such driver with the kernel. They distribute a version of Linux that "can accelerate nVidia cards", which requires modifications to Linux which they don't make fully available. IMO they're clearly violating the GPL.

GPLv2 enforcement

Posted Mar 22, 2007 11:07 UTC (Thu) by bug1 (guest, #7097) [Link]

According to the US gov, a derivative work is, "a work that is based on (or derived from) one or more already existing works" (1)

Could the LinuxAnt wrapper (compatibility layer) be written without the windows broadcom driver, without the broadcom driver does the compatibility layer have a purpose ?

I think most real people can see there has to be some sort of dependency there... But maybe the compatibility layers dependence is through a standard interfaces, which are allowed exceptions in most countries i believe. (but im not sure how that effects the GPLv2).

You misunderstand me in your windows example, what im claiming is that the compatibility layer is the derivative work of both layers, the GPL requires athe source of dependencies be distributable. There are no requirements placed on either layer unless they want to be legally compatible with the compatibility layer.

If Microsoft doesnt distribute this hypothetical microsoft/linux compatibility layer they dont have to do anything.

But its all depends on the interfaces, if it uses standard interfaces to windows then the compatibility layer is probably ok, but as you suggest in your first post, only a judge can say for sure.

Another example would be shell script, it serves no purpose without a shell, so it is dependent on _a_ shell, but the shell is a standard interface (POSIX SUS), there are any number of shells that can interpret it, so the script isnt a dependency on any specific shell.

Can the linuxAnt compatibility layer claim the same sort of independence from the windows broadcom driver, does it access the driver directly, or _only_ through standard windows calls ?

1) http://www.copyright.gov/circs/circ14.html

GPLv2 enforcement

Posted Mar 22, 2007 17:43 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

I was pretty convinced of this also for a while.

But I was corrected.

The FSF and friends stating that linking code against GPL code would require that all the code is GPL is simply _wrong_ and _misleading_.

The reality of the matter is that it's up to a Judge to decide what is and what is not derived work. The GPL is a copyright license and by it's nature is limited by the scope of copyright.

The issue of 'derived work' is _intentially_ left up the open by law and is completely a matter of jurisdiction, interpretation and such things. It is not something that the GPL or FSF or anybody else has any control over.

So the thing is is that you _can_ violate the GPL by having a propriatory kernel module, but not nessicarially all kernel modules are in violation.

The Nvidia Linux driver, at it's core, is the same code as what is used in the Windows driver. Not that I know this for a fact, but it's just that that's what I am told.

Also the OpenAFS driver is based on code that existed long time before Linux even existed.

Both of these drivers are using code that existed completely independant from any sort of code that is in the Linux kernel.

Sure they know about kernel internals and such things, but that is required to make the software compatable and modifing code for compatability doesn't mean that it's derived, right? Of Course not.

Now with Linux you have all this modularity. You have the VFS and all sorts of functionality that people remove from individual drivers and then lump it all together in one system.

Like sound drivers and the sound core.
Or Sata drivers and libata and the scsi subsystem.

Now if I was to try to make a propriatory sound card driver, but used a crapload of alsa functionality to do that, then I would more then likely be in violation of the license and any kernel developer in any parts of Alsa would be be free to sue the pants off me.

GPLv2 enforcement

Posted Mar 23, 2007 6:39 UTC (Fri) by gmaxwell (guest, #30048) [Link] (1 responses)

>The FSF and friends stating that linking code against GPL code would require >that all the code is GPL is simply _wrong_ and _misleading_.

>The reality of the matter is that it's up to a Judge to decide what is and >what is not derived work. The GPL is a copyright license and by it's nature >is limited by the scope of copyright.

You were corrected incorrectly, or at least incompletely.

When someone other than the copyright holder distributes GPLed covered software, he does so only by the good graces of the license. The license could, for example, demand that the software only be distributed inside fortune cookies.

A court might decide to invalidate an instance of the license, but without a license you are not able to distribute the software, at least not without performing an actionable copyright infringement.

Thus, in cases where both GPL and non-free parts are distributed by the same party the license can effectively enforce whatever byzantine interpretation of derivative is desired.

The GPLv3 specifically avoids standard legal terms in order to avoid creating confusion like this. Instead the license adopts new terms and defines them clearly in the license.

Obviously the case of separate distribution is another matter entirely, but I'm not aware of anyone sane trying to argue against such cases on legal grounds.

GPLv2 enforcement

Posted Mar 23, 2007 7:22 UTC (Fri) by drag (guest, #31333) [Link]

Well distribution is covered elsewere the license also. Don't forget that.

Also, as you are aware from Microsoft EULA goes.. just because somebody has something in a license it doesn't mean that it's enforcable, even if you agree to it. I don't know how far that goes.

But there is a nasty little clause in the GPLv2 that goes as follows:
(in section 2)

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

So you _can_ distribute non-derivative (see the portion immediately before the part I quoted.) work along with GPL'd software then the GPLv2 license expressly states that it is not covered under the terms of the GPLv2 license.

In other words,
A: If code is non-derivative then it's not covered under the terms of the GPLv2.
And
B: The license expressly allows it's distribution along side non-GPL works.
So
C: Therefore if a kernel module is non-deravitive then it's legal to distribute it along with the kernel.

IF its non-derivative. It's gray.. so some can and will violate while others won't.

("Deravitive" IS a well established legal term, btw. It's defined as part of the US copyright code. Of course in other countries this may vary, but I am operating under US law.)

http://www4.law.cornell.edu/uscode/html/uscode17/usc_sec_...