GPLv2 enforcement

Posted Mar 21, 2007 23:42 UTC (Wed) by ekj (guest, #1524)
In reply to: GPLv2 enforcement by orospakr
Parent article: The Torvalds Transcript (InformationWeek)

It's not quite that simple. The *LAW* (and judges interpreting same) defines what is, and what isn't a "derived work". If the law says something or other is not a derived work, there's nothing you can do to change this.

A driver written for Windows, with no knowledge of, interface to, or interest in Linux is clearly not a derived work of Linux.

If someone writes a wrapper (and releases this under GPL) that nevertheless allows the former to be loaded by Linux, then what ?

The wrapper *is* a derived work -- but that's ok, since it's released under GPL anyway. The loaded driver very clearly is not, so whatever the GPL says about it has no influence on it.

to post comments

GPLv2 enforcement

Posted Mar 22, 2007 8:25 UTC (Thu) by bug1 (guest, #7097) [Link] (7 responses)

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.

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

GPLv2 enforcement

Posted Mar 22, 2007 8:29 UTC (Thu) by MKesper (subscriber, #38539) [Link] (2 responses)

This does only apply to things like ndiswrapper, but clearly not to such things like ATI or nvidia (or whatever...) binary drivers. They _have to_ know about kernel details.

GPLv2 enforcement

Posted Mar 22, 2007 14:02 UTC (Thu) by i3839 (guest, #31386) [Link] (1 responses)

Not really. The underlying hardware is the same, so they make certain assumption in their code. How to get to access to the hardware might depend on what kernel is run, but not much more. For that the Nvidia driver has a BSD wrapper.

The GPL doesn't disallow that wrapper, nor does it disallow loading binary only modules at runtime. That wrapper doesn't disallow being linked to the Nvidia binary either.

So if the driver is written independently from Linux (which seems to be the case, as it's a modified Windows driver), Nvidia really doesn't break the GPL.

It only becomes interesting when the driver is distributed together with the kernel, as then the question is whether it's mere aggregation, or a combined work. But even then it isn't Nvidia who's breaking the GPL, but the distributors.

GPLv2 enforcement

Posted Mar 29, 2007 20:15 UTC (Thu) by TRauMa (guest, #16483) [Link]

The BSD wrapper is a derivative work of the kernel. NVidia doesn't have the copyright to the kernel, so it's no BSD wrapper at all, it's a GPL wrapper. Now it's sole purpose is to link itself to a non-GPL-compatible blob... I think a linux copyright holder could make a case out of that, if so inclined?