Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Defence of the GPL realm (The H)
Posted Dec 17, 2012 22:45 UTC (Mon) by dlang (✭ supporter ✭, #313)
It's hard to claim that something developed for a different OS is derivative of the Linux kernel.
There are also cases like AFS where the filesystem existed before Linux, in those cases it's hard to argue that something that existed before Linux is derivative of the Linux kernel.
For the other cases, it boils down to nobody taking the time to go through all the legal hassles of pursuing the lawsuit. It's quite a hassle, and in most cases there is a rather limited benefit (see Rob Landley's comments on the lack of benefit from the busybox lawsuits and his reasons for withdrawing from GPL compliance efforts) It takes really annoying someone to trigger action.
Posted Dec 18, 2012 6:30 UTC (Tue) by gowen (guest, #23914)
I'm not saying they would lose (results would probably depend strongly on jurisdiction), but the risk of losing and the consequences of losing would make it unlikely that anyone will ever actually go to court. The doubt acts as a strong to comply. The kernel community may have legal opinion that their case has merits, but you can bet that NVIDIA has legal opinion supporting them too.
Posted Dec 18, 2012 9:52 UTC (Tue) by farnz (guest, #17727)
While I'm not a lawyer, I've obtained advice on this subject before. I'll try and summarize it here. Note that I'm deliberately not identifying my jurisdiction here - it's not legal advice, and may not apply where you are, it's just a summary of a discussion I've had with someone who's qualified to give such advice if you pay them.
The legal situation in my jurisdiction is likely to be that the module as component parts (i.e. the blob .o, and the shim source) is legally acceptable - you are being given a set of components written to an API that the kernel implements, and as long as the two are not combined, only the copyright holder of the binary blob components you've been given can control redistribution (so, in the case of the NVIDIA blob, you can distribute the binary blob plus the shim source freely, as that's what NVIDIA says is OK).
My lawyer suspected this theory would continue to hold if you distributed the compiled blob for a specific kernel version, as long as you distributed it independently of the kernel (e.g. if NVIDIA provided precompiled binaries for RHEL 5's kernel), but was less confident of this pronouncement. The legal reasoning would be that the module was not a derived work - it was written to the Linux functional API only, which is not protected by copyright law.
Where you hit problems is when you try to distribute both the kernel and the binary module together. At this point, my lawyer thinks you have to comply with the licenses on both parts at once - as the kernel license requires source under GPL, and the binary license says you can't distribute source, you're stuck breaking one set of obligations or the other, and thus hit the GPL's catch-22 - either you comply with the GPL (which means supplying NVIDIA's secret source in breach of your license from NVIDIA), or you comply with NVIDIA's license, which means that you cannot be licensing the kernel under the GPL, and thus cannot point to any license that permits you to distribute the kernel.
Note that my lawyer believed that distributing the two bits separately for self-assembly by your end customer is acceptable, as in that case it's possible that the customer will not assemble them, but instead will use the binary blob with a differently licensed kernel (e.g. if someone wrote a BSD-licensed shim layer for NetBSD that could make the NVIDIA blob work). It's distributing the combination together that's a problem; if the end-user has to go to enough extra effort to combine them, it's no longer a problem.
This affects (for example) embedded systems; if I build an arcade machine around a PC with NVIDIA graphics, I have to get the final owner of the machine to combine the NVIDIA module with the kernel before it works; I am not allowed to do that for them, as the resulting machine is no longer legally redistributable thanks to copyright law. In turn, the only plausible attack on NVIDIA is via this embedded route - find a customer who NVIDIA can't afford to lose who's distributing the binary blob together with the matching kernel binary, and go for them, in the knowledge that NVIDIA will step in to protect them.
Posted Dec 19, 2012 1:43 UTC (Wed) by JoeBuck (subscriber, #2330)
But in that case, the components were very tightly coupled: the Objective-C extensions were designed to work with GCC and not with anything else. For NVidia, the driver binary blob is the same for Windows and Linux, only the shim layer is different and they give you the code for that. That would probably present a much tougher case for someone interested in suing for infringement, especially since NVidia isn't distributing the kernel itself.
Posted Dec 18, 2012 8:16 UTC (Tue) by paulj (subscriber, #341)
Posted Dec 18, 2012 10:54 UTC (Tue) by airlied (subscriber, #9104)
There has been cases of distros/live cd that did ship both being hit with CnD from kernel devs.
Posted Dec 18, 2012 12:54 UTC (Tue) by pboddie (subscriber, #50784)
Again, farnz makes the crucial point upthread: it's all about the distribution. When you have someone distributing things to be used together as one system and where the nature of the GPL-licensed software signals the intent that anything taking advantage of that software must adhere to the conditions of the GPL, the "derived work" defence is merely something that can be used to limit the claims of the GPL if the relevant copyright law imposes restrictions on what licences can require of others.
So, if you take something which deliberately says that "you had better be able to release the source for all this" if you distribute your Linux system "with added Nvidia magic" and then combine it with the Nvidia drivers for which you don't have sources, then you really have to have a better argument than "they're not really touching (come on, your honour!)". After all, there are plenty of licence agreements that impose more peculiar and arbitrary restrictions on how works are used.
Posted Jan 7, 2013 0:05 UTC (Mon) by DHR (guest, #81356)
So: is this a license violation? I guess not since a majority of the smart phone world would then be uncompliant.
Posted Jan 7, 2013 5:21 UTC (Mon) by dlang (✭ supporter ✭, #313)
It gets hard when a lot of the 'binary drivers' are userspace components like the camera drivers on most devices.
Posted Jan 7, 2013 5:24 UTC (Mon) by jrn (subscriber, #64214)
Posted Dec 20, 2012 16:04 UTC (Thu) by bkuhn (subscriber, #58642)
I discussed the issue of Nvidia in an interview on Linux Outlaws 290.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds