August 24, 2011, 3:52 PM —
With all of the talk about the license for the Linux kernel being violated by Google and downstream vendors of the Android operation system, I wanted to find out what would happen in a worst-case scenario.
Specifically, if someone wanted to sue a vendor for GPL non-compliance on behalf of the Linux kernel, who could do it, and what might happen next?
To understand this, let's back up and talk about how "ownership" of the Linux kernel works. Throughout this discussion, I will be talking about the Linux kernel proper, not any form of the broader Linux operating system (aka GNU/Linux, if you're so inclined). Ownership of the operating system is a little easier: Red Hat owns Red Hat Enterprise Linux, SUSE owns SUSE Linux Enterprise Server, and so on.
But when it comes to the kernel, things get a bit more confusing.
A common misconception is that Linux is owned and controlled by its founder, Linus Torvalds. In a legal sense, that's not the case. Torvalds owns the trademark for the name "Linux," a trademark enforced by the Linux Foundation (LF). This means that I should not be able to name my new line of bath soaps "Linux Luxury," unless I had the approval of Torvalds and the LF.
Nor does the LF own the Linux kernel. The LF exists primarily as a support and advocacy organization for Linux. Their only involvement with kernel development is paying the wages of certain Linux developers through fellowships and organizing working groups when asked. Otherwise, it's strictly hands off. Which, probably, is how it should be.
So if the kernel as a whole is not owned by Torvalds, then who has it? Simply put, anyone and everyone with accepted code inside the kernel. That's because unlike some other software projects (free, open, or otherwise), Linux does not require contributors of code to sign any sort of copyright assignment.
Copyright assignments basically work like this: I, a hypothetical developer, create some semi-brilliant code and want to contribute it to Project X, which is overseen and used by Company X. Company X, recognizing the semi-brilliance of my code, wants to use it in their latest release, so they ask me to sign away the copyrights of my code over to them. This is so that when they release my code as part of the greater whole software release, they can have full legal control over the code--even though they will still work with me and give me credit.
Under most circumstances, this makes sense. After all, I want my code to be in Project X, and it makes sense that Company X doesn't want the nightmare of working with a bazillion different copyrights.
The Linux kernel, however, uses another method. There is no copyright assignment requirement. In fact, there really isn't a contributor agreement in the traditional sense. Developers who contribute to the Linux kernel are only required to sign off on a Developer's Certificate of Origin, which basically says that the developer created the code, didn't copy it from anyone else, and is authorized to submit the code to the Linux kernel. This lets the rest of the Linux developers off the hook if someone foolishly tried to pilfer some code from another piece of software and inject it into the Linux kernel.
But what the Certificate of Origin doesn't do is grant the ownership of the contributed code to any other entity. The contributor still holds the copyright for the code. This means, in theory, that any single developer or group of developers who owns the copyright for a piece of the Linux kernel could raise objections about any legal issue affecting the Linux kernel--including violations of the GNU General Public License, under which the Linux kernel is licensed.
In theory this raises some interesting questions about GPL enforcement of Linux. If any one developer, who owned the copyright for a piece of Linux kernel code, opted to sue a downstream vendor, then that vendor might lose the right to distribute the entire kernel.
This has already happened, so there's precedence: when the Software Freedom Law Center sued Monsoon Multimedia for GPL violations of the BusyBox software, they did it on behalf of two principal developers of BusyBox--Erik Andersen and Rob Landley--not all of the BusyBox developers. This is significant because, like Linux, BusyBox also does not use contributor agreements or copyright assignments.
In fact, as BusyBox developers continued to launch GPL violation lawsuits, the creator of BusyBox, Bruce Perens, actually raised public objections to the lawsuits in 2009, claiming that his interests were not being represented in the multiple lawsuits.
So yeah, this doesn't sound like such a good thing for downstream Android vendors, at least in theory. Looking at the GPL compliance list of Android tablet vendors compiled by Red Hat kernel developer Matthew Garrett, it would appear that some of these vendors are already in trouble. In fact, I have caught flack for pointing out Garrett's list and then turning around and saying there are no claimed violations. That's because, to my knowledge, Garrett nor any other Linux kernel developer have filed any formal legal claims against any of the vendors he's cited, though he has been pretty vocal in his objections.
That's why I have been writing that, thus far, all of the GPL compliance noise about Android and Linux has been just that: noise. Simply put, if there's no legal complaint, then you can't run off your mouth and declare Android vendors are already in violation of the Linux kernel's GPL.
So what would have to happen for a Linux kernel developer to initiate a lawsuit?
First, I would imagine that the developer in question would have to determine if their part of the Linux kernel were actually in the downstream software that was not in compliance. That could be tricky, since the downstream vendor's source code might not be available (hence the non-compliance). Reasonable guesses could be made, however: the developer of embedded controls, for instance, would have a far more likely chance for their code to be in an Android kernel than, say, a developer who submitted desktop monitor code. Past releases, which might be available, would also provide some clues.
Next, if code presence were established, the developer would probably need to try non-legal recourse first. Bradley Kuhn, executive director of the Software Freedom Conservancy, an organization that pursues GPL enforcement, has often said that a lot of GPL violations can be handled with a phone call or two, which is just fine with him. Public complaints are another avenue. Garrett raised holy heck about HTC's non-compliance of the GPL, and HTC responded to the public outcry by posting the appropriate source code--albeit in a delayed way.
If all options had been tried, then the developer might choose to get a lawsuit going. Because of this theory, two concerns kept bubbling up from the darker corners of my mind.
First, after the recent pronouncement from the Free Software Foundation (FSF) on the shortcomings of the GPLv2, I was worried about what would happen if a kernel developer decided to use the FSF to represent or be a co-plaintiff in any non-compliance claims. I could just see the FSF using such a lawsuit to not only attain compliance but also formally pursue agreement from every single affected Linux kernel developer, just to prove their point about how the GPLv2 is more difficult to regain compliance than the GPLv3.
Second, and this is admittedly paranoid, I kept coming back to the recent reports such as the one where Microsoft developer K.Y. Srinivasan was revealed to be the largest contributor to the Linux 3.0 kernel, in terms of change sets. Srinivasan's contributions were for Hyper-V related code, so there's little chance his code will make its way to the Android kernel. But what about other contributed code from Microsoft, or Oracle for that matter? What would happen if one of those developers saw their code in the Android kernel suddenly got the urge to vigorously pursue GPL compliance with oh, say, an Android vendor? The copyright belongs to them, or their employer, so they would certainly be within their rights.
This bothered me. I kept thinking that with so much money tied up in the Linux ecosystem, someone would get clever and try to damage Linux-related projects with carefully aimed litigation, just to further their own commercial or philosophical ends.
So I did more research and discovered that in practice, thankfully, things aren't quite as bad as all this theory sounds.
To begin with, while the LF does not own the Linux kernel, it does have licensing counsel, and it's very likely that the LF, not the FSF, would help represent a Linux kernel developer, working very hard to resolve the situation on the developer's behalf. With the full muscle of the LF and its constituent members behind any such legal action, I would further speculate that any matter of GPL violation would be resolved quickly. I also suspect that the supposed hurdles to GPL re-compliance recently raised by the Free Software Foundation and others would also be quickly worked out without having to really go through every other copyright holder of the Linux kernel. After all, if the original developer who initiated the compliance lawsuit is satisfied, does anyone expect objections from the other developers?
(It should be noted that the above is all speculation on my part. I can't speak for the LF nor any legal action they might take, as evidenced by all the "ifs" and "imagines" in the previous paragraph.)
But beyond my speculation, there are known arrows in the LF's quiver. The Foundation's Open Compliance Program, for example, was implemented to take care of issues just like this.
"Complying with open source licenses is very straightforward," according to the LF's VP Marketing and Developer Programs Amanda McPherson. "The Linux Foundation started the Open Compliance program last year to make it even easier... our compliance directory is one example of this system at work."
McPherson [Disclaimer: My former boss at the LF] isn't worried about the recent discussions regarding the Linux kernel and GPL compliance.
"The kernel development community is incredibly well coordinated on these matters. There is a lot of FUD out there and we suggest people keep a cynical
eye on the sources of this 'sky is falling' material," McPherson wrote in response to my queries today.
The coordination McPherson refers to confirms another thought I had: I would expect that any developer who decided to make a stand on GPL compliance might face strong community pressure to not pursue such a lawsuit. Torvalds does not need to own Linux to assert control over the Linux kernel. The community trusts him and through that trust has granted him broad management powers. I would imagine his influence and those of veteran Linux contributors would be enough to prevent individual lawsuits.
It's very easy to sit around and come up with scary booga-booga situations that anyone can wrap up and sell as truth, when it's really just a possibility. Heck, I can make up scenarios that could scare myself.
But there's theory and then there's reality. Everyone needs to make sure they know the difference.
Read more of Brian Proffitt's Open for Discussion blog and follow the latest IT news at ITworld. Follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.