Just a reminder, these posts are not legal advice. This site is the personal blog of Mark Radcliffe and the opinions expressed are those of Mark Radcliffe and not those of his clients, DLA Piper or the clients of DLA Piper.

About Me:

Mark Radcliffe

I have been practicing law in Silicon Valley for over thirty years assisting startups and global companies develop and market innovative products and services. I have participated in multiple business cyles in Silicon Valley from hardware to software to internet to cloud. My projects have included developing the dual licensing business model for open source startup, developing the original domain dispute resolution policy for NSI and assisting Sun in open sourcing the Solaris operating system. Recently, I served on the US Japan Innovation and Entrepreneurship Council (one of ten members) to develop a plan to encourage the innovation in Japan and the United States. I have been working with the same attorneys since 1986 although we have merged with other law firms several times. I am now a partner at DLA Piper, a (relatively) new global law firm formed in 2005 from the merger of three law firms. The firm now has 4200 lawyers in 31 countries and 77 cities. My experience in corporate securities (particularly venture capital) and intellectual property enables me to assist companies structure the financing and intellectual property strategy for developing ane exploiting a new product or service. I and my team work with fifty startups at one time as well as Global Fortune 100. I have been fortunate enough to work with companies in software, cloud computing, semiconductor, health care IT and Web 2.0.

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. 

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 theyve 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”

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.”  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.” 

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][3], 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.

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.”  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.