Oh Noes -- teh Angry Birds GPL'd! Google's Alleged GPL Violations in Android

Two commentators, Florian Mueller and Edward Naughton, have recently claimed that Google is violating the copyleft obligation of the General Public License in distributing the Android mobile operating system used in millions of smartphones all over the world. Android consists of a combination of the underlying Linux kernel, licensed under GPLv2, wrapped with a C library known as Bionic, and topped off with an application framework. Google has released Bionic under the permissive BSD license. Naughton's and Mueller's thesis is that Google's Bionic library is a derivative work of the Linux kernel due to the amount and type of code Bionic lifts from the kernel, and therefore is required to be licensed under GPLv2. If Bionic is required to be licensed under GPLv2, that means Android applications would also have to be licensed under GPLv2 in source code form, they claim. Google would lose control of the entire platform, the argument goes, and Android as a viable and profitable ecosystem would collapse.

Naughton writes:

Google took a novel and quite aggressive approach to developing a key component of Android -- the Bionic Library. That library, a type of C Library, is used by all application developers who need to access the core functions of the Linux operating system. Google essentially copied hundreds of files of Linux code that were never meant to be used as is by application developers, "cleaned" those files using a non-standard and questionable technical process, and then declared that the code was no longer subject to the GPLv2, so that developers could use it without becoming subject to copyleft effect that would normally apply to GPLv2-licensed code taken from the Linux kernel.

Bionic and the Incorporation of Header Files

Google incorporated kernel header files - that is, the interfaces of the Linux kernel so that "userspace" programs (like applications) can invoke the declared functions of the kernel. The copyrightability of header files is open to debate. API declarations can be basically considered as "facts" of the operation of the software program to which such APIs apply, and facts (along with systems, processes or methods of operation) are as a general matter not copyrightable. Even if some copyright protection exists for APIs, courts have held that copying such interfaces in order to create compatible independently-developed software is fair use.

In any event, incorporating header files in this manner is in itself non-controversial and hardly "aggressive", "non-standard" or "questionable". Many have done this. In fact both Mueller and Naughton describe another library that was created in the exact same manner: the LGPL-licensed GNU C library known as glibc. The developers of glibc created it using the same basic methodology that Google used - by copying header files from the kernel itself.  There are numerous other libraries that have done the same, and which are not licensed under GPL: klibc (LGPL/BSD), uClibc (LGPL), newlib (LGPL/BSD) and Embedded Glibc (LGPL).

This is non-controversial because the Linux kernel is licensed under terms that permit linking to kernel functionality. The Linux kernel source code can be accessed here: http://www.kernel.org/pub/linux/kernel/. Clicking on the "COPYING" link reveals the licensing terms applicable to the kernel - namely, the GPL v2. However, immediately before the recitation of the GPL is the following statement: 

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it.

This statement means that userspace programs that invoke functionality of the kernel will not be considered derivative works of the kernel and will not be required to be licensed under GPL.  Google posits that this statement is the equivalent of licensing the kernel under the so-called "GPL + exception" - essentially, a copyleft license that permits invocation of system calls by non-GPL programs such that non-GPL programs are not considered derivative works and therefore not subject to the obligations of the GPL. 

GNU C Library vs. Bionic - Why is the Former OK but the Latter is Not?

Now, it's certainly possible, as Naughton and Mueller claim, that Google lifted more kernel code than necessary, and that Bionic does more than simply invoke system calls. Bionic was created as an alternative to the more widely used C library kernel wrapper, glibc, because Bionic is smaller and faster in execution. Information about Google's thinking on Bionic can be deduced here and here. Without closely inspecting the over 700 files in question, there's no way to know for sure if Naughton's and Mueller's accusations in this regard carry water.

Interestingly, however, both Mueller and Naughton maintain that Google sinned by not incorporating glibc in Android. Naughton: "The preferred option in the industry is to build the application against a different set of kernel header files that accompany the GNU C library (glibc) ...."; Mueller:  "I think the only viable option will be for Google to recognize its error with Bionic and to replace it as soon as possible with glibc (GNU C library)." Bionic is notably smaller than glibc - thus begging the question: if Bionic is a derived work of the GPL-licensed kernel and thus must be licensed under GPL because Google lifted too much kernel code, as Naughton and Mueller claim, why isn't glibc a derived work of the kernel as well? Both Bionic and glibc are licensed under non-GPL terms. Mueller and Naughton don't explain why glibc's approach is kosher but Bionic's approach is not. 

The Case Against Angry Birds

In any case, the most objectionable aspect to the Mueller and Naughton blog entries are the wildly exaggerated claims that Android applications will be forced to be licensed under the terms of the GPL in open source code form.  Mueller (emphasis added):

If Google is proven wrong, pretty much that entire software stack -- and also many popular third-party closed-source components such as the Angry Birds game and the Adobe Flash Player -- would actually have to be published under the GPL. .... Everyone would be free to use, modify and redistribute all of the affected software. As a result, there would be no more revenue opportunity for the developers of the affected applications, and the makers of Android-based devices would lose their ability to differentiate their products through proprietary add-ons. Whatever software they publish would become available to their competitors on GPL terms. Prices and margins would inevitably come down.

Naughton:

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. ... If GPLv2 applies to Android applications, developers’ ability to differentiate on the Android platform would be seriously impaired, because they would be required to release the source code of their applications and would be precluded from limiting how anyone, including competitors, uses that code. At a minimum, developers are taking a significant business and legal risk, by joining in Google’s bet that the Bionic headers don’t contain any copyrightable material.

With all due respect, I don't believe that developers are taking any risks, let alone significant risks, in this context, and I don't believe there's any possibility that Angry Birds will have to be GPL'd against their will. Application developers have done nothing to subject themselves to the copyleft obligations of the GPL. Linking to kernel APIs directly wouldn't create a derived work according to the stewards of the Linux kernel, as evidenced by the statement quoted above. Even in the absence of this "GPL + exception"-flavored statement, a strong text-based and copyright law-based argument can be made that merely linking one independent program to another independent program does not create a derivative work under both copyright law and under the text of the GPL itself.

The GPL, Derivative Works and Collective Works 

It's important to remember that the copyleft obligation of the GPL is expressed as a condition to the right to modify; section 2 states: "You may modify your copy or copies of the [GPL] Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work ... provided that ... you must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." (emphasis added)). Only the right to modify is conditioned by the copyleft obligation. Rights to use, copy and distribute are not. If one does not modify GPL-licensed code, one is not subject to the copyleft requirement. Application developers are never modifying GPL code at any time.

It's also important to remember that the GPL applies to a GPL-licensed program and "any work based on the Program", and the GPL defines a "work based on the Program" in pertinent part as "any derivative work under copyright law". Bringing together two independent and separate works constitutes the creation of a compilation or collective work, but not a derivative work. Collective works or compilations are collections of separate and independently developed works into a whole work, where the separate works are arranged or selected in an original way. The usual examples here are anthologies, encyclopedias, databases, etc. They are legally distinct from derivative works.

The universal standard for copyright protection for any type of work, including derivative works, is originality. In the context of derivative works, to be original the derivative work must “recast, transform, or adapt” the original work in more than a trivial way. I believe the caselaw in the US might be a bit more strict, in that there are cases that call for a “substantial difference” between the original work and the derivative work in order to qualify as a copyrightable derivative work. But in any case, the bottom line is that the original work must be recasted, transformed, or adapted.

In the US, the 7th Circuit case of Lee v A.R.T. Company (1997) is instructive. In that case, the defendant purchased copies of plaintiff's postcard art (thus first sale applied), affixed the postcards to ceramic tiles, and sold such tiles in commercial outlets.  The plaintiff claimed that such activity infringed plaintiff's exclusive right to create derivative works.  The 7th Circuit disagreed, holding that the art cards were not recast, adapted or transformed, and therefore no derivative work was created. An argument can be made that an Android application that links with a GPL-licensed library in the platform is the functional equivalent of pasting postcard art (GPL-licensed code) with ceramic tile (non-GPL works). The result is not a recasting, transformation, adaptation or modification of the original (GPL-licensed) work and is therefore not a derivative work of it.

And finally, as discussed above, programs that merely incorporate header files or interface declarations of code covered by the GPL, or that link to such code either statically or at runtime, are in all likelihood not incorporating copyrightable expression from the GPL-licensed library, and even if they are held to do so, are subject to a viable fair use defense.

Propagating the Unreasonable Fear of Infection

Lawrence Rosen makes essentially the same points adroitly in a paper entitled, "The Unreasonable Fear of Infection", to wit:

Simply combining a copyrighted work with another work does not create a derivative work. The original copyrighted work must be modified in some way. The resulting derivative work must itself “represent an original work of authorship.” So if the licensee doesn’t modify the original GPL-licensed program, but merely runs it, he is not creating a derivative work.

Consider the scenario where the Linux operating system, a GPL-licensed program, loads and executes a proprietary program. The Linux program is not modified; it is merely used for the purpose for which it was designed. The proprietary program does not “contain” nor is it “derived from” Linux. Linux does not infect the proprietary program, and the proprietary program does not become subject to the GPL.

Google is under no danger of losing control of the platform. Even if a court rules that Bionic should have been licensed under GPL, the worst case scenario is that Google is guilty of copyright infringement of the Linux kernel by distributing the kernel without GPL compliance. Assuming all kernel copyright holders can be located and convinced to collectively sue Google for infringement (otherwise the case will be dismissed for lack of standing), at most Google will be forced to pay damages and enjoined from distributing the kernel in a non-compliant fashion. There's no legal possibility that Google or any application developer will be forced to comply with copyleft. No court would specifically enforce the GPL in this situation or order Google to release Android under GPL, the copyright to many parts of which are not even owned by Google.

Frankly I doubt an infringement action would ever be brought, as a practical matter.  Google and the Linux/Android developer community would come up with a workaround of some kind. In the words of Bradley Kuhn:

Google may have erred; no one actually knows for sure at this time. But the task they sought to do has been done before and everyone intended it to be permitted. The worst that we might be able to accuse Google of is inadvertently taking a copyright-infringing short-cut. If someone actually does all the research to prove that Google did, I'd easily offer a 1,000-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.

I couldn't have said it better.  Angry Birds can rest easy.

notices    log in

© 2006, 2014 Sean Hogle PC. All rights reserved.