Network Effects & APIs: Oracle v. Google in 2018

Posted By: Alek Emery

  1. Introduction

OracleLogoThis March, the Circuit Court of Appeals for the Federal Circuit issued its most recent decision regarding a copyright dispute between Oracle and Google going back to 2012. This ongoing battle over the copyrightability of elements of Oracle’s Java API has drawn out for years and created significant uncertainty in the software industry. Generally speaking, the dispute raises questions about the protections available for software under copyright law for Application Programming Interfaces (APIs) that facilitate communication between software components and programs. In 2014, the Federal Circuit first reversed the decision of a district court in the Northern District of California on the copyrightability of Oracle’s Java API elements, but left open the possibility for Google to raise a fair-use defense. Now, several years later, the appellate court has ruled that the copying by Google of some portions of the Java API packages was not a fair use as a matter of law. This article is intended to provide a brief overview of the dispute and the aspects of copyright protections available for software that are implicated. Subsequently, the decision will be discussed within the larger context of the goals of copyright law and promoting the innovation of new technology and ideas.

  1. Background
    1. APIs, Computer Programming, and the Law: A Brief Overview

Software, due to its combination of expressive and functional elements, has presented challenges in both copyright and patent law for decades. For example, it was in the mid 1970s when the Commission on New Technological Uses of Copyrighted Works (the “CONTU Commission”) stated that creative aspects of software could be copyrightable. The Copyright Act was amended in 1980 to incorporate the CONTU Commissions findings, and copyright law has been one of the primary means of protecting software since.

One of the difficult aspects of protecting software via copyright is in determining what elements are eligible for copyright protection—with the “abstraction/filtration/comparison” test from the 1992 Altai case having become the popular methodology. Under this test, those elements of software code that are necessarily tied to the expression of the ideas embodied within the code—which are not copyrightable—are ineligible for copyright protection and “filtered out” during an infringement analysis. This sets the legal backdrop for the original dispute between Oracle and Google over protecting APIs.

Application Programming Interfaces are the elements of an application that enable it to communicate with end-users and other software. In a very generalized sense, an API provides the means for software programs to interact with other programs or components by defining how the data being input and output should be formatted. Because the API defines how to communicate with a program, it has an intrinsic connection to the structure of the program. For example, if you are sending a request for data to a server running a program that stores lots of different types of files in different formats, the server program’s API should inform you of how to make the request and what type of output you want it to return to you. This may require you to specify “where” the server should pull the data from—and this depends on how the storage program is structured. The “structure” of software code may be copyrightable as a “non-literal element” of the program (under the Altai test). This concept predates even the Altai case, in the form of an argument by analogy to the non-literal elements of a book such as the plot, discussed at least as early as 1985 in the SAS Institute, Inc. v. S & H Computer Systems, Inc. case.

However, those portions of the software that do not represent “original” contributions by the author, like modules or code snippets incorporated to provide common functionalities to a program without having to “re-invent the wheel” for every program, are not protected by copyright. Likewise, those portions of the software code that are necessarily tied to the functioning of the software would not be copyrightable.

So, to summarize, an API is tied to a program’s structure (a non-literal element) and it can contain creative contributions by an author, but, it is also inherently functional and designed to allow for the author’s program to communicate with other programs or components.

b. Oracle and Google’s Fight over Copyright Protection for APIs

This is where the debate over copyright for Oracle’s Java APIs comes in. The Java interface seems to present many creative choices made by Oracle—for example, the names of different classes in Java. But, it is also functional because the API is intended to communicate with other software or other components of the program—and this requires some ability to find a common format for inputs and outputs. This difficulty in determining if an API can be copyrightable was examined by the Federal Circuit in 2014, and the court found that APIs could be protected by copyright. In particular, the court found that Oracle had copyrights in at least some of the Java API code and that Google had directly copied some portions of it into its Android operating system. The debate over whether copying from the Java API could be a fair use was left open by the 2014 decision, and it was this issue that the court returned to in its 2018 ruling.

  1. The 2018 Federal Circuit Decision

After remanding the case for an examination on the issue of fair use by Google in copying some of the Java API code, the case was presented to a jury. The jury found in favor of Google. Oracle moved for the jury verdict to be overturned, but the district court denied this motion and entered judgment against Oracle. Oracle then appealed the decision back up to the Federal Circuit. For those readers interested in why the case was before the Federal Circuit in the first place, it is because the court has exclusive jurisdiction over cases where patent claims are at issue. For the sake of brevity, issues regarding the standard of review and other tangential matters will not be discussed here. For those readers interested in those portions of the opinion, it can be viewed here.

Fair use is one of the more conceptually difficult aspects of copyright law. Codified into the law as 17 U.S.C. § 107, the “fair use” of materials that would otherwise constitute copyright infringement is one mechanism for balancing the exclusive rights granted by a copyright against the socially beneficial activities the incorporate concepts or materials previously copyrighted. The Supreme Court examined the issue of fair use in Campbell v. Acuff-Rose Music in 1994. The important takeaway from that case being the balancing of the four factors that are codified in § 107. For the purposes of this article, more in depth examination of the factor test is not necessary and will be omitted. The focus will instead be on the court’s discussion of the way that Google copied the Java API code and how that seems to color the court’s perception of Google’s use as not being “transformative.”

Google previously sought a license from Oracle to use the Java API packages within the Android operating system, and after failing to reach an agreement with Oracle, Google decided to copy portions of Oracle’s code that would help developers trained on Java migrate to the Android platform. Google did not take all of the code, but it kept some portions of the declaring code and Structure, Sequence, and Order (SSO) while providing its own new implementing code. Keeping this in mind, the court’s decision can be generalized as follows:

1. The court had already ruled on the copyrightability of the Java APIs in 2014, and the Supreme Court had denied cert. on that issue after getting input from the Solicitor General;

2. Google copied some portions of the code in their entirety, and this was after Google had failed to reach an agreement with Oracle to use their Java API in Android;

3. Google copied from Oracle to make it easy for programmers to make the switch to Android and to save itself from having to go through the effort of developing new code for the functionality it wanted to incorporate;

4. Google’s use of the copied code was not transformative, because the code was still being used to accomplish the same function and the context of being used on mobile devices was not new for the Java API; thus

5. As a matter of law, the § 107 factors weighed in favor of Oracle and there was not a basis in the record for a reasonable jury to find otherwise.

This is a very broad generalization of the opinion, but it presents the most important aspects of the court’s reasoning. Specifically, the court did not reverse course on its prior ruling on the copyrightability of APIs—meaning that there was a valid copyright that could be infringed. The reasons for Google’s copying of Oracle’s code might promote interoperability, but taking for the “convenience” of making it easy for people to program in Android weighed against fair use. And, perhaps most importantly, that Google had not provided a “transformative” use of the copied code when it used it to accomplish the same things that it had been originally created to do.

  1. Analysis and Discussion

Readers familiar with the Electronic Freedom Foundation (EFF) will not be surprised to learn that the Foundation was very critical of the Federal Circuit’s decision. And, to the EFF’s credit, it is true that the decision does cast some legal uncertainty on the practice of copying from an existing program to create competitive interoperable alternatives. But as some commenters have observed, perhaps the EFF is a little off target when it comes to its predictions for the terrible consequences this decision will have on innovation. Copyright protections for software are designed to incentivize innovation, but that is not always easy to accomplish. This is especially true when attempting to find the proper balance between the rights of the author and those of society to build upon the author’s ideas. Fears about industry first movers entrenching themselves within an industry by excluding competitors through copyrighting APIs have been thoroughly examined in academic articles—like Fred von Lohmann’s article in the Harvard Journal of Law and Technology. But, as the court makes clear, this case doesn’t stand for the principle that APIs could never be copied as a fair use. It only finds that the copying that Google engaged in was not a fair use.

Focusing myopically on the fears of entrenchment, commenters like the EFF risk overlooking the potential incentives for innovation that providing copyright protection to APIs offers. At the very least, those types of balancing decisions should probably be left to the legislature rather than the courts. If the Federal Circuit’s decision tends to chill innovation, then Congress can adjust the laws to correct the balance. If, and until that proves to be the case, it seems that the court’s decision has received a less-than-fair reception.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s