Oracle v. Google – Copyrightability of APIs

By Michaela Barry, Counsel, Potomac Law

On May 9, the US Court of Appeals for the Federal Circuit handed down their ruling on the appeal (and cross appeal) of Oracle v. Google, a very interesting case that could have wide impact on the use of “application programming interfaces” or APIs.  At issue are 37 Java packages, 8 specialized Java security packages, and a routine called “rangeCheck.”  Oracle claims that Google infringed on its copyrights in the packages and rangeCheck, in using them in the Android operating system without license.  Google admits copying eight of the files verbatim, and that they copied the declarations sections of the other 37 Java packages, but that they were not guilty of infringement because they had an affirmative defense under the “Fair Use Doctrine.”

The ruling from which both parties appealed is a mixture of jury verdict and judge’s decisions from the Northern District of California’s Federal District Court.  The parties agreed in the district court case that the jury would decide on infringement and fair use, including whether the copying was “de minimus,” which would lead to a not guilty verdict on infringement.  Meantime, the judge would decide on whether the API files were copyrightable, and if so, would go on to decide whether Google had an adequate equitable defense to infringement. The jury returned a verdict of infringement of the 37 Java packages and rangeCheck, but said that there was no infringement as to 8 decompiled security files that Google claimed made up the “core” of the Java operating system.  The jury explained that it was necessary to use the 8 decompiled files verbatim, in order to access the Java language.  The jury could not reach a verdict regarding fair use.

Once the jury had completed their findings, Oracle asked for a judgment as a matter of law (“JMOL”)  which would throw out the defense of fair use since the jury hadn’t reached a verdict.  Oracle asked, in addition, that the judge nullify the jury verdict on the 8 security files and find that Google’s use was infringing.   Google asked for a JMOL on the rangeCheck files, which would basically nullify the verdict of infringement for that program.  The judge ruled that the 8 security files were indeed infringed, since Google admitted copying them verbatim, and no reasonable jury could find that the copying was de minimus and therefore excused.  The judge denied Google’s motion regarding rangeCheck..  In addition, the district court found that none the elements of the 37 API files were copyrightable, but rangeCheck and the 8 decompiled security files were copyrightable.  The final verdict, in a nutshell, was that Google was guilty of infringement of the 8 decompiled security files, and rangeCheck, with no affirmative defenses.

On appeal, the Federal Court of Appeals decided that the district court was incorrect on several counts.  First, the court ruled that the 37 API files were indeed copyrightable, and since the jury found infringement, Google was guilty of infringing the 37 API files, the 8 decompiled “core” files, and rangeCheck.  However, since it was up to the jury to determine fair use, which was Google’s defense, that part of the case goes back to the district court for determination.  The district court’s granting of Oracle’s JMOL that excluded fair use as a defense for the 8 decompiled files was upheld by the appeals court.  Google’s request for JMOL to reject the jury’s verdict of infringement on rangeCheck was denied.

In other words, Google is guilty of infringement of 8 decompiled security files, and rangeCheck, and the 37 API files.  Google has no available defense regarding the 8 security files it decompiled and copied verbatim.  The case now goes back to the jury to decide whether Google has a defense against the infringement, such as fair use, which would result in a not guilty verdict.

The Court’s Reasoning for Finding Copyrightability 

In order to determine whether a copyright is infringed, the first step is determining whether the copyright itself is valid. This can often be a difficult analysis when dealing with specific software functions such as APIs that are meant to be interoperable with a given software language.  At the center of the court’s analysis was the question of whether or not the verbatim copying of Oracle’s code was necessary in order to access the functionality of the Java language and programming platform.    The crux of the matter seemed to come down to whether or not the verbatim copying of Oracle’s code was necessary in order to access the functionality of Java.  There were several additional considerations that the court looked at, which will be taken in turn.


The district court concluded that “there is only one way to write” the declarations to interface with Java.  If true, the use of identical declarations would not be copyrightable.  However, except for three of the API packages, Google did not dispute the fact that it could have written its own API packages to access the Java language.

Oracle argued, and the appeals court agreed that the files in question consisted of two parts: 1)  literal elements, as in 7000 lines of declarations in the source code, and 2) non-literal elements, being the structure, sequence, and organization of each of the 37 API packages.  Infringement of the literal elements, according to the court, occurred through the verbatim copying of original expression.  Non-literal, in this case would be paraphrased, or loosely paraphrased copying, rather than word for word.  Oracle claimed copyright in both literal, and non-literal aspects.  The appeals court analysis did not proceed to non-literal copying, since Google conceded that it copied the declarations verbatim.  The court found that since the literal aspects were copied, the underlying code was then copyrightable.

Oracle’s Appeal 

Oracle appealed from the district court decision that none of the elements of the 37 API files were copyrightable.  Their argument was that the code was original, and as such met the standard for copyrightability.  As issues of whether or not a work is copyrightable are reviewed “de novo” (reviewed ‘fresh,’ without any reliance on the previous ruling), the appeals court took a new look at the files, while noting as undisputed, two key premises of the previous decision:

  1. Java is open and free for anyone to use (with appropriate licensing for commercial use)
  2. Google could have written its own API packages using Java, but instead copied the declarations files and replicated the overall structure, sequence and organization of the 37 API packages.

While examining this issue, the court made note of a telling line in Judge Boudin’s concurring opinion in Lotus Dev. Corp. v. Borland Int’l, Inc., 47 F.3d 807:  “Applying copyright law to computer programs is like assembling a jigsaw puzzle whose pieces do not quite fit.”  The court acknowledged that examination of the jigsaw pieces was indeed a difficult task, but also concluded that the district court did not properly separate the concept of copyrightability and the concept of copyright infringement.  The district court used factors that should have been examined solely in relation to infringement, in their analysis of copyrightability.

The appeals court found that the threshold for copyrightability is a “low bar” and in this light, the 37 API packages were indeed copyrightable.  The requirement for a work to be “original” in order to be copyrightable is not difficult to reach.  Originality, as defined in Feist Publ’ns, Inc. v. Rural Tel. Serv. Co., 499 U.S. 340, 358 (1991) is: “only that the work was independently created by the author (as opposed to copied from other works), and that it possesses at least some minimal degree of creativity.”  Id. at 345.

Google’s argument was not based on the originality of the API pages, but instead argued that a work cannot be copyrightable if it is also functional.  They cited Section 102(a) of the Copyright Act, claiming that this section takes away any designation of copyrightability if there are any functional components to the work.  The appeals court disagreed, and cited the Congressional Record (H.R. Rep. No. 1476, 94th Cong., 2d Sess. 54) “Section 102(b) does not extinguish the protection accorded a particular expression of an idea merely because that expression is embodied in a method of operation.”

Google’s final argument revolved around the doctrines of merger and scenes a faire, both of which relate to the concept that as copyright can only apply in the expression of an idea rather than the idea itself, if a given idea can be expressed in only one, or a very limited number of ways, it can not then be copyrightable.  The idea becomes as the idea becomes so intertwined with its expression that the two are “merged.”  Google argued, in order to utilize Java, there are only very limited number of ways you can write the API in order to access Java’s functionality. While this is an argument that many Java programmers agree with, the appeals court disagreed that these doctrines should be considered in concluding whether or not a work is copyrightable as a threshold factor.  They instead concluded that both merger and scenes a faire should only be considered to determine whether or not a work has been infringed, as expression of an idea that may only be expressed in a limited number of ways, was fair use and should be examined as a defense to copying, and not as dispositive of whether or not the expression could be copyrighted.

Functions, Parameters, Variables and Declarations

The argument by many Java programmers that there are very limited ways to express variables and functions in which to access the Java language through creating an API package is an agument worth examining.  There is no doubt that using a standard set of variables and function calls is much easier for others to understand and further develop upon (which was the original point of the General Public License concept under which Java was originally released).  The GPL concept is that the licensee can use the declarations and implementing code verbatim, in any way it wishes, so long as it “contributes back” the innovations to the public domain.  This is called the “open source” license, and is free for use so long as the user returns any source code it creates to the community for continued usage.  This model is not often appealing to companies that pay for development of a product for sale.  Those companies have two options:  the first, a Specification License, which allows a company to write its own implementation code and use the declarations and general organization of Oracle’s code.  If Google had chosen to purchase a Specification License, there would have been no infringement question, as Google created its own implementation code and used Oracle’s declarations and general organization in a manner in which the license contemplated.  The second option is a Commercial License whereby a company can use all of Oracle’s code, declarations, organization, implementation, etc. while keeping its own code secret.

Indeed, Google was in negotiations with Sun (predecessor to Oracle) to purchase a license for a derivative version of the Java platform for use on mobile devices, called Java Micro Edition.  Google and Sun also discussed co-development, partnership, or other types of ventures under which they could co-produce a mobile operating system.  The sticking point was that Google wanted all code to be proprietary rather than compatible with the Java virtual machine or other Java programs.  For this reason, Sun did not grant Google a license to the packages.  The court was no doubt influenced by the fact that Google had originally determined that they would need a license to use the API packages, and when denied, decompiled and used them verbatim.

The court found the 37 API packages to be indeed copyrightable, as they are expressive, and “could have been written and organized in any number of ways to achieve the same functions.”  As Google admitted to copying the declarations verbatim, Google infringed Oracle’s copyright by definition.  The remaining question is whether or not that infringement was “fair use” under either the Merger Doctrine, or other interoperability arguments.

Evaluation at the Time of Creation 

An interesting discussion in the opinion, which could be seen as dicta concerns infringement analysis, which was not a question the appeals court was asked to decide.  The court provided guidance regarding how the Merger Doctrine could still be used in order to evaluate claims of infringement.  The district court had originally found that the Merger Doctrine applied to the 37 API files because “under Java, a programmer must use the identical declaration or method header lines to declare a method specifying the same functionality.”  However, a key point that the lower court missed was when one analyzes whether the identical declarations must be used.  In this case, as in many cases of interoperability and necessity of duplication, timing was everything.

Copyrightability and the scope of protectable activity (which is a key component of an infringement analysis), is evaluated at the time of creation, not at the time of infringement Apple Computer, Inc. v. Formula Int’l Inc., 725 F.2d 521, 524 (9th Cir. 1984.) (emphasis added).  So, when Sun created Java, and the API packages, example questions to ask include whether it would have been possible, at the time Java was created, to call the package by another name, defined as such in the declarations?  Would it have been possible to name the variables in another way?  Would the functions have to be in any specific order?  The district court, interestingly enough, had found that nothing in the rules of Java required the same groupings of function calls or declarations, found that there were many ways to express the code, yet still found that the API packages were not copyrightable.  The appeals court made a point to mention that the “core” Java files, when Java was created, had greatly limited the expression of functions, classes, and variables, idea and expression may then have been merged, and the Merger Doctrine may apply.  However, Google did not argue this, nor differentiate between the types of packages it was accused of infringing.  Google did not build a factual record to support its argument that external factors that existed at the time of creation, mandated that the expression of the API packages were either common, or essential to the functionality of their implementation code.  Had they done so, the court hinted that their findings may have been different, at least with regard to the core programs.

The appeals court states outright, quoting an amicus filed by the former Register of Copyrights of the United States, “[h]ad Google reverse engineered the programming packages to figure out the ideas and functionality of the original, and then created its own structure and its own literal Code, Oracle would have no remedy under copyright whatsoever.”


The court’s findings could also have been swayed by findings of the district court that Google intended to capitalize on the familiarity that developers already had with the Java API packages they copied.  The district court stated outright that “Google’s interest was in accelerating its development process by ‘leverag[ing] Java for its existing base of developers.”

What’s Next?

This is hardly the end of the story.  Although the court found that the 37 Java API packages are copyrightable, and the jury at the district court level found infringement, the appeals court reversed the district court on copyrightability, and reinstated the jury’s verdict.  Therefore Google is guilty of copyright infringement for the 37 Java API files.

However, the matter of whether Google has sufficient affirmative defenses, such as fair use, to dismiss the infringement as inapplicable, goes back to the district court jury to determine, as the previous jury deadlocked on the issue.

The court also held that the eight decompiled files that Google used were also infringed, as was rangeCheck.  These findings also go back to the jury for analysis to determine whether there are any affirmative defenses.