Supreme Court Decides Landmark Copyright Fair Use Case – Google v. Oracle

By Shane Wax

On April 5, 2021, the United States Supreme Court released its decision in a landmark copyright case, Google LLC v. Oracle America, LLC, siding with Google and providing new guidance on “fair use” for the first time in over 25 years.[1]  It has been nearly as long since the High Court took on a software-related copyright case.[2]  This decision is the culmination of a lawsuit that was commenced over a decade ago, dismissed by a judge in 2012, reversed on appeal in 2014, decided in favor of Google by a jury in 2016, and reversed again on appeal in 2018, thus earning the label “Lawsuit of the Decade” even before oral arguments were held at the Supreme Court last fall.[3]

The dispute concerns a common practice among computer programmers – using pre-existing JAVA-language computer code, originally authored by JAVA’s developers, that served as a set of programming tools known as “Application Programming Interface packages” or “API” as a short-cut for developing completely new computer programs.  The developers of JAVA made all these API packages “available for free and open source,” but subject to their licensing terms -namely a “general public license” that required licensees to give back their original code to public domain, or a commercial license for creators who wished to treat their code as a secret.[4]

When Google began developing its Android platform (and phones), it attempted, but failed, to obtain a commercial license for Oracle’s API packages. When license negotiations broke down, Google built up the Android platform from scratch, albeit not entirely.  It took about 100 Google engineers more than three years to author millions of lines of new and original code, including over 160 original API packages; however, since “Google wanted millions of programmers, familiar with Java, to be able easily to work with its new Android platform, it also copied roughly 11,500 lines of [pre-existing] code.”[5]  Oracle also claimed that some of Google’s original API packages copied the “structure, sequence, and organization” of Oracle’s API packages.

Google countered with two primary arguments: first, that it had not copied any protectable subject matter inasmuch as the concededly copied computer code was functional or a method of operation; or alternatively, that its copying was transformative and constituted fair use.  While the district court judge agreed with Google on the copyrightability question and a jury agreed with Google on the question of fair use, the Federal Circuit Court of Appeals disagreed and reversed each time.[6]

In November 2019, the Supreme Court agreed to review both issues and initially scheduled argument for March 16, 2020, but arguments were postponed until October 7 in light of the pandemic.  Ultimately, the Supreme Court sided with Google in a 6-2 decision with a majority opinion authored by Justice Breyer and a dissent written by Justice Thomas and joined by Justice Alito.

Justice Breyer’s majority opinion neatly explains the technical jargon and foreshadows the Court’s conclusion that Google’s use was fair.  For example, below is an excerpt of Justice Breyer’s discussion of API and relevant technical terms put into layman’s context ahead of his fair use analysis:[7]

Consider in more detail just what an API does. . . . An API divides and organizes the world of computing tasks in a particular way. Programmers can then use the API to select the particular task that they need for their programs. . . .

For each task, there is computer code, known as “implementing code,” that in effect tells the computer how to execute the particular task you have asked it to perform (such as telling you, of two numbers, which is the higher). The implementing code (which Google independently wrote) is not at issue here. For a single task, the implementing code may be hundreds of lines long. It would be difficult, perhaps impossible, for a programmer to create complex software programs without drawing on prewritten task-implementing programs to execute discrete tasks.

But how do you as the programmer tell the computer which of the implementing code programs it should choose, i.e., which task it should carry out? You do so by entering into your own program a command that corresponds to the specific task and calls it up. Those commands, known as “method calls,” help you carry out the task by choosing those programs written in implementing code that will do the trick . . . different method calls will tell the computer which of those tasks to choose. Those familiar with the Java language already know countless method calls that allow them to invoke countless tasks.

And how does the method call (which a programmer types) actually locate and invoke the particular implementing code that it needs to instruct the computer how to carry out a particular task? It does so through another type of code, which the parties have labeled “declaring code.” Declaring code is part of the API. For each task, the specific command entered by the programmer matches up with specific declaring code inside the API. That declaring code provides both the name for each task and the location of each task within the API’s overall organizational system. . . . [T]he declaring code and the method call form a link, allowing the programmer to draw upon the thousands of prewritten tasks, written in implementing code. Without that declaring code, the method calls entered by the programmer would not call up the implementing code.

The declaring code therefore performs at least two important functions . . . [First] the declaring code enables a set of shortcuts for programmers. By connecting complex implementing code with method calls, it allows a programmer to pick out from the API’s task library a particular task without having to learn anything more than a simple command. . . . [Second,] the declaring code performs an organizational function.

Practitioners might be puzzled to read Justice Breyer’s discussion of “functionality” in view of the fact that the majority opinion skips to a fair use analysis under the “assumption” that the API constituted copyrightable subject matter, despite the general rule that functionality precludes copyrightability and the fact that Court had granted certiorari with respect to that question.[8]

Justice Thomas’ dissent does not veer away from answering the question, and in his view, copied “declaring code,” is copyrightable.  His conclusion is principally based on his deference to Congress, which has sole authority to legislate both patent and copyright laws, and, consequently, could have chosen to grant either patent or copyright protection to software, and chose copyright.  However, the above passage from Justice Breyer’s opinion portends the majority’s agreement that Google’s use was fair.

To the question of fair use analysis, both the majority and dissent proceed through a fairly straight-forward analysis of the factors enumerated in Section 107 of the Copyright Act: (1) the purpose and character of the use, including 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.  As is often the case, reasonable minds can and do often reach different conclusions when applying these fair use factors, as evidenced by the disagreements between Justices Breyer and Thomas and between the Federal Circuit and the District Court.

First addressing the “nature of the copyrighted work,” the majority concludes that “declaring code is, if copyrightable at all, further than are most computer programs (such as the implementing code) from the core of copyright,” reasoning that declaring code is different from run-of-the-mill computer programs:[9]

Like other computer programs, [declaring code] is functional in nature. But unlike many other programs, its use is inherently bound together with uncopyrightable ideas (general task division and organization) and new creative expression (Android’s implementing code). Unlike many other programs, its value in significant part derives from the value that those who do not hold copyrights, namely, computer programmers, invest of their own time and effort to learn the API’s system. And unlike many other programs, its value lies in its efforts to encourage programmers to learn and to use that system so that they will use (and continue to use) [it].

In other words, while all computer programs are, by their nature, outwardly functional, the true functionality of declaring code, as part of a user interface, isn’t merely in its end-use as a computer program, but in serving as an essential building block for new language.  Thus, in the majority’s view, this factor weighs in favor of a finding of fair use.

In dissent, Justice Thomas acknowledges that the declaring code “is inextricably bound together with a general system, the division of computing tasks, that no one claims is a proper subject of copyright,” but responds that most copyrighted works (e.g., books) interweave copyrightable expression with uncopyrightable ideas, and that efforts by consumers to learn and exploit copyrightable works for themselves (e.g., a Broadway cast and crew learning and performing a script) is not a proper basis for weighing the “nature of the work.”[10]

Next, the majority opinion turns to the “purpose and character of the use,” to inquire whether Google’s use was “transformative.”  Justice Breyer begins by responding to the position adopted by the dissent and the Court of Appeals: “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” – cautioning that “to stop here would severely limit the scope of fair use in the functional context of computer programs” and would constrain rather than promote “creative progress.”[11]

Here Google’s use of the Sun Java API seeks to create new products. It seeks to expand the use and usefulness of Android-based smartphones. Its new product offers programmers a highly creative and innovative tool for a smartphone environment. To the extent that Google used parts of the Sun Java API to create a new platform that could be readily used by programmers, its use was consistent with that creative “progress” that is the basic constitutional objective of copyright itself. . . .

[Google] copied the API (which Sun created for use in desktop and laptop computers) only insofar as needed to include tasks that would be useful in smartphone programs [a]nd it did so only insofar as needed to allow programmers to call upon those tasks without discarding a portion of a familiar programming language and learning a new one. . . . Some of the amici refer to what Google did as “reimplementation,” defined as the “building of a system that repurposes the same words and syntaxes” of an existing system—in this case so that programmers who had learned an existing system could put their basic skills to use in a new one.

The record here demonstrates the numerous ways in which reimplementing an interface can further the development of computer programs . . . interfaces are necessary for different programs to speak to each other . . . reimplementation of interfaces is necessary if programmers are to be able to use their acquired skills . . . the reuse of APIs is common in the industry .. . . Sun itself had used pre-existing interfaces in creating Java . . . [and] Sun executives thought that widespread use of the Java programming language, including use on a smartphone platform, would benefit the company.

Thus, the majority concludes that Google’s “reimplementation” of digital building blocks to create an entirely new commercial product was sufficiently transformative to overcome the commercially profiting nature of the new product.

Next, the majority addresses the “amount and substantiality of the portion used” factor.  While Google concededly copied a large quantity of declaring code in a vacuum, the court points out that the “total set of Sun Java API computer code, including implementing code, amounted to 2.86 million lines, of which the copied 11,500 lines were only 0.4 percent.”  Of added consequence was that “Google copied those lines not because of their creativity, their beauty, or even (in a sense) because of their purpose,” but 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,” suggesting that Google took no more than necessary.  The dissent responds that that “because the declaring code is what attracted programmers to the Java platform and why Google was so interested in that code,” by copying these lines, Google “copied the heart or focal points” of Oracle’s code.[12]

Lastly, but not least, the majority addresses market effects, which Justice Thomas labels as “undoubtedly the single most important element of fair use.”  In the dissent’s view, Google’s release of the Android system negatively impacted Oracle’s ability to license its API to other smartphone developers, such as Samsung, and significantly devalued any potential license. However, the majority dismisses this concern by noting that Oracle was primarily in the market of laptop and desktop computers, that its past efforts to enter the mobile phone market were unsuccessful and that its CEO testified that its market failures were not attributable to the success of Android.  According to Justice Thomas, however, this line of reasoning begs the question that past market failures or conditions preclude future market attempts or success.[13]

It is on this final point that the dissent perhaps strikes its strongest chord.  Thus, while some outlets like EFF and National Review are praising this decision as a “victory for fair use,” other commentators are criticizing the potential ripple effects of the decision.[14]

 

[1]Google LLC v. Oracle Am. Inc., No. 18-956, (U.S. Apr. 5, 2021), Slip Opinion available at https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf.  The last time the Supreme Court took up “fair use” under the Copyright Act was when it addressed parody songs in Campbell v. Acuff-Rose Music, Inc., 510 U.S. 569 (1994).

 

[2] Lotus Dev. Corp. v. Borland Int’l, Inc., 516 U.S. 233 (1996) (per curium, affirming by split decision [4-4] the appellate court’s holding that copyright in software does not extend to a method of operation).

[3] See Ward, Aaron, Google v. Oracle: Silicon Valley Braces for “Lawsuit of the Decade” as Google Petitions for Cert to decide API Copyrightability, Harvard Jolt Digest (Mar. 13, 2019), https://jolt.law.harvard.edu/digest/google-v-oracle-silicon-valley-braces-for-lawsuit-of-the-decade-as-google-petitions-for-cert-to-decide-api-copyrightability; Donahue, Bill, The Google-Oracle Copyright War, Explained, Law360 (Oct. 6, 2020), https://www.law360.com/articles/1317193/the-google-oracle-copyright-war-explained; Rigg, Robert S. and Sudip K. Mitra, Google v. Oracle and the Future of Software Development, 10 Nat’l L. Rev 283 (Oct. 9, 2020) https://www.natlawreview.com/article/google-v-oracle-and-future-software-development

[4] Oracle Am., Inc. v. Google LLC, 886 F.3d 1179, 1208-09 (Fed. Cir. 2018).

 

[5] Supra n.1, Slip Opinion p.3.

 

[6] Oracle Am., Inc. v. Google Inc., 872 F. Supp. 2d 974 (N.D. Cal. 2012) (“Oracle I”), rev’d, 750 F.3d 1339, 1348 (Fed. Cir. 2014) (“Oracle II”), cert. denied, 135 S.Ct. 2887 (2015), on remand, Oracle Am., Inc. v. Google Inc., No. 3:10-cv-3561 (N.D. Cal. June 8, 2016) (“Oracle III”), rev’d, 886 F.3d 1179 (Fed. Cir. 2018) (“Oracle IV”).

[7] Supra n.1, Slip Opinion pp. 4-6.

 

[8] By “punting” on the question of copyrightability, the Court could be signaling that there is not strong agreement between the justices how or whether to address copyrightability of software amidst the digital revolution steaming forward to the smart phones of today and beyond.  Indeed, oral argument did not suggest any common ground with justices equally critical of both sides’ arguments and suggesting a reluctancy to fashion copyright rules unique to the software context.

 

[9] Supra n. 1, Slip Opinion pp. 23-24.

 

[10] Id., Dissenting Opinion pp. 10-11.

 

[11] Id., Slip Opinion pp. 25-26, Dissenting Opinion p. 16 (quoting Oracle IV, 886 F.3d at 1210).

 

[12] Id., Slip Opinion pp. 28-29, Dissenting Opinion p. 18.

 

[13] Id., Slip Opinion pp. 30-35, Dissenting Opinion p. 11-14.

 

[14] See, e.g., Gene Quinn, IPWatchDog, License to Copy: Your Software Code Isn’t Safe After Google v. Oracle (Apr. 6, 2021), https://www.ipwatchdog.com/2021/04/06/license-copy-software-code-isnt-safe-google-v-oracle/id=131860/