Submitted by Does Google’s Android violate the GPL? This bold claim is being made by Edward Naughton, and was picked up here and there across the web. The problem seems to be that Android’s Bionic, a glibc alternative, supposedly violates the GPL by stripping the Linux kernel header files of all comments and other extraneous information and relicensing them under a more permissive license so that non-GPL programs can be written. Bradley Kuhn, former FSF executive director and expert on GPL violations, believes the claims are way overblown.
The trouble stems from Android’s Bionic, an alternative to glibc and uClibc. Bionic includes cleaned-up Linux kernel header files which can be included with user-space programs. The raw Linux kernel headers are licensed under version 2 of the GPL; Google’s cleaned-up versions, which only contain “type and macro definitions, with the exception of a couple static inline functions used for performance reason (e.g. optimized CPU-specific byte-swapping routines)”, are licensed under the BSD license.
According to Naughton, this is a GPL violation, and thus, this would have dire consequences for the Android ecosystem. “If Google’s assumptions are wrong, and if the Bionic header files remain subject to GPLv2, there is a considerable risk that applications using them become subject to GPLv2 as well,” Naughton argues, “On Android, all native code must compile against Bionic, and at least in the view of the Free Software Foundation, compiling code against a GPLv2 licensed library like Bionic makes the code subject to GPLv2.”
He goes even further than that, and argues that if Google is right, and Bionic can indeed remain licensed under the BSD license, then it has unlocked the Linux kernel from the GPLv2. “If Google is right, if it has succeeded in removing all copyrightable material from the Linux kernel headers, then it has unlocked the Linux kernel from the restrictions of GPLv2,” he argues, “Google can now use the ^aEURoeclean^aEUR Bionic headers to create a non-GPL’d fork of the Linux kernel, one that can be extended under proprietary license terms. Even if Google does not do this itself, it has enabled others to do so.”
If this sounds overly dramatic to you, that’s probably because it is. Bradley Kuhn, sort of the expert on GPL violations, takes a lot of issues with Naughton’s report. “Naughton’s full paper gives some examples that would make a good starting point for a complete analysis,” he states, “It’s disturbing, however, that his paper is presented as if it’s a complete analysis. At best, his paper is a position statement of a hypothesis that then needs the actual experiment to figure things out. That rigorous research (as I keep reiterating) is still undone.”
Kuhn has done this sort of rigorous analysis before, so he knows what he’s talking about. “For example, one of my first questions would be whether or not Bionic uses only parts of Linux headers that are required by specification to write POSIX programs, a question that Naughton doesn’t even consider,” he adds.
Kuhn further argues that Google’s Bionic isn’t the first time someone came up with a way of cleaning the raw header files to create something programmers can use to interface with the Linux kernel without having to licens their code under the GPL. “If it turns out that Google has succeeded in making sure that the GPLv2 does not apply to Bionic, then Google’s success is substantially more narrow,” Kuhn states, “The success would be merely the extraction of the non-copyrightable facts that any C library needs to know about Linux to make a binary run when Linux happens to be the kernel underneath. Now, it should be duly noted that there already exist two libraries under the LGPL that have already implemented that (namely, glibc, and uClibc – the latter of which Naughton’s cursory research apparently didn’t even turn up).”
Kuhn successfully argues that all this looks like a storm in a teacup. It clearly wasn’t Google’s intention to violate the GPL, so even if mistakes have been made, they’ll be easily cleared up. “If someone actually does all the research to prove that Google did so [inadvertently taking a copyright-infringing short-cut], I’d easily offer a 1000-to-1 bet to anyone that such a copyright infringement could be cleared up easily, that Bionic would still work as a permissively licensed C library for Linux, and the implications of the whole thing wouldn’t go beyond: ‘It’s possible to write your own C library for Linux that isn’t covered by the GPLv2’ – a fact which we’ve all known for a decade and a half anyway,” he explains.
We’ll see what such an in-depth investigation would turn up, but the fact that someone like Kuhn is skeptical about the whole thing doesn’t bode well for Naughton’s claims.
If this isn’t allowed, I guess it wouldn’t be allowed to use the header-files to the LGPL glibc. In essence this boils down to the age-old troll:
Troll: It is not allowed to run non-GPL programs on Linux.
Tired answer: Yes, yes it is. Go away troll
Saw this info on /.
http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html
I’m not sure what your project is designed to do, so I don’t have an opinion about how it stands regarding the GPL. However, I’ve talked with our lawyer about one specific issue that you raised: that of using simple material from header files.
Someone recently made the claim that including a header file always makes a derivative work. That’s not the FSF’s view. Our view is that just using structure definitions, typedefs, enumeration constants, macros with simple bodies, etc., is NOT enough to make a derivative work. It would take a substantial amount of code (coming from inline functions or macros with substantial bodies) to do that.
—
This might also explain why no coders have come forward to complain or object to it. (^;)
Issue is macros and inline.
If headers only include structs and function calls including it the license of the header does not effect the rest of the work. In the USA atleast.
Note those items are still copyrighted by the first copyright holder.
Now if the headers contain macros and inlines copied across they are active code. No different to linking a .c file into your binary that is GPL if you use them.
Few legal problems stripping of copyright notice very much like Novell did with BSD and paid a high price. 2 it was a program that processed the data. Legally if program processing the data has not been ruled if that resets copyright.
Yes if I type a new copy of the struct and the interface functions even if it looks the same since I typed it the copyright is mine. Legally is a computer program allowed to also do this. Has data processed by a program changed copyright.
Because this does open up some scary facts if it does.
One of the issues being argued over in the Orcale case against Google on java is the use of decompliers and its effect on copyright.
Technically Orcale lose and we might be legally allowed to used a decomplier to pull programs to bits and rebuild them under a different license.
This is a true pandora for copyrights of mixed works as well.
AFAIK, header files are NOT copy-writeable. They are similar to book titles.
As for machine generated code, you still start with something that is copyrighted and make a copy of it, at least into memory. There is also the issue that the code is still essentially the same. While it may differ a little, the vast majority of it will be the same in structure making it a derivative work.
Well in general. While there is no issue here, the copyright status of header files is not that simple.
Header files are supposed to be interface descriptions, and interfaces can not be copyrighted.
On the other hand, C and C++ makes no distinction between source files and header files, and it is very easy to put non-interface code into the header files, inlined functions, templates and comments are all copyrightable, so you can not make a blanket claim.
Still this is rather stupid. The Linux system-calls are not only header files they are the published APIs for the operating system, they are published for the very purpose of being used by all types of software.
One thing strikes me as odd though: Why did Google feel the need to change the license header? The very fact that makes it legal for them to do so, is the very fact that makes it completely unnecessary.
Edited 2011-03-22 11:52 UTC
http://www.groklaw.net/article.php?story=20110322014831856
Linus calls these claims bogus. Userland programs are not derivatives of the kernel, there is no copyright violation, and indeed userland programs are *expected* to use the kernel header files in order to interface with the kernel.
Unrelated to the article: I’ve noticed that you tend to use UK English in your articles. In that case, it should be “sceptical”, instead of “skeptical”.
Kuhn’s argument is as unsatisfying as he says Naughton’s is. Neither is a full analysis. All that Kuhn is really saying is that Naughton hasn’t fully analyzed this. He isn’t actually saying that he’s wrong, just that he might be, or that he might only be partly correct. But neither has he done any analysis. In fact, his own arguments are mere speculation.
This does need further work. But for now, it doesn’t look good for Google.
Edited 2011-03-23 00:41 UTC
I recall that Apple Inc was sued by Apple Records. Part of that settlement was that Apple Inc was not to sell music.
Oops! Posted under the wrong article.
Edited 2011-03-23 07:04 UTC
I wonder why google hadn’t started with *BSD, why do they use Linux which is obviously not business friendly.