Ed. Note: This post is the first in a series analyzing the U.S. Supreme Court’s decision in Google v. Oracle.

James Daily is the Head of Legal Data Science at Skopos Labs and a Lecturer in Law at the Center for Empirical Research in the Law at Washington University in St. Louis. He co-authored an amicus brief in support of Google in Google v. Oracle.

***

After two trials and two trips to the Supreme Court, the 11-year saga of Oracle’s intellectual property battle against Google has essentially come to a close. The underlying case involved Oracle claiming copyright infringement against Google’s use of large parts of the Java application programming interface (API) to create the Android mobile operating system. At stake were potentially billions of dollars in damages, and although Google didn’t get everything it wanted from the Court, it was successful on the most important point. The Court held that Google’s copying of the Java API was protected by fair use. Google v. Oracle, 503 U.S. ___ (2021).

Almost as important, however, was what the 6-2 majority didn’t say. The Court did not decide the first of the two questions presented in the case: “Whether copyright protection extends to a software interface.” Thus, as in Lotus v. Borland, 516 U.S. 233 (1996), the Court has avoided making a clear decision on the limits of the copyrightability of software. Lotus was a 4-4 split decision, and it raises the possibility that there was no clear majority on the issue of the limits of copyrightable subject matter in this case either.

While several commentators suspected the Court might dodge the copyright issues, it was thought that the Court would use a relatively narrow question of civil procedure to do so, given that the Court took the unusual step of requesting additional briefing on that issue after the case was postponed to the 2020 term. Instead, the Court addressed the civil procedure issue head-on but breezed past the question of copyrightability in the opening paragraph of the opinion: “In reviewing [the Federal Circuit’s] decision, we assume, for argument’s sake, that the material was copyrightable.” Google v. Oracle at 1.

What can we make of the Court “deciding not to decide”? How broad was the Court’s application of the fair use defense? And what does this mean for the creators and re-implementers of APIs?

Background

Both the majority and dissenting opinions took pains to explain the significance of programming language APIs, but in short an API is a well-defined set of commands or functions that a computer programmer can use to interact with a programming language, application, library, or service. For example, you may be familiar with Microsoft Excel and its numerous functions. That library of functions constitutes an API. When you combine functions such as SUM, AVERAGE, or COUNT you are writing small computer programs using that API.

In this case, Google was accused of infringing Oracle’s copyright in the API of the Java programming language, essentially the Java equivalents of SUM, AVERAGE, COUNT, and so forth. In particular Oracle claimed to have a copyright in the definition of the particular set of functions in the API, their names, how many and what kinds of parameters the functions take, and how the functions were organized. These definitions are called the “declaring code.”

Google did not copy the behind-the-scenes code that actually, for example, computes the sum of a set of numbers (this is called the “implementing code”). It only copied the declaring code, and even then it did not copy all of it. Nonetheless, what Google copied amounted to approximately 11,500 lines of code. In absolute terms that may seem like a lot, but in relative terms it was only 0.4% of the Java programming language. (As you might suspect, the implementing code takes up a lot more lines than the declaring code, especially once the functions get more complicated than SUM or COUNT.)

Oracle alleged that Google’s use of the Java API allowed tens of thousands of Java programmers to easily start developing for Google’s new Android operating system, giving Google a running start in the nascent smartphone industry and stifling Oracle’s own efforts at Java-based smartphones. This led to a claim of billions of dollars in damages, which only grew as the case wore on. With such high damages at stake and no significant counterclaim to induce settlement, Oracle pursued the case aggressively.

In the run up to the Supreme Court case, the Federal Circuit held that the declaring code was copyrightable, but a jury then found that Google’s copying was protected by fair use. The Federal Circuit reversed the jury verdict of fair use. Google then appealed both issues: was the declaring code copyrightable, and if so, was there fair use?

Copyrightability

It might seem that in order to decide whether there was fair use, the Court would first have to decide whether there was a copyright. After all, fair use is a defense to copyright infringement, and if there is no copyright then there can be no infringement and thus the question of fair use is irrelevant. As mentioned above, the Court flipped this around, holding that, even if the declaring code was copyrightable, fair use applied, and thus there was no infringement either way.

It is not uncommon for courts to reason this way, but of course it only works if there is fair use. A lower court in a future case might be presented with similar questions but decide that there was not fair use in that case. The lower court would have to decide the threshold question of copyrightability without any guidance from the Supreme Court.

It is somewhat frustrating that the Court was unable to decide this question in an almost ideal case: two highly invested litigants with excellent representation, dozens of amicus briefs on either side, and several additional months in which to consider the question. The dissent, by contrast, gives a thorough treatment of the question of copyrightability, coming down conclusively on the side of “yes, copyright but no fair use”. Since the majority ultimately found fair use, it would not have changed the outcome to have first decided in favor of copyrightability. This further suggests to me that there may not have been a 5-vote majority in favor of both copyrightability and fair use. The majority’s curious reasoning for avoiding the question does not do much to suggest otherwise:

Given the rapidly changing technological, economic, and business-related circumstances, we believe we should not answer more than is necessary to resolve the parties’ dispute. We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copyrighted.

Google at 15. As the dissent points out, “rapidly changing technological, economic, and business-related circumstances” “[have] been a constant where computers are concerned.” It is almost inevitable that an API infringement case will occur again, and the district court will not be able to claim that “rapidly changing technological, economic, and business-related circumstances” prevent it from deciding the issue, at least if it first decides that the fair use defense does not apply.

Fair Use

But how likely is that situation? Does the Court’s application of fair use here leave much room for a case in which an API is copyrightable but a re-implementation of that API is not fair use?

At the outset, the Court’s fair-use analysis is mingled with the question of the scope of copyrightability of computer software, including a discussion of the legislative history of the addition of software to copyrightable subject matter. The majority then gives this explanation of its goal in applying fair use in this case:

The upshot, in our view, is that fair use can play an important role in determining the lawful scope of a computer program copyright, such as the copyright at issue here. It can help to distinguish among technologies. It can distinguish between expressive and functional features of computer code where those features are mixed. It can focus on the legitimate need to provide incentives to produce copyrighted material while examining the extent to which yet further protection creates unrelated or illegitimate harms in other markets or to the development of other products. In a word, it can carry out its basic purpose of providing a context-based check that can help to keep a copyright monopoly within its lawful bounds.

Google at 16-17. The Court’s approach seems clear here: when in doubt, assume the copyrightability of software and let the fair use defense do the heavy lifting of avoiding excessive monopolization.

The Court’s application of fair use follows the four factor analysis prescribed by the copyright statute, considering (1) the nature of the copyrighted work; (2) the purpose and character of the use; (3) the amount and substantiality of the copyrighted work used; and (4) the effect on the market or value of the copyrighted work. Although the Court notes that the four factors are not necessarily equally weighted in all contexts, in this case it found that all four factors favored a finding of fair use, representing a substantial victory for Google and other API re-implementers.

With regard to “the nature of the copyrighted work,” the Court found that the Java declaring code is further from the core of copyright than other kinds of creative works, favoring fair use. In particular the Court noted that declaring code is substantially functional and that it is a kind of user interface (where the user is a computer programmer). As the Court explained, much of an API’s value derives from its ability to channel programmers toward using the underlying implementing code. Since Google independently created its own implementing code, Google’s copying of the Java API did not prevent programmers from continuing to use the Java implementing code, nor did Google rely on the Java implementing code to make the API attractive to programmers. In short: an API, even an extensive or well-designed one, is not very valuable in a vacuum.

Second, the Court similarly found that “the purpose and character” of Google’s use of the Java API was transformative because Google took an API intended for use on desktop and laptop computers and added and removed elements in order to make it useful on mobile phones. The Court held that “reimplementing an interface can further the development of computer programs”, “consistent with that creative progress that is the basic constitutional objective of copyright itself.” Id. at 26 and 25.

Although Google’s use was indisputably commercial, the Court held that commerciality is not dispositive, “particularly in light of the inherently transformative role that the reimplementation played in the new Android system.” Id. at 27. The Court gave little consideration to claims of bad faith, noting that the Court’s previously-expressed “skepticism about whether bad faith has any role in a fair use analysis” is “justifiable” and that, in light of the strength of the first two factors and the jury’s finding in favor of Google, the question of bad faith would not be determinative in this case. Id. at 28.

For the third factor the Court considered “the amount and substantiality of the portion used.” Here the Court had to choose between focusing on the large absolute amount of code copied (approximately 11,500 lines) or the small amount in relative terms (0.4% of the entire API, including the implementing code). Perhaps unsurprisingly given the ultimate outcome, the Court focused on the relative amount copied.

The Court’s analysis here is subtle. “[E]ven a small amount of copying may fall outside of the scope of fair use where the excerpt copied consists of the heart of the original work’s creative expression.” Id. at 28. And here, Google copied the API precisely “because programmers had already learned to work with the Sun Java API’s system, and it would have been difficult, perhaps prohibitively so, to attract programmers to build its Android smartphone system without them.” Id. at 29.

At first glance it might seem like Google had therefore copied the heart of the original work, if indeed it had copied such a vitally important part of the API, without which Android could not have succeeded. The key question, however, whether Google copied “the heart of the original work’s creative expression” (emphasis added). The Court excuses Google’s copying because of its intent, finding that Google did not copy those lines “because of their creativity [or] their beauty.” Id. This focus on intent is difficult to square with the Court’s previous disregard for the question of bad faith, but the practical upshot seems to be that copying an API for brute commercial reasons is excusable in a way that copying it for its creativity would not be.

For the fourth factor the Court considered the effect on the “market for or value of the copyrighted work.” Here the Court’s analysis was more evidence-focused, listing reasons why the jury might have found Google’s evidence on this question more persuasive than Oracle’s. A key part of the Court’s analysis is that Google’s “desire to use the Sun Java API” stemmed not from Java’s originality but because it was already successful and widely adopted (again there is a focus on intent). Id. at 34. The Court attributes the value of that success not to the copyright owner but rather to the effort of the third-party programmers. “We have no reason to believe that the Copyright Act seeks to protect third parties’ investment in learning how to operate a created work.” Id.

This suggests that this fourth factor might have cut in the other direction had Google copied Java some years earlier, when Java’s success was still unknown. But since Google copied Java only after (and indeed because) Java had become widely adopted and successful, the multi-billion-dollar success of Google’s decision to copy the Java API is attributed not to the creative value of the API but rather to the effort of programmers to learn Java, to which Oracle has no right. Whether the programmers might have learned Java in the first place in part because of the API seems to be outside the scope of the Court’s analysis.

Finally, the Court held that allowing Oracle to enforce a copyright on the API would harm the public, “limiting the future creativity of new programs” given that “the reimplementation of a user interface allows creative new computer code to more easily enter the market.” Id. at 34 and 35. The substantially functional nature of declaring code made the Court reluctant to allow copyright to prohibit downstream uses that are substantially creative.

What Now?

Given the strong fair use holding in favor of Google, what can API creators do to protect against re-implementation, should they wish to do so? And what can re-implementers do in order to establish clear fair use?

For API creators, there are two major problems. First, the copyrightability of APIs remains in doubt. Making the API as creative as possible may help. Part of the problem with the Java API was that so much of it was unoriginal. For example, a max() function is simple, already existed in numerous languages, and is very close to unprotectable mathematics. By contrast, an API that addresses a novel problem or is organized in a novel, creative way may be more clearly protectable.

Second, API creators can make some of the fair-use factors less available to re-implementers:

• As mentioned, a creative API design may be more protectable where the “nature of the copyrighted work” is closer to the core of copyright.
• Avoiding open source and fencing-in the API through proprietary licensing may help avoid Oracle’s problem that it had “originally emphasized the importance of using the API to attract programmers” by “mak[ing] the API open and then compet[ing] on implementations.” Google at 23.
• Designing the API such that the declaring code makes up a larger portion of the entirety of the codebase may help tilt the analysis away from a finding that the copied portion was a small part of the work as a whole. One way to do this may be to avoid large functions that hide a large amount of implementing code behind a single line of declaring code.
• Designing the API in a way that shifts creative decisions from the implementation to the specification. One way to do this could be to specify the algorithm by which a given function must be implemented. For example, rather than a generic sort() function, the API could specify that it must use a particular sorting algorithm. The Java API often doesn’t do this. For example, rather than specifying a sorting algorithm, the library states that “implementors should feel free to substitute other algorithms.”
• Going in the other direction, an API could avoid transformational use by being broad and flexible, such that re-implementations could not offer substantially different functionality. That may be a tall order, however.

Re-implementers have an easier task, given Google’s success here. However, there are still some lessons. Copying an openly available API may be more likely to be fair use than copying a proprietary one. It is important to avoid copying implementing code. Copying a well-established, widely-adopted API may be more defensible than copying a new API. Documenting intent may be important: the copying should ideally be done for reasons of interoperability, to address a new market, or to make use of existing users’ familiarity with the API.