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.
The recent series of open source projects who are working to integrate with proprietary software (such as the driver for Microsoft’s Kinect and Apache’s Harmony project relating to Java) demonstrates the difficulty the copyright analysis of these types of interaction. Some guidance is available from England: the recent decision in the case of SAS v. WPL provides some guidance. SAS challenged the established view as to the limits of copyright protection for computer programs. However the decision this summer is not final because the court has referred interpretation of certain provisions of the copyright law to the European Court of Justice (”ECJ”). http://www.bailii.org/ew/cases/EWHC/Ch/2010/1829.html#para332.
Kit Burden, one of my London colleagues, explained that in 2004 and 2007 the English courts confirmed that competitors are free to study how software works in order to write a program mimicking its functionality. The courts also said that programming languages themselves, and any software interfaces, fall outside of the scope of copyright protection.
SAS, a major player in the analytical software, is challenging this view. It does so following the actions of WPL, a smaller software house. WPL studied SAS’s software, wrote its own software (there was no suggestion that SAS’s source code had been copied), tested its software by running it on SAS’s Learning Edition products, and then offered it to customers as a cheaper, alternative to SAS’s product with much of the same functionality.
SAS’s arguments are essentially:
· that WPL breached copyright in SAS’s software both indirectly (by studying SAS’s software and SAS’s manuals in order to develop software which would function in the same way) and directly (by using SAS’s Learning Edition to test this new WPL software - in breach of license) and
· that WPL breached copyright in SAS’s manuals in the way that it used them to develop its own software and, more straightforwardly, simply because WPL’s user manual is so similar to SAS’s user manual
The English court’s judgment was handed down in the last week of July. Both sides claim some success.
The judge did agree that the two user manuals were too similar; WPL will rewrite them.
However he remained unconvinced as to SAS’s other, more significant, arguments. On balance, he believes the earlier decisions of the English courts were correct - that programming languages, interfaces and functionality do all fall outside of the protection of copyright. He also believes that the breached license term was void and unenforceable. On this analysis, WPL is in the clear.
However, there remains some doubt. The judge agrees that interpretation of the relevant legislation is not clear cut and has asked the ECJ for guidance.
Given the potential to broaden copyright protection to include functionality, “look and feel” and so on, the industry will be closely monitoring this referral. That said, the ECJ’s opinion is not expected soon. These issues will continue to arise as proprietary software and open source software become more integrated.