Weekly Edition
Return to the Announcements page
| |||||||||||||
Defence of the GPL realm (The H)
The H talks
with Bradley Kuhn about GPL compliance.
"Certainly we're in an era where lots of people are scrambling to create business models dancing around the issue of GPL compliance, and in using GPL enforcement in nefarious ways. Our community already has too much of that kind of activity, and I certainly don't want more of that.
If, however, someone wanted to start another non-profit charity to do enforcement, I'd certainly welcome it and help them do it. I also encourage any individuals who hold copyrights in projects that Conservancy currently does active enforcement for – namely, BusyBox, Linux, and Samba – to get in touch with me and join our coalition. That's an easy way for those who hold copyrights to get involved with the work Conservancy's already doing in this area."
(Log in to post comments)
Defence of the GPL realm (The H) Posted Dec 17, 2012 22:23 UTC (Mon) by heijo (guest, #88363) [Link]
Why no attempt to enforce the GPL against nVidia, AMD and the several other companies who release Linux kernel modules without full source?
Defence of the GPL realm (The H) Posted Dec 17, 2012 22:45 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
In the case of NVidia, their code was originally developed for Windows and has a shim layer (which is GPL) that interfaces with their binary blob.
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.
Defence of the GPL realm (The H) Posted Dec 18, 2012 6:30 UTC (Tue) by gowen (guest, #23914) [Link] Also, despite the general acceptance in the kernel community that they're right, there's absolutely no certainty that they'd win. There's no legal precedent to suggest that's the case. And such a ruling would contradict, at least in part, recent ruling that programming to an API is *not* derivation. Similarly, for GPL libraries like readline. As you say, a broad ruling that "module linking means derivation", would mean that some code would be a derivative of code it predates.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.
Defence of the GPL realm (The H) Posted Dec 18, 2012 9:52 UTC (Tue) by farnz (guest, #17727) [Link] 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.
Defence of the GPL realm (The H) Posted Dec 19, 2012 1:43 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] The FSF managed to get Steve Jobs and NeXT to back down on their attempt to use user-does-the-link to get a GCC-based proprietary Objective-C compiler. The argument is that if your R&D team has a running system that combines GPL and proprietary code in one executable, and you build a mechanism that arranges for the same executable to appear on your customer's system, you've made a copy of a work that is derivative of the GPL work, and the technical details of the process don't matter. The lawyers can use abstraction: look, we have a communication channel that makes a perfect copy! How this channel operates does not matter, only the I/O does.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.
Defence of the GPL realm (The H) Posted Dec 18, 2012 8:16 UTC (Tue) by paulj (subscriber, #341) [Link]
NVidias' blob was developed for windows a *long* time ago. NVidia have been doing Linux development along-side since then. We do not know to what extent this has influenced the development of the blob. It could be it's still been kept completely independent of their Linux work, or it could equally been that the blob has had major changes made to it in order to accommodate Linux.
Defence of the GPL realm (The H) Posted Dec 18, 2012 10:54 UTC (Tue) by airlied (subscriber, #9104) [Link]
Also since nvidia don't distribute the Linux kernel and their binary driver at the same time, or same place, it would be even trickier. They do this quite deliberately.
There has been cases of distros/live cd that did ship both being hit with CnD from kernel devs.
Defence of the GPL realm (The H) Posted Dec 18, 2012 12:54 UTC (Tue) by pboddie (subscriber, #50784) [Link]
It's interesting to hear of cease-and-desist orders, certainly.
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.
Defence of the GPL realm (The H) Posted Jan 7, 2013 0:05 UTC (Mon) by DHR (guest, #81356) [Link]
As far as I know, almost all Android devices are distributed with binary Linux kernels and binary device driver modules. These device drivers are often closed-source. In particular, I think all reasonable video drivers are closed source.
So: is this a license violation? I guess not since a majority of the smart phone world would then be uncompliant.
Defence of the GPL realm (The H) Posted Jan 7, 2013 5:21 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
So far, nobody who has standing to do so has considered these to be a license violation enough to take action, so for practical matters they are not.
It gets hard when a lot of the 'binary drivers' are userspace components like the camera drivers on most devices.
Defence of the GPL realm (The H) Posted Jan 7, 2013 5:24 UTC (Mon) by jrn (subscriber, #64214) [Link]
Is nouveau an unreasonable video driver? Or did you mean all reasonable smartphone GPU drivers?
Nvidia issue Posted Dec 20, 2012 16:04 UTC (Thu) by bkuhn (subscriber, #58642) [Link] I discussed the issue of Nvidia in an interview on Linux Outlaws 290.
Defence of the GPL realm (The H) Posted Dec 18, 2012 12:21 UTC (Tue) by dps (subscriber, #5725) [Link]
The build system issue is particularly difficult. The "real" build system where I work, which does sell a solution with GPLed components at a profit, assumes you have things like a perforce server with a particular IP addresses and other features of the dev network.
The "real" build system also includes a secret, which we would not want to give you, to upload release components to a sever you probably can't reach.
Would you want our real build system or code which is 1:1 with what we distribute and an alternative build system that does not require the network resources you don't have and can't reach?
Defence of the GPL realm (The H) Posted Dec 18, 2012 22:01 UTC (Tue) by cwillu (subscriber, #67268) [Link]
A complete build system that depends on resources that I don't have and can't reach isn't a complete build system. In this situation an alternate build system is the sane way to meet the requirement, but don't kid yourself that you're doing anyone a favour by complying with the rules.
Defence of the GPL realm (The H) Posted Dec 18, 2012 22:21 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
saying that the required build system (that needs to be provided for the GPL) must include access to private servers, or authentication tokens used to publish the result to private servers is being silly at best.
That sort of access was never intended by any license writer (and any developer who thinks they are entitled to such access is foolish)
The problem is that the definition of what the "build system and scripts" are is a bit fuzzy. Many people who automate builds try to minimize all of their work, and this can include purely private things like what version control system the source is checked out of, or what version control system the resulting binaries are checked into. This sort of thing is of no interest to anyone except people trying to break into that company and disrupt it. The reason that the licenses specify "build scripts" is because sometimes logic gets put in there that affects the final binaries (things that arguably should be in the makefiles instead). In cases like this, the build scripts needed to duplicate the binaries from the source are different than the scripts that the company uses to do the builds that also do several other things.
This isn't bad faith or trying to violate the license on the part of the companies. It may be short sighted optimization of things by the admins writing the scripts, but no more than that.
Defence of the GPL realm (The H) Posted Dec 19, 2012 0:02 UTC (Wed) by cwillu (subscriber, #67268) [Link]
I don't disagree; I'm just emphasizing that if your internal build system depends on things you cannot distribute in order to build the thing, it's perfectly reasonable that you be required to provide an alternate build system that you can distribute.
Defence of the GPL realm (The H) Posted Dec 19, 2012 0:10 UTC (Wed) by armijn (subscriber, #3653) [Link]
Back in the day when the GPLv2 was drafted the "scripts to control compilation and installation" referred to things like the Makefile of a single package on a Unix workstation where you had full access a shell and a compiler and the package was built and installed on that machine.
These days firmwares with tons of free software are built and installed on millions of devices. How these firmwares are built is often a non-trivial process. You need to set up a cross compilation environment (smart people go for standard solutions of course, but there are tons of homebrew things out there), different devices have different layouts of flash or the way firmware upgrades are assembled, and so on. Without the information in the build system, or the build system itself, it is impossible to recreate the firmware, sometimes not even the individual components. So from a software freedom standpoint having the build system, plus the configuration to build the software makes a lot of sense.
Of course, whether or not this could be legally enforced is another question. The argument can certainly be made that a firmware is "mere aggregation" and not a derivative work.
The most valuable part from the build scripts are not the scripts, but the information about things like firmware layouts and configuration options, which I know developers extract and then merge upstream into projects with proper build systems. When I talk to companies I always suggest to ditch the homebrew scripts and go for standard solutions, which make a lot of compliance questions a lot easier.
Defence of the GPL realm (The H) Posted Dec 19, 2012 0:17 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
all you say is true, but I'll point out that back in the day it was common to require proprietary compilers to compile things for some environments. The requirement was never to include the compilers, even though it was impossible to recreate the binaries without them.
This point is a fairly major split in the community.
One one hand we have people who say that if they can't compile the exact same binary (and install it), the GPL really hasn't been complied with.
On the other hand we have people like Linus that say that if they get the source code, that's all the the GPL requires.
Now, when you get to the point where there is a legal challenge stating that you have not complied, merely producing source and stating that it's what was used is not likely to be good enough. At that point a company could stand on that point and take it to court, or they could work with people like Bradley to convince them that it really is the source, by providing them with whatever help is needed to let the compile the source to get the same binary. It's _far_ cheaper to do that sort of thing than it is to pay lawyers to go to court.
Defence of the GPL realm (The H) Posted Dec 19, 2012 1:53 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] If Linus says this (and I'm not sure he has), he hasn't read the license text. The relevant GPLv2 text states (I added the emphasis)The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Now, in the cases Linus is most concerned about, the standard Linux build system will work fine with the distributor's new code or patch, so he doesn't need a build script, he already has it (so if he said something like this, then perhaps that's what he meant). It is covered in the exception in the last sentence above. But if the code won't build with a simple command or three (e.g. configure, make, make install), then more must be included.
Defence of the GPL realm (The H) Posted Dec 20, 2012 23:34 UTC (Thu) by zlynx (subscriber, #2285) [Link]
That exception is major though.
It means that if you have the source code for the firmware for a network card, or a hard drive, you don't have to be given the compiler. After all, it is a normally distributed part of the operating system on which the executable runs: in that case, the chip hardware. And to get that special compiler or even the opcode list for the processor might require committing to the purchase of a very expensive dev kit. If the ASIC is completely custom and proprietary you might not be able to get a compiler at all.
Defence of the GPL realm (The H) Posted Dec 21, 2012 2:09 UTC (Fri) by bkuhn (subscriber, #58642) [Link] Whether or not the firmware as a whole is derivative or aggregate is unrelated to the issues of The point is that for a given GPL'd program, GPL requires that, upon distribution of a binary of that program, the information on how to build and install a modified version of that particular binary must be provided. This requires knowing how to get a modified binary correctly into a firmware blob. The copyright status of the firmware as a whole is just moot with respect to this issue.
Defence of the GPL realm (The H) Posted Dec 21, 2012 2:36 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
If it was as simple as you are making it out to be, there would have been no need for the anti-Tivo clause in GPLv3
I know there are people who believe this, but nobody with standing has ever tried to enforce this, so it doesn't seem likely to prevail
Defence of the GPL realm (The H) Posted Dec 19, 2012 16:57 UTC (Wed) by heijo (guest, #88363) [Link]
Well, you should just separate the "get source from Perforce" and "upload binaries to server" parts from the process that builds the executable.
Then just release the part that builds the executable, which is the only actual build system.
Or you can create an alternate system that produces the same result, but that's just wasted work.
In practice, you'd have an in-tree build system using autotools/cmake/whatever, plus a script in a different repository that fetches the source, calls the build system and pushes out the release.
|
|||||||||||||