Get the highlights in your inbox every week.
Oracle v. Google and API copyrightability
Oracle v. Google and API copyrightability
As has been widely reported, the district court in the Oracle v. Google case has issued an order holding that the "structure, sequence and organization" (SSO) of 37 J2SE 5.0 API packages is not copyrightable. Oracle is expected to appeal.
The API packages at issue, comprising over 600 classes and over 6,000 methods, form part of the 166-package class library bundled with Sun's J2SE 5.0 JDK and JRE products. The accused 37 of the 168 packages in the Android Froyo platform's Dalvik class library substantially replicate the namespace hierarchy, class declarations, and method declarations of these J2SE packages, and provide equivalent functionality. Oracle claimed that this replication was copyright infringement, despite the fact that Google's implementations of the classes and methods were independently developed. From a source code perspective, 97 percent of the corresponding 37 API packages in the two platforms was dissimilar.
No US court had previously examined the copyrightability of APIs, let alone the SSO of a set of APIs. As was true of the recent SAS v. WPL case in the EU, the issues here principally involved the distinction between copyrightable expresson and noncopyrightable idea. Section 102(b) of the 1976 Copyright Act codifies this distinction, stating that copyright does not "extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery".
In asserting an SSO infringement theory, Oracle was drawing on a line of cases that had recognized a residual copyright interest in software where there was no literal copying of source or object code. As the court explained, judicial support for nonliteral software copyright infringement theories peaked in the 1980s. Since then, courts have been more cautious, mindful of 102(b) and the need to prevent extension of patent-like monopolies to the copyright sphere.
There were two parts to the court's holding. First, the court addressed Java platform APIs on an individual level. The court held that anyone could replicate the functionality of the API classes and methods, using identical declarations, so long as the implementations did not copy from the original version. The court made much of the fact that Java's syntactic rules mandated use of identical declarations (modulo class and method names) in order to develop an independent implementation that would provide the same functionality as the original. Under the merger doctrine, where there is only one way of expressing a given idea, no one can claim copyright ownership of such expression. While it was not necessary to replicate the names used in the API packages, names are themselves not copyrightable. Despite the emphasis on Java syntax, the court's reasoning seems applicable to APIs generally, as well as to typical varieties of the technically distinct category of web services APIs.
The court then addressed the copyrightability of the 37 API packages as a whole. Oracle claimed that it was copyright infringement to group the various packages, classes and methods in the same taxonomic manner as the J2SE class library. Nothing in the Java language dictated any particular organization in order to provide equivalent functionality. However, the court considered the J2SE organization to be a noncopyrightable utilitarian "command structure" for carrying out specified functions. Moreover, interoperability considerations suggested that the 37 API packages as a whole were a 102(b) "system" or "method of operation". Essentially, the court concluded that it was necessary for Google to provide the same "command system" with the same taxonomic organization, names and functional specifications in order for some of the massive amounts of existing third-party Java code to be easily portable to Android, since such existing code assumed the availability of common Java platform APIs.
Relevance for open source
It is an interesting peripheral fact that both Oracle and Google release versions of the relevant class library codebases to the public under open source licenses. Source code for the Dalvik class library, which is based on a subset of the late Apache Harmony project, is available under the Apache License 2.0. Oracle has continued Sun's post-2006 practice of releasing source code for versions of the Java SE class library under GPLv2 with the Classpath Exception, as part of the OpenJDK project. The Classpath Exception, which transforms GPLv2 into an MPL-like weak copyleft license, was adapted from the license for the GNU Classpath project. GNU Classpath (which remains in active development) and Apache Harmony, both of which aimed to produce complete independent implementations of core Java class libraries, are legacies of years of tension between the free software developer community and Sun over the latter's efforts to maintain control over Java, one lasting effect of which was a cultural isolation of the open source Java ecosystem.
The issue of API copyrightability has deeper historical resonance. Much of the history of free software has been characterized by efforts to develop replacements for elements of dominant or popular proprietary platforms, systems and protocols. This is seen not only in the various free JVM and Java compiler and runtime projects, but also in the earlier efforts to develop unencumbered clones of Unix (GNU, late versions of BSD and their descendants, and Linux). "Interoperability" in the sense meant in the Oracle v. Google order may be seen as an objective of many such projects.
During the late 1980s and early 1990s, pivotal years for the development of free alternatives to proprietary Unix, the free software developer subculture was aware and fearful of judicial recognition of nonliteral infringement theories in software copyright cases. While the influential Richard Stallman was prominent in calling attention to the dangers of "interface copyright", his critics accused him of advancing a theory similar to interface copyright in his interpretation of the GPL as applied to software libraries. (The introduction of the LGPL was, in part, a product of this conflict.) But both pro-copyleft and anti-copyleft camps were united by a basic belief that law should not be used to prevent the development of unencumbered interface-compatible reimplementations of proprietary software. The Oracle v. Google decision on API copyrightability, which one suspects validates the policy intuitions of most developers, is well within the spirit of that belief.