The Federal Circuit has issued a copyright opinion that stands to radically alter both copyright law and the software industry. The case involves the first-ever reversal of a jury on the question of fair use, and the first time that APIs (described below) and their organization have been protected by copyright despite a fair use defense.

At the center of the controversy in Oracle America v. Google are application programming interfaces (APIs): instructions that invoke (or call up) entire programs, provide those programs with bits of data, and receive back the results of processing using that data.

To illustrate a simple API, imagine an instruction that reads: SQRT 4, where the command “SQRT” invokes a program that calculates the square root of the number that follows the command. The hard work is done by an implementing program. The command “SQRT 4”, called the “declaring code”, is a simple command that seems to involve little or no imagination or expression. Instead, it seems purely functional, exactly the sort of development that is denied copyright protection and that can be protected, if at all, only by patent law.

The Development and Cloning of Java. In the 1990s, Sun Microsystem developed the Java platform, which was designed to allow programmers to write code that, once written, could run on any popular computer hardware. While Sun presented Java as open source software, and thus made it freely available to all, it kept tight reins on its evolution as a product that would carry the “Java” trademark. It also kept some key components proprietary and demanded license fees for the complete Java package.

Sun was successful in developing a community of programmers who wrote code and contributed it to the Java platform. In time, there would be 30,000 such programs (called “methods,” in Java parlance) and several million programmers writing applications in Java.

Google decided to aggressively pursue the smartphone market in 2005 when it acquired Android Inc. It gave its technical team a tight timetable for developing Android into a complete smartphone operating system. The team quickly decided that incorporating Java into its system was key to meeting its deadline.

Google tried to negotiate a license with Sun, but talks broke down over Sun’s insistence on maintaining control over the Java platform so that its motto of “write once, run anywhere” would continue to be true. Sun feared, correctly as it turned out, that Google might create a version of Java that would be incompatible with its own version, and result in Java-like programs that would run on Android but not elsewhere.

When negotiations cratered, Google panicked. The Android team had been working on substitutes for the Java platform, but, as a top Android engineer lamented, Google’s versions were “half-ass at best. We need another half of an ass.” A Google engineer was tasked to investigate what options besides Java were available. He summarized Google’s predicament as follows:

What we’ve actually been asked to do (by [Google’s co-founders]) is to investigate what technical alternatives exist to Java for Android and Chrome. We’ve been over a bunch of these, and think they all suck. We conclude that we need to negotiate a license for Java under the terms we need.

Android’s chief gave Google’s founders two options: “1) Abandon our work or 2) Do Java anyway and defend our decision, perhaps making enemies along the way.”

Google chose option 2. Google copied verbatim the declaring code of 37 Java API packages, 11,500 lines of Oracle’s copyrighted code, and the elaborately organized taxonomy known as the “structure, sequence, and organization” (“SSO”) of the Java API packages.

The Litigation. Sun originally expressed enthusiasm for the release of Android and its reliance on the Java platform, but attitudes changed soon after Oracle acquired Sun. It sued Google in 2010 for patent and copyright infringement. The case went to trial, where the jury found that Google did not infringe the Oracle patent in question. The jury found, however, that Google had infringed Oracle’s copyright, but was unable to agree on whether it was protected as fair use.

The district court found the APIs were not copyrightable and that Google was entitled to judgment as a matter of law. On appeal, the Federal Circuit ruled that APIs and the SSO in which they are organized are eligible for copyright protection, but that there was insufficient fact-finding below to determine whether Google’s use of them was fair use. It remanded for a new trial.

At the conclusion of the retrial, the jury determined that Google’s use of the Java APIs constituted fair use. On appeal, the Federal Circuit panel ruled in March 2018 that no reasonable jury could reach that conclusion and that Google’s use was infringing. It has remanded for a trial on damages, which may reach several billion dollars. Google has indicated its intention to seek an en banc review, which would involve a reconsideration by a larger panel of appellate judges. Given the importance of the case, such a review seems probable.

The Fair Use Analysis. Fair use is a judge-created doctrine that, at bottom, is intended to further the purposes of copyright law as expressed in the United States Constitution: “To promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries.” Courts have held that copying may advance progress in circumstances such as analysis for academic or reverse engineering purposes.

The Copyright Act includes a statutory summary of the fair use doctrine that directs courts to consider these factors:

1. whether such use is of a commercial nature or is for nonprofit educational purposes;
2. the nature of the copyrighted work;
3. the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and
4. the effect of the use upon the potential market for or value of the copyrighted work.

For purposes of this case, the fourth element on this list was likely to be the most important and the first element the least. Nonetheless, the parties engaged in forceful debate over every point.

Before analyzing these factors, the Federal Circuit first addressed the degree to which it was bound by the findings of the jury below. It described the question of fair use as one involving a mixed question of fact (usually the province of the jury) and law (for the judge to decide). Appellate courts are bound to accept a jury’s findings of fact unless they lack any reasonable basis. Thus, on appeal, the playing field was tilted heavily in Google’s favor because of the jury ruling.

Google had pointed out in its brief that no appellate court had ever reversed a jury’s finding of fair use. Nonetheless, the Federal Circuit felt bound only by the jury’s findings of “historical facts”—what happened and when—but not by its conclusion of fair use. It viewed the jury’s conclusion as an inference based upon those facts, in effect, as advisory only.

Commercial Use. Google argued that its use of Java was non-commercial because Android is an open source operating system that Google gives away for free. Oracle pointed out that Google’s business model is to generate ad revenue from its free services, and that Google had reaped billions of dollars of profit from Android.

Prior courts had also considered, under this prong of the analysis, whether the use of the work was “transformative.” For example, a song that parodied another musician’s song has been held to be transformative. Google argued that by moving Java from desktop computers to smartphones, it had transformed Java.

Oracle responded as follows:

When a plagiarist takes the most recognizable portions of a novel and adapts them into a film, the plagiarist commits the classic unfair use: a commercial use that adversely affects the owner’s adaptation rights.” . . . Google’s copying in this case is the software equivalent of this classic unfair use. . . . Google concedes it put that code to the same use in the competing Android platform, for entirely commercial purposes.

The Federal Circuit was persuaded. It said that no reasonable jury could have concluded that Google’s use of the Java APIs was either non-commercial or transformative.

The Nature of the Copyrighted Work. In the first trial, the judge had ruled that the APIs at issue were, by their nature, too functional and insufficiently expressive to warrant copyright protection. Having lost that argument in the first appeal, Google was able to make a similar argument under this prong of the fair use argument, saying that because the APIs were highly functional, they warranted only a weak level of protection.

The Federal Circuit did not go so far as to say that copyright protection for APIs should be weak. In fact, it said that “it is clear that the 37 API packages at issue involved some level of creativity.” However, it concluded that a jury could have reasonably found that the APIs were sufficiently functional to support a finding of fair use under this prong of the copyright analysis. The court also pointed out that this factor is generally the least important of the four statutory factors in determining whether the use was fair.

The Amount and Substantiality of the Portion Used. After the jury returned a verdict of fair use, Oracle asked the trial judge to overturn the verdict. In the absence of a detailed jury finding of fact, the judge assessed the verdict by considering what the jury might have reasonably concluded. On the question of the substantiality of the copying, the judge concluded that the “jury could reasonably have found that Google duplicated the bare minimum of the 37 API packages, just enough to preserve inter-system consistency in usage, namely the declarations and their SSO only, and did not copy any of the implementing code.” Under that analysis, the jury could have concluded that Google “copied only so much as was reasonably necessary.”

The Court of Appeals noted, however, that the parties had stipulated that the copying of only 170 lines of code were necessary to permit programmers to write in the Java language, but that Google had copied 11,000 lines of code.

The trial judge also justified the jury’s finding by saying Google was seeking to preserve compatibility with Java. In order to avoid confusion among Java programmers, Google made the syntax of Android similar to that of Java. But in fact Google did not made Android fully compatible with Java, and it did not press this argument on appeal. Instead, it said that it wanted to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue.

To many of the parties filing amicus briefs, this was the key issue: Who owned the familiarity with Java that millions of programmers had developed? Was it an asset of Oracle’s that Google was trying to misappropriate, or was it an asset of the individual programmers that Oracle was trying to misappropriate? In the eyes of many, Oracle was the bad actor.

The Federal Circuit sided with Oracle on this point, saying that there is no inherent right to copy in order to capitalize on the popularity of the copyrighted work or to meet the expectations of intended customers. It cited a case involving the illustrations of Dr. Seuss to conclude that taking those aspects of the copyrighted material that were familiar to software developers to create a similar work designed to be popular with those same developers is not fair use.

Effect Upon the Potential Market. Google said that Sun/Oracle had failed in its effort to develop a version of Java that would be suitable for a mobile computing environment, and that Android had no effect on the market for desktop Java. This argument was forcefully undercut, however, by Oracle’s experience with the Amazon Kindle, which jettisoned Java for Android and then went back to Java after demanding – and receiving – a license fee discount of 97.5%.

The court discounted Google’s allegation that Oracle had failed in the smartphone market by pointing out that some smartphone makers had licensed Java before the release of Android. It also pointed out that the right to create derivative works is a right reserved to the copyright holder. Oracle had introduced evidence that it had not given up on creating a version of Java that was more suitable to smartphones. Thus, the court concluded, Google had no right to copy Java code to enter the smartphone market.

Summary. The Federal Circuit panel summed up the prior analysis by saying that two of the four fair use factors weighed heavily against a finding of fair use, one weighed in favor, and one factor was at best neutral. In balancing these findings, the court concluded:

Although Google could have furthered copyright’s goals of promoting creative expression and innovation by developing its own APIs, or by licensing Oracle’s APIs for use in developing a new platform, it chose to copy Oracle’s creative efforts instead. There is nothing fair about taking a copyrighted work verbatim and using it for the same purpose and function as the original in a competing platform.

Lost in the Shuffle – The expressive nature of APIs and their Organization.

The Federal Circuit gave insufficient consideration to the second factor – the nature of the copyrighted work. It is that facet of the case that has stirred strong emotions in the software community because, according to the brief filed on behalf of 76 computer scientists, a ruling that the use of the APIs is not fair “would stifle innovation and disrupt well-settled industry practices.”

The list of computer scientists signing on to this brief is a who’s who of computer science, including professors from MIT, Stanford, Berkeley, Carnegie Mellon and Princeton; lead developers of Java who are no longer at Sun (and some of whom now work for Google); alumni of Bell Labs (including Gordon Bell) and Linus Torvalds, the principal developer of the Linux kernel.

Nonetheless, the most compelling technical brief was filed on behalf of only four computer scientists: Eugene Spafford, a Purdue professor; Zhi Ding, a professor at the University of California, Davis; Adam Porter a professor at the University of Maryland; and Kenneth Castleman, a former senior scientist at the NASA Jet Propulsion Laboratory.

In seeking to explain the creative expression that may underly APIs, they compared an API to a blueprint. “The blueprint may express the design of a structure, and may specify the building materials, clearances and dimensions, placement of utilities, and methods of ingress and egress. . . There are countless designs that are possible because architects may make many subjective choices to address varying goals. The blueprint is therefore the creative expression of a unique design that is the product of the architect’s many choices.”

They offered up, as a simple example of such choices, the design of APIs that might call upon programs designed to draw geometric figures. They imagined functions called “DrawCircle”, “DrawEllipse” and “DrawSquare”. As an example of a simple choice made by the programmer, the “DrawCircle” command could use, as inputs, the center and radius of the circle, while the DrawEllipse could use as inputs the center and the lengths of the major and minor axes.

However, a programmer could choose to eliminate the circle command, and treat it as merely a special form of ellipse, one in which the major and minor axes are identical. As a more challenging alternative to DrawSquare, the programmer might choose instead “DrawPolygram”, which might allow for a wide variety of shapes but also require a more demanding set of input parameters.

They pointed out that, for a complex API that may involve hundreds or thousands of methods and classes, these expressive choices are multiplied hundreds or thousands of times over, resulting in an almost countless number of ways an API design can be expressed.

Oracle’s brief highlighted the complexity of the artistic choices made by the designers of the Java APIs. To understand the explanation, you need to know that Oracle used a hierarchical set of terms in which a “class” of APIs consists of several “packages” each of which in turn consists of several “methods” – the individual programs that perform functions, and the APIs that link to them. The APIs in some cases refer to one another, creating links in the system.

Oracle presented two diagrams, the first showing the 166 Java API packages in blue and some interfaces between them in green. The individual methods were not shown because the detail would have been overwhelming. Grey lines show the links between the packages and interfaces.

The second diagram shows the same packages, interfaces and links, but also shows the links that Google copied in red.

According to Oracle, none of this organization was mandated by any function.

Many of the amicus briefs, and the Google brief as well, emphasize the functional nature of the APIs, seeking to diminish them as a basis for expressive content. But the truth is that all software is functional; that’s the whole point of software.

Yet Congress has chosen to assign it to the realm of copyright, which by its nature protects expression. It has never been a perfect fit, but the courts have made the best of it. In this case, it is hard to imagine that the structure of Java, much of which Google copied verbatim, was anything but highly creative. Thus, the Federal Circuit should have found strongly in favor of Oracle on the second prong of the fair use analysis, notwithstanding the functional nature of APIs.

The software community is in shock that the copying of these APIs and their governing structure, sequence and organization (SSO) can be infringing activity because, in the eyes of the software community, the APIs are part of the public common, free for all to use.

While APIs may be copied in limited circumstances – for example to study them in order to create a functionally equivalent, non-infringing clone — it is not correct to think that a huge ecosystem created by a commercial enterprise can or should be free for the taking without its consent. Such a conclusion would discourage companies from investing in the creation of new systems.

The policy of the US Constitution – to “promote the progress of science and useful arts” is best served by affording complex APIs copyright protection. Three judges of the Federal Circuit have come to this conclusion, if not as forcefully as they should have. Now in all likelihood their ruling will be tested by an en banc re-hearing. Should it come to that, the judges would do well to focus on the originality of the Java SSO and the brazenness with which Google copied it.