First published in Intellectual Property Today
Oracle's "Java", originally released in 1996, is the world's most popular programming language. It allows developers to write programs, which in turn can be used on varying computer hardware. In an effort to design its own mobile platform, Google used the Java language and announced its Android software platform for mobile devices in 2007. In response, Oracle brought suit against Google in Oracle America, Inc. v. Google Inc., 872 F. Supp. 2d 974 (N.D. Cal. 2012). In May of 2012, the United States District Court of the Northern District of California held (among other holdings) that certain elements within the application programming interface of Oracle's Java programming language, including the structure, sequence and organization of the Android software platform, are not subject to copyright protection. Oracle appealed the decision to the Court of Appeals for the Federal Circuit and oral arguments were heard on December 4, 2013.
The Java language includes words, symbols, and a set of pre-written programs which carry out its various commands. The set of prewritten programs, or commands, are known as the application programming interface ("API"). The hierarchy of the API is composed of approximately 160 "packages," broken into about six hundred "classes," all broken into about six thousand "methods." To simplify the complex program, the Court used an analogy: "An API is like a library. Each package is like a bookshelf in the library. Each class is like a book on the shelf. Each method is like a how-to-do-it chapter in a book." Because the methods and classes are used by programmers to carry out particular functions, the function header, or "declaring code," of each command within the Java and Android libraries must be identical in order for the functions to take place. Hence, although the Java and Android libraries are similarly organized in order to solve the same problems, the chapters are different.
Because the declaring code and hierarchy of more than six-thousand commands carry out varying pre-assigned functions, in Oracle the district court held that the commands were not subject to copyright protection, finding that Section 17 U.S.C. § 102(b) of the Copyright Act does not provide protection for a "method of operation." Google did not challenge the copyrightability of the API as a whole (but Google does contend that each of the thousands of individual files in Version 5.0 of the Java 2 Platform, Standard Edition do not constitute a "work as a whole" as the district judge erroneously instructed, and thus copyright protection extends only to the individual files as they are a part of the Java platform). Accordingly, the district court did not consider the copyrightability of the API as a whole and that issue is not part of the appeal. Below, we summarize the legal and policy arguments on appeal, both for and against copyright protection for the declaring code and hierarchy of the Java API.
Arguments Against Copyright Protection
Legal Arguments Against Copyrightability
Although the Copyright Act requires a low threshold for copyright protection, it also includes robust exclusions to filter out and deny protection for functional elements. The more functional the work is, the more there is to filter out. 17 U.S.C. § 102(b) states: "In no case does copyright protection for an original work of authorship extend to any idea, procedure,process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work." (emphasis added) Case law has held that if a program's hierarchically arranged command structure is essential to accessing, controlling, or using the program, it is an uncopyrightable method of operation under § 102(b). Case law has also held that even though a program may be copyrightable overall, § 102(b) filters out and denies protection for elements within the program that are dictated by the function to be performed, or by external factors such as compatibility requirements and industry demands. Moreover, case law is clear that when the design choices of subsequent programmers are constrained by the interface designs in earlier programs, the merger doctrine applies to the reuse of elements necessary to achieving interoperability. The only requirement of subsequent programmers is to re-implement the necessary elements in independently created code.
Policy arguments that claim exclusions undermine copyright protection for computer programs simply read the exclusions out of the statute. The legislative history of the Copyright Act of 1976 indicates that Congress was aware that computer programs would include numerous types of unprotectable processes and methods of operation. Congress specifically added the § 102(b) exclusions to ensure that copyright protection for programs would not be interpreted too broadly.
Policy Arguments Against Copyrightability
The uncopyrightable nature of declaring code and API hierarchies spurs the creation of software that otherwise would not have been written. When programmers are free to re-implement or reverse engineer an API, they can create compatible software that the API's original designers might never have been able to create, thus sparking new innovation. This freedom is especially important for software start-ups. This freedom also helps rescue "orphan" software—systems whose creators have gone out of business or abandoned their products. Also, compatible APIs enable users to switch platforms and services freely.
In contrast, if a company could exercise proprietary control over declaring code and hierarchies, it could determine which third-party products—if any—could interoperate with its software. Without competition, early market entrants could lock users into a particular software environment, and would have little incentive to develop better software. Moreover, copyrightability of declaring code and hierarchies is contrary to the current and historical practice and expectations in the software industry. Software developers and users would face legal uncertainty if these elements were afforded copyright protection. Such legal uncertainty would translate into a chilling effect on financial investment, which is especially important for software start-ups.
Arguments for Copyright Protection
Legal Arguments for Copyrightability
The Copyright Act requires a low threshold for copyright protection—any creative spark generally suffices. The declaring code and hierarchy of an API are therefore protectable because the API's designers exercised creativity in designing those elements. The declaring code and hierarchy can be written and structured in numerous ways that reflect the creative choices of the designers, but nevertheless achieve the exact same function. Thus, the creative expression in the declaring code and hierarchy demands copyrightability. Also, since the same function can be achieved in various ways, copyrightability does not amount to a preemptive monopoly over the function, and thus the merger doctrine1 does not apply.
In addition, copyrightability extends to hierarchies—the non-literal and original selection, coordination, or arrangement of content. It is apparent from the definition of compilations and derivative works, and the protection afforded to them, that Congress believed that the sequencing and ordering of materials are copyrightable.
Moreover, interoperability is irrelevant to copyrightability. Instead, a court should consider interoperability in a question of fair use during an infringement analysis. Even if interoperability were a factor for copyrightability, a court should consider it separate from the perspective of the API's designers, considering what constrained them and the extent to which their choices were dictated by the need to interact with other programs. The interoperability of the accused program with other programs should not affect whether the API is subject to copyright protection in the first instance.
Policy Arguments for Copyrightability
APIs play a central role in modern information systems, and it is important to incentivize development of APIs. Denying copyright protection for declaring code and hierarchies would upset the expectations of API designers who believe that the code they painstakingly develop would receive the same copyright protection afforded to any other source code or literary work.
Also, software companies need reliable copyright boundaries to enforce a consistent set of practices that maximize productivity, interoperability, and innovation. Denying copyright protection for declaring code and hierarchies would introduce doubt in which software elements qualify for copyright protection. Software companies would retrench and only disclose information about their programs in more restrictive and costly ways to prevent harmful misappropriation of their innovation. This would lead to a chilling effect in software innovation. Denying copyright protection for declaring code and hierarchies would also lead to "fragmentation" of APIs. An API is written by skilled designers and often supports critical features and dependencies not explicitly described in accompanying documentation. Without control on subsequent API usage through copyright protection, third parties less knowledgeable about the API may modify it and introduce unanticipated vulnerabilities and instability.