The use of the Android operating system continues to grow. Gartner recently reported that Android had become the leading operating smartphone operating system in the world in the first quarter of 2011. http://www.computerworld.com/s/article/9216848/Gartner_Android_and_Apple_win_big_globally_in_Q1. Android grew from 9.6% to 36% of the market in the last year. Its lead over smartphones running Symbian is now almost 10 million units per quarter. During the first quarter of 2011, manufacturers distributed 36.3 million smartphones running Android while only 27.6 million smartphones running Symbian were distributed.
Yet Android continues to be a very complicated product from a licensing point of view http://lawandlifesiliconvalley.com/blog/?p=635. Peter Vescuso of Black Duck and I worked to provide a summary of the issues in managing licenses in software development based on the Android operating system http://www.law.com/jsp/lawtechnologynews/PubArticleLTN.jsp?id=1202495469387 . I have included a more detailed legal perspective http://www.law.com/jsp/lawtechnologynews/PubArticleLTN.jsp?id=1202495473435.
The recent Android Builder’s Summit in San Francisco demonstrated the breadth of products using Android and the dynamic nature of the operating system. In her keynote, Christy Wyatt of Motorola described the challenges of managing the launch of 700 products based on Android in countries around the world. She was followed by Mark Charlebois (Director of Open Source Strategy at Qualcomm Innovation Center) and he predicted that their Android releases would grow from 241 in 2010 to more than 365 in 2011.
Karim Yaghmour of Opersys provided a great overview of Android and its critical subsystems http://www.opersys.com/blog/abs-march2011. However, his presentation brought home the challenges of managing Android: he mentioned in passing that he was unhappy with the performance of the Android Toolbox, the component which Google substituted for BusyBox for Toolbox. He regularly substitutes BusyBox for Toolbox (one Android site had more than 25,000 downloads of BusyBox). BusyBox is described as follows;
a software application that provides many standard Unix tools, much like the larger (but more capable) GNU Core Utilities. BusyBox is designed to be a small executable for use with the Linux kernel, which makes it ideal for use with embedded devices. It has been self-dubbed “The Swiss Army Knife of Embedded Linux”.
According to Black Duck, Android Toolbox is a collection of 66 files, 52 are under the Apache 2.0 license and 14 are under BSD. Both the Apache 2.0 and BSD licenses are very permissive. However, BusyBox is licensed under the GPLv2, a copyleft license, which has very different and much more significant obligations, particularly the obligation to make the source code available either with the object code or through a written promise. More importantly, the license to BusyBox is the most actively enforced license in open source. The Software Freedom Conservancy and the Software Freedom Law Center have filed at least seven lawsuits (with many other disputes settled with ligitation) to enforce the GPLv2 license on BusyBox. Last year, they won $90,000 in damages from Best Buy.
Thus, a reasonable technical decision can dramatically change the obligations of the distributor. Since the GPLv2 is a “conditional” license, the failure to comply with these terms means that the license terminates automatically without a cure period. Thus, the distributor would be a copyright infringer. Since products including Android are frequently mass market products, the consequences could be significant liability arising from millions of unlicensed units. This reality demonstrates once again the need for careful management of the use of Android and clear communication between the developers and the relevant counsel.
Recently, Edward Naughton, a lawyer with Brown Rudnick, raised concerns about Google’s potential violation of the license for the Linux kernel (the General Public License Version 2, “GPLv2”) in developing the Android operating system:
“I have serious doubts that Google’s approach to the Bionic Library works under U.S. copyright law. At a minimum, Google has taken a significant gamble. While that may be fine for Google, because it knows about and understands the risks, many Android developers and device manufacturers are taking that same risk unknowingly. If Google is wrong, the repercussions are significant for the Android ecosystem: the manufacturers and developers working with Android would be incorporating GPLv2-licensed code into applications and components and taking on the copyleft obligations of that license”
However, his statements are based on a fundamentally flawed analysis of the application of the GPLv2 to Linux: he ignores the modification to GPLv2 found in the “Note” (see below) which fundamentally limits the scope of “derived works” under the GPLv2 as it applies to Linux (as a matter of transparency, neither I nor my law firm, DLA Piper, represents Google and this opinion is my own and may not reflect the views of DLA Piper or its clients). The Note is found at the top of the GPLv2 on the license page of the website of the Linux kernel:
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. http://www.kernel.org/pub/linux/kernel/COPYING
This flawed analysis is coupled with a basic misunderstanding of the intentions of Linus Torvalds and contributors to Linux: Naughton suggests that Linus and other contributors are interested in having GPLv2 apply to “user space” and that the common program used with Linux kernel files, glibc, enjoys a special informal blessing which permits its use without extending the effect of the GPLv2 to programs in “user space”. In fact, the reverse is true. Linus and the contributors to Linux want to avoid the application of GPLv2 to programs in “user space” as a fundamental basis of the development of Linux. This intention has been clear since the initial development of Linux as evidenced by Linus Torvald’s adoption of the “clarification” to the GPLv2 in the form of the Note.
Naughton argues that the GPLv2 requires that any program which reproduces and distributes Google’s “cleaned” Linux header files is subject to GPLv2. It is undisputable that the unmodified GPLv2 requires that programs that are “based on” the GPLv2 licensed software must be distributed under the GPLv2. However, Naughton ignores the critical difference about the scope of the GPLv2 as modified by the Note. The effect of the Note on this issue is substantial.
Naughton mentions this “Note” but only in passing when discussing glibc:
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”). The headers in glibc are different from the “raw” header files, because they’ve been created, with the apparent blessing of the Linux kernel maintainers, from a subset of the raw files by means of a standard process. Within the industry, these header files are referred to as “sanitized” header files. Linus Torvalds and the kernel maintainers have publicly declared that applications can use these sanitized header files without becoming subject to GPLv2 because these sanitized header files are “normal system calls” http://lkml.org/lkml/2003/12/4/239.
However, the creation of the “sanitized” header files are not subject to an informal “blessing” with kernel maintainers (in fact, they don’t have the authority to provide such a blessing which can only be done by the copyright owners of the contributions to Linux): the Note, which is part of the legal framework adopted by Linus and agreed to by all contributors, limits the scope of works “based on” under the GPLv2 for the kernel. In fact, Naughton’s description of the Bionic’s Library modification of the Linux header files is very similar to the manner in which he describes the operation of glibc. Thus, it is difficult to understand the difference between the analysis of the scope of the modified GPLv2 with glibc and with the Bionic program. The key issue is whether the interaction of the Bionic Library with the kernel uses “normal system calls” and, thus, it is not a “derived work”. It appears that the Bionic program uses normal system calls. These facts explain why none of the Linux committers (a notably outspoken group) has chosen to challenge the use of the Bionic program.
Naughton makes much of the expressed desire of certain Google programmers to ensure that Android “keep GPL out of user space”. Yet this goal is fundamental to the Linux community. Linus Torvalds stated: “User programs are _clearly_ not derived works of the kernel, and as such whatever the kernel license is just doesn’t matter.” http://lkml.org/lkml/2003/12/3/228. In fact, Linus Torvalds recently stated about Naughton’s article that “It seems totally bogus,” Torvalds told IT World’s Brian Proffitt. “We’ve always made it very clear that the kernel system call interfaces do not in any way result in a derived work as per the GPL.” http://www.networkworld.com/community/node/72428.
Nonetheless, his concluding paragraph focuses on the risks arising under copyright law, a focus which is misplaced: the critical issue, is whether the scope of the modified GPLv2 applied to Linux rather than US copyright law. In fact, his risk of application of the copyleft provisions of the GPLv2 only arises if (i) the Linux header files (as “cleaned” by the Google development scripts) are copyrightable and (ii) the Bionic software reproducing and distributing are “based on” the Linux kernel and, thus, are not exempted by the limitations on “derived works” in the Note. The “copyright” part of his analysis also has flaws although the result is considerably less clear for this analysis than the analysis of the interpretation of the modified GPLv2 (and we may not have all of the relevant facts). For example, one factual error in his discussion is his reference to the Linux header files as part of an “Application Programming Interface”: these files are part of an Application Binary Interface”. It is not clear whether this programming difference has legal consequences, but it is critical for this type of analysis to ensure that the underlying facts are correct.
Even the copyright argument has problems: the copyrightability of the Linux header files is subject to serious doubt. Copyright law protects “works of authorship fixed in a tangible medium of expression.” However, software programs are functional (unlike books and movies) and the scope of protection is limited. The most widely used legal test for determining copyright infringement in software programs expressly limits the scope of protection for certain parts of software program (the “filtration” step):
Professor Nimmer points out that “in many instances it is virtually impossible to write a program to perform particular functions in a specific computing environment without employing standard techniques.” 3 Nimmer § 13.03[F], at 13-65. This is a result of the fact that a programmer’s freedom of design choice is often circumscribed by extrinsic considerations such as (1) the mechanical specifications of the computer on which a particular program 710*710 is intended to run; (2) compatibility requirements of other programs with which a program is designed to operate in conjunction; (3) computer manufacturers’ design standards; (4) demands of the industry being serviced; and (5) widely accepted programming practices within the computer industry. Id. at 13-66-71. http://scholar.google.com/scholar_case?case=6976925648486076739.
Steven J. Vaughan-Nichols noted recently that he interviewed Eric Raymond, then president of the Open Source Initiative, during the SCO litigation and “Eric told him that there was a “reason why Unix and Linux’s header files looked the same: “Do you know that there is not one bit of executable code in those files? They’re pretty much all macros and declarations forced by POSIX and other technical standards.” http://www.zdnet.com/blog/open-source/does-googles-android-violate-linuxs-copyright/8497. Linus Torvald in a statement on March 22, 2011 made the point even more strongly, calling Naughton’s claims “bogus”. These statements are helpful in analyzing the copyrightability of the Linux header files, but only a court can provide a final answer. However, it is interesting that all of the cases cited by Naughton relating to “interfaces” found that the interfaces are not copyrightable.
This dispute reflects the challenges of the analysis of open source legal issues: the law in this area is uncertain and the analysis is very fact dependent. However, the statement that the law is uncertain regarding software is not unusual: this uncertainty has existed from the date that Congress debated whether to apply copyright to software under the Copyright Act of 1976 (they set up a special group to review the issue among others after the adoption of the 1976 Act, the National Commission on New Technological Uses of Copyright Works) Although the violation of the GPLv2 does not appear to be a problem for Android, Android has more than its share of lawsuits on both patent and copyright claims. Anyone who is using Android in their products needs to ensure that they understand these risks and monitor the progress of these suits.