It’s the End of Google v. Oracle (And I Think I Feel Fine)

In a long-awaited decision, the Supreme Court finds that Google’s copying of Oracle’s Java API was fair use. Should creators of more traditional content be concerned?

After eleven long years of legal wrangling, Google v. Oracle has finally been put to bed by the Supreme Court. (Although let’s be honest—at that age, it really was old enough to put itself to bed.) To the uninitiated, the case concerned Google’s alleged infringement of certain portions of computer code from Oracle’s Sun Java application programming interface (API). In particular, Google copied the declarations (so-called “declaring code”) responsible for providing the name and location of each task within the API’s overall organization system. (Think of it as using a book title to refer to a particular book, which will then enable you to identify and locate the book.)

In a 6-2 ruling authored by Justice Breyer (read here), the majority sidestepped the issue of whether the API’s declaring code was subject to copyright protection in the first place. Google’s primary argument was that this code represented the type of process, system or method of operation that isn’t covered by copyright, as opposed to code that actually carries out a particular task (so-called “implementing code,” which Google didn’t copy).

The Court decided only the second issue presented by Google: whether, assuming the Sun Java API was copyrightable, Google’s use of the API nevertheless constituted “fair use” under the Copyright Act as a matter of law.

The Court’s stated rationale for avoiding the first issue was that it “should not answer more than is necessary to resolve the parties’ dispute.” That assertion is a bit odd, given that copyrightability would have been a more narrow basis on which to decide the case (and would have created easier to follow precedent for future cases). I assume this means the Court couldn’t get a majority of justices to decide that APIs weren’t copyrightable, and that at least two of the justices who agreed with the majority’s fair use outcome also agreed with Justices Thomas and Alito in dissent (who would have found the APIs copyrightable).

Nevertheless, all six justices in the majority signed onto a fair use opinion that’s almost entirely grounded in the premise that the API is not copyrightable (or is only barely so)—contrary to the explicit assumption Justice Breyer claimed to be making.

The Fair Use Analysis

The Court begins its trip through the four fair use factors by noting that copyright protection is narrower, and the applicability of fair use is greater, when copyrightable material is bound up with uncopyrightable material (so-called “thin” copyright protection). From this launching-off point, the Court begins its fair use analysis—not with the traditional first statutory factor (the “purpose and character of the use”), but with the second (the “nature of the copyrighted work”).

The Nature of the Copyrighted Work

Starting with an explanation of the differences between the “implementing code” and “declaring code” discussed above, the Court drew a distinction between those aspects of computer programs that are at the core of copyright protection and those that exist primarily to define, divide and locate the implementing code—primarily organizational aspects that exist more for the ease and benefit of the programmer than to carry out any particular function. According to the majority, because the declaring code fell into this latter category, the “nature of the copyrighted work” pointed in the direction of fair use.

So, notwithstanding the Court’s announced assumption that the API’s were copyrightable for purposes of the fair use analysis, its resolution of this factor seemed to depend entirely on precisely the opposite assumption.

In dissent, Justice Thomas argued that the declaring code met the “extremely low” threshold for originality under the Copyright Act, and therefore the nature of the work did not favor a finding of fair use. That said, the analogy he chose to explain his assertion, that declaring code is “like the defined term in a statute,” while implementing code is “like the detailed definition” seems if anything to cut against his argument that the declaring code is copyrightable in the first place.

The Purpose and Character of the Use

Turning next to the traditional first statutory fair use factor (“purpose and character of the use”), the majority acknowledged that Google copied portions of the Java API precisely, and that it did so in part for the same reason that the code was originally created by Sun, namely to enable programmers to call up implementing programs that would accomplish particular tasks.

While the Court’s statement that Google’s use of the Sun Java API was transformative because it allowed Google to “create new products” may cause excitement and/or consternation among folks on opposite sides of the fair use aisle, I don’t read the Court to be suggesting that the creation of new products is in and of itself transformative. It seems more likely that the Court is simply noting that to the extent Google created a new platform which could then be used by programmers to create new products, “its use was consistent with that creative ‘progress’ that is the basic constitutional objective of copyright itself.” This is true, the Court reasoned, regardless of whether Google’s copying was for commercial reasons.

The Amount and Substantiality of the Portion Used

On the third factor (“amount and substantiality of the portion used”), the Court noted that depending on how the “whole” of the work is defined, Google could either be deemed to have copied a large amount (11,500 lines of declaring code) or a small amount (0.4 percent of the total Sun Java API code, including implementing code). Either way, the Court found that Google’s copying didn’t go further than necessary to achieve a transformative use.

As to these portions, the Court held, “Google copied those lines not because of their creativity, their beauty, or even (in a sense) because of their purpose. It copied them 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.”

Effect on the Market

It was in its discussion of the fourth statutory fair use factor (the effect of the copying in the “market for or value of the copyrighted work”) that the Court used the type of language that would be most likely to strike fear in the hearts of the non-tech creative industry leaders responsible for worrying about such things. (The Motion Picture Association, sans Netflix, filed an amicus brief in support of Oracle in the case.)

Here, the Court engaged in a balancing, not only of the potential harm to the copyright owner as a result of the unauthorized copying, but to the potential benefit to the public that copying would likely produce. Cue hand-wringing, as content owners have to wonder whether future courts will use this statement to find fair use even when the copyright owner has shown market harm.

Potentially even more problematic, if untethered from the moorings of this particular case, is the Court’s comment that the “costs and difficulties of producing alternative APIs with similar appeal to programmers” weighed in favor of fair use. And while this assertion too may be a subject of concern for copyright owners, I think the Court’s statement is really more properly viewed in the context of copyrightability.

Google’s use of the particular copied material was not about its content, but its function—a function the Court already indicated was subject to only a thin copyright to the extent it was protectable at all. And frankly, it’s not the declaring code that would have been difficult to produce—certainly not for a company with the resources of Google, which wrote millions of lines of its own implementing code in contrast to the 11,500 lines of declaring code it copied from Oracle. Instead, the difficulty lies with the estimated 6 million programmers who were trained in Java, and the difficulty they would have if forced to learn entirely new commands in order to program for the Android system.

Perhaps I’m being naïve, but I certainly don’t read the Court as suggesting that a fair use analysis is triggered any time it’s more difficult to create than it is to copy (which, let’s face it, is always). Instead, I think we need to read the opinion taking into account the particular code at issue in the case, which exists for the purpose of providing organization and structure to programmers, as opposed to core creative content.

My Take

I read a comment yesterday on Twitter pondering whether, through its decision, the Supreme Court was en route to finding that a website like The Pirate Bay is a fair use insofar as it benefits the public by helping people discover music or movies, while serving as a less difficult alternative to buying content.

I don’t think the case goes anywhere near that far, and shouldn’t be interpreted anywhere near that broadly. Toward the beginning of its opinion, the Court noted that “computer programs differ from books, films, and many other ‘literary works’ in that such programs almost always serve functional purposes.” Then, near the end of the decision, the majority recognized that “[t]he fact that computer programs are primarily functional makes it difficult to apply traditional copyright concepts in that technological world.” The Court noted that in applying the fair use doctrine to “this different kind of copyrighted work,” it did not intend to “overturn or modify our our earlier cases involving fair use—cases, for example, that involve “knockoff ” products, journalistic writings, and parodies.”

Interestingly, on this latter point, the majority and dissent seem to agree, although, having been outvoted on fair use, Justice Thomas made his point more directly. In a footnote to his dissent, Thomas declared: “Because the majority’s reasoning would undermine copyright protection for so many products long understood to be protected, I understand the majority’s holding as a good-for-declaring-code-only precedent.”

Of course, only time will tell. While opportunistic litigants will no doubt cite some of the more sweeping language in the Court’s opinion in favor of fair use in any number of different contexts, my sense is that future courts will read it consistently with the narrow set of facts in which the case was actually presented.

Bottom line is that Google v. Oracle is over, and the sky is not falling. (At least I hope it isn’t, because I’m not insured for that sort of thing.) I think that where the case is most likely to have an impact, at least in the short term, is to introduce uncertainty as to whether so-called API “reimplementation” in other contexts is fair use or not. This confusion could have been avoided by a finding on copyrightability. Instead, lawyers and clients will have to try to read the tea leaves on fair use—which as I noted in my article on the case involving the Andy Warhol Foundation, is an area that’s often hard to predict.

The case is also likely to result in more summary judgment motions decided on fair use grounds in cases where the underlying facts aren’t materially disputed. In an ancillary portion of the Google ruling, the Court held that while a jury is entitled to decide disputed factual issues impacting fair use, the ultimate legal analysis is left to the courts.

So, how do you feel about the result in Google v. Oracle? I’d love to find out in the comments below or @copyrightlately on most social media platforms.