U.S. Supreme Court Upholds Fair Use in Google-Oracle Software Battle (Guest Blog Post)
By Guest Blogger Tyler Ochoa
[BONUS: Prof. Ochoa will be speaking on this case April 13, 6pm Pacific. Free registration.]
On April 5, the U.S. Supreme Court held 6-2 that Google’s copying of 11,500 lines of code from the Java SE Application Programming Interface (API) in creating its Android operating system was a fair use. Google LLC v. Oracle America, Inc., No. 18-956. Writing for the majority, Justice Breyer declined to answer the first question presented in the petition for certoriari: “Whether copyright protection extends to a software interface,” defined narrowly as “lines of computer code that allow developers to operate prewritten libraries of code to perform particular tasks.” “[W]e assume, for argument’s sake, that the material [copied] was copyrightable.” (Slip op. at 1) Instead, the majority held that even if the entire API was protected, Google’s use of the declaring code, defining the names of the methods and their organization into packages, classes, and methods, was fair: “where Google reimplemented a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative program, Google’s copying of the Sun Java API was a fair use of that material as a matter of law.” (Slip op. at 35)
The ruling ends a decade-long battle between Google and fellow software giant Oracle, which purchased Java developer Sun Microsystems in 2010. It also overturns the Federal Circuit’s 2018 ruling in favor of Oracle, which could have led to a multi-billion dollar award against Google. If the Federal Circuit’s opinion had been affirmed, it likely would have been highly disruptive to the software industry. Ever since the Lotus v. Borland case in the 1990s (affirmed without opinion by an equally divided Supreme Court, 4-4, with Justice Stevens recused), the software industry has assumed that interface specifications of this type were not protected by copyright. A concurring opinion in the Lotus case (by Judge Boudin) suggested that some kind of privileged use was an alternative path to the same result. Justice Breyer cited Judge Boudin’s opinion in his majority opinion, and the holding that Google’s use was fair follows Judge Boudin’s alternative path. (In the interests of full disclosure, I should note that I was one of 65 intellectual property scholars that signed an amicus brief in favor of Google in this case.)
Facts and Procedural Posture
To someone familiar with the basics of computer programming, the facts of this case are relatively straightforward; but to the layperson, the facts are complicated and may be difficult to understand. Justice Breyer’s opinion does a good job of laying out the facts (slip op. at 1-9) and the procedure posture (slip op. at 9-11). I will summarize the facts briefly here. If you are already familiar with the facts, you can skip to my analysis of the opinion below. (If you are interested in a longer in-depth explanation of the facts and legal background, you may listen to my one-hour lecture, presented to Santa Clara students before the oral argument.)
In the 1990s, Sun Microsystems developed the Java programming language and invited all programmers to use it. To facilitate its use, Sun also developed the Java SE (Standard Edition) Application Programming Interface (API). The Java API consists of a large number of prewritten programs that execute certain routine tasks, such as adding numbers, calculating an average, etc. Instead of having to write every piece of computer code from scratch, the Java API allows programmers to simply memorize the names (or “method calls”) associated with those basic tasks, which the programmer can then incorporate into more complex programs. “In this way, the [“method calls”] are similar to a gas pedal in a car that tells the car to move faster or the QWERTY keyboard on a typewriter that calls up a certain letter when you press a particular key.” (Slip op. at 6) In other words, they are “part of an interface between human beings and a machine.” (Id.)
The Java API is organized into 166 packages, thousands of classes, and tens of thousands of methods. The majority opinion notes that “No one claims that the decisions about what counts as a task are themselves copyrightable—although one might argue about decisions as to how to label and organize such tasks (e.g., the decision to name a certain task ‘max’ or to place it in a class called ‘Math’).” (Slip. op. at 21) The Java API consists of both declaring code and implementing code. “The declaring code both labels the particular tasks in the API and organizes those tasks, or ‘methods,’ into ‘packages’ and ‘classes.’ We have referred to this organization, by way of rough analogy, as file cabinets, drawers, and files.” (Slip op. at 22) The implementing code then “actually instructs the computer on the steps to follow to carry out each task.” (Id.) Finally, each of the names specified in the declaring code becomes a “method call,” the words that a computer programmer uses to invoke the program that executes the method or task. For example, to compare two numbers and determine which is the larger, the programmer would invoke (or “call”) the method by using the name “java.lang.math.max” (which indicates the “lang” package, the “math” class, and the “max” method).
In 2005, Google acquired Android, Inc., with the intention of developing a software platform for smartphones. Google negotiated with Sun for a license to customize the Java API in creating Android. (Both Apple and Microsoft paid Sun a license fee to customize the Java API.) The advantage to Google was that programmers already familiar to Java would not have to learn new names (or “method calls”) in order to create new programs for the Android platform. Talks broke down, however, over Sun’s insistence that any application programs (“apps”) written for Android must follow its “write once, run anywhere” philosophy. Google wanted to leave software developers relatively free and unconstrained in writing apps for Android.
After talks with Sun broke down, Google decided to create its own Android platform, and it took 100 programmers more than three years to do so. (Slip op. at 3) In order to attract Java programmers to the platform, however, Google copied 11,500 lines of declaring code from the Java API, which defined and named about 6,000 methods in about 600 classes in 37 of the 166 packages. Google then “reimplemented” the Java API by writing all of its own implementing code. The amount of declaring code that Google copied comprised about 3% of the code in the 37 packages, and about 0.4% of the code in the 166 packages in the entire Java API. Because of the copying, Google obtained the advantage that programmers already familiar with Java would be able to program easily in Android without having to learn new method calls.
As an aside, almost any trial lawyer will tell you that it is a “bad fact” that Google sought a license, and despite not getting one, went ahead and copied a portion of what it had sought to license anyway. Most people see the negotiations as an implicit concession that the material is protected by copyright (or by some other type of intellectual property). As the U.S. Supreme Court explained in Campbell v. Acuff-Rose Music, Inc., 510 U.S. 569 (1994), however, involving an alleged rap parody of the popular song “Pretty Woman”:
[W]e reject Acuff-Rose’s argument that 2 Live Crew’s request for permission to use the original should be weighed against a finding of fair use. Even if good faith were central to fair use, 2 Live Crew’s actions do not necessarily suggest that they believed their version was not fair use; the offer may simply have been made in a good-faith effort to avoid this litigation. If the use is otherwise fair, then no permission need be sought or granted. Thus, being denied permission to use a work does not weigh against a finding of fair use. (Id. at 585 n.18)
Moreover, the majority discounted the Google-Sun negotiations, noting that a large part of the perceived value of a license was the ability to use the trademarked term “Java” (“branding and cooperation,” slip op. at 33), which Google had to forego when it decided not to license Java and instead to develop Android on its own. Google also had to write all of its own implementing code, an expensive and time-consuming endeavor that is inconsistent with Oracle’s theme that Google was merely a pirate.
Android was released in November 2007, and within a few years it became wildly successful. Android-based smartphones and devices have captured a large share of the U.S. market, and as of 2015, they earned Google about $42 billion in revenue. (Slip. op. at 9) At the time, Sun’s CEO, Jonathan Schwartz, publicly congratulated Google, and he later testified that he didn’t think Google needed Sun’s permission to use the declaring code of the Java API in this manner. After Oracle purchased Sun in 2010, however, Oracle sued Google for both patent and copyright infringement.
At the initial trial, a jury found that Google had copied 11,500 lines of code, but it could not reach a verdict on the issue of fair use. (In a separate trial, the jury also rejected the patent infringement claims. That decision was not appealed.) The trial judge then held that the lines of code that were copied were not protected by copyright. 872 F. Supp. 2d 974 (N.D. Cal. 2012). Because the original case had included patent claims, the appeal went to the Federal Circuit instead of the Ninth Circuit, even though the patent claims were no longer part of the case. [For commentary on this jurisdictional loophole, see Peter Menell, API Copyrightability Bleak House: Unraveling and Repairing the Oracle v. Google Jurisdictional Mess, 31 Berkeley Tech. L.J. 1515 (2016).] The Federal Circuit reversed and remanded, holding that the Java API, including the declaring code, was protected by copyright; and it remanded for a new trial on fair use. 750 F.3d 1339 (Fed. Cir. 2014). The Supreme Court denied Google’s first petition for a writ of certiorari. 576 U.S. 1071 (2015).
On remand, the jury found that Google’s use was a fair use. (The jury was asked to render a general verdict in favor of one party or the other, rather than using a special verdict form with interrogatories.) Oracle moved for judgment as a matter of law (notwithstanding the verdict), which the trial judge rejected. On appeal, the Federal Circuit again reversed. 886 F.3d 1179 (Fed. Cir. 2018). It rejected three of the jury’s implicit findings in favor of Google, and instead held that no reasonable jury could find the work transformative; no reasonable jury could find the portion used was qualitatively insignificant; and no reasonable jury could find that there was no market harm. The Supreme Court granted certiorari (despite the negative recommendation of the Solicitor General). Oral argument was originally scheduled to be held on March 24, 2020; because of the pandemic, oral argument was postponed to this term (October 7, 2020).
Standard of Review
The most important part of the majority opinion for future fair use cases is the brief section on the standard of review (slip op. at 18-21). As the Supreme Court paraphrased it, the Federal Circuit held “that the ‘fair use’ question was a mixed question of fact and law; that reviewing courts should appropriately defer to the jury’s findings of underlying facts; but that the ultimate question whether those facts showed a ‘fair use’ is a legal question for judges to decide de novo.” (Slip. Op. at 18-19) The Supreme Court agreed with this approach. (Of course, the Federal Circuit gave only lip service to the jury’s implicit factual findings supporting the verdict, reversing those implicit findings on three of the four fair use factors. The Supreme Court corrected that error by expressly noting the substantial evidence on which the jury found in Google’s favor, in addition to its ultimate holding in Google’s favor.)
The Supreme Court also rejected two arguments based on the Seventh Amendment. The Seventh Amendment provides: “In Suits at common law … the right of trial by jury shall be preserved, and no fact tried by a jury, shall be otherwise re-examined in any Court of the United States, than according to the rules of the common law.” In practice, this means that a right to jury trial attaches to factual questions that would have been tried by a jury in 1791, while questions of law and questions that would have been decided in courts of equity do not carry a right to jury trial. The Supreme Court noted that it has described fair use as “an equitable rule of reason” (slip op. at 13), and it held that “the right of trial by jury” does not include “the right to have a jury resolve a fair use defense.” (Slip op. at 20). In addition, “[i]t does not violate the Reexamination Clause for a court to determine the controlling law in resolving a challenge to a jury verdict, as happens any time a court resolves a motion for judgment as a matter of law.” (Slip op. at 20)
Thus, the fact that a jury ruled in Google’s favor does not preclude a court from determining for itself whether a particular use is or is not “fair.” Courts already play a large role in fair use determinations, since many of them arise on a motion for a preliminary injunction, a purely equitable remedy that is decided by a judge. But the majority opinion means that fewer fair use cases will survive summary judgment to reach a trial; and those that do likely will utilize a special verdict form asking specific factual questions, rather than a general verdict simply asking who wins or loses (as in this case). The ruling also gives appellate judges even more power than they already exercise to overturn lower court rulings on the issue of fair use. (That’s a bit ironic, since the opinion was announced in a case in which the Federal Circuit exercised its power, only to have the Supreme Court agree with the principle but overrule the result.)
Question One: Are Interface Specifications Protected by Copyright?
There are many different kinds of interface specifications. Most courts agree that software-to-computer or software-to-software interface specifications, which must be followed in order for software to interoperate with the computer or with other software, are not protected by copyright. See, e.g., Computer Assocs. Int’l, Inc. v. Altai, Inc., 982 F.3d 693, 709-10 (2d Cir. 1992) (filtering out “mechanical specifications of the computer on which a particular program is intended to run”; “compatibility requirements of other programs with which a program is designed to operate in conjunction” and “computer manufacturers’ design standards”); Sega Enterprises, Ltd. v. Accolade, Inc., 977 F.2d 1510, 1522-25 (9th Cir. 1993) (approving reverse engineering “in order to discover the functional requirements for compatibility with the Genesis console — aspects of Sega’s programs that are not protected by copyright”); Sony Computer Ent’mt, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000) (same for Sony Playstation). More controversial are human-to-computer interface specifications. Those can be further subdivided into human-to-computer interface specifications for ordinary users or consumers, such as the menu command structure in Lotus Development Corp. v. Borland Int’l, Inc., 49 F.3d 807 (1st Cir. 1995) (not protected by copyright), aff’d by an equally divided Court, 516 U.S. 233 (1996); and the human-to-computer interface specifications for programmers involved in Google v. Oracle.
In the lower courts and on appeal, Google argued that the Java API’s interface specifications — the lines of declaring code that named the various methods, defined their inputs and outputs, and organized them into classes and packages — were not protected by copyright. It cited 17 U.S.C. 102(b), which denies copyright protection to “any idea, procedure, process, system, [or] method of operation.” The district court agreed and held that even though the command structure was original and creative, it was nonetheless part of the program’s “system” or “method of operation.” 872 F. Supp. 2d 974 (N.D. Cal. 2012). The Federal Circuit reversed and remanded, holding that “Section 102(b) does not … automatically deny copyright protection to elements of a computer program that are functional.” 750 F.3d 1339 (Fed. Cir. 2014).
As noted above, the majority purports to remain agnostic on the question of whether the Java API software interface specifications at issue were copyrightable. “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.” (Slip op. at 15) Nonetheless, in discussing the second fair use factor, “the nature of the copyrighted work,” the majority opinion strongly suggests that, at a minimum, such interface specifications should receive very little, if any, protection under copyright law. (See the Court’s discussion of the second fair use factor, below.)
Justice Breyer famously began his career as a law professor with a provocative article, The Uneasy Case for Copyright: A Study of Copyright in Books, Photocopies, and Computer Programs, 84 Harv. L. Rev. 281 (1970), in which he “warn[ed] against any headlong rush to provide computer programs with [copyright] protection.” Id. at 348. Breyer was also the newest Justice of the Supreme Court when the Lotus v. Borland case was argued before the Court in January 1996. That case involved the “menu command structure” (human interface specifications) for the popular Lotus 1-2-3 spreadsheet software; competitor Borland designed its own software to respond to the Lotus menu commands and user-created shortcuts (macros) to take advantage of the user base that had already learned how to use Lotus. The First Circuit had held that the menu command structure was an uncopyrightable method of operation, and its decision was affirmed by an equally divided Court, with Justice Stevens recused. 516 U.S. 233 (1996). Given his voting history in copyright cases, it is virtually certain that Justice Breyer voted to affirm the judgment in Lotus v. Borland.
My suspicion is that in Google v. Oracle, Justice Breyer wanted to hold that interface specifications were not protected by copyright as “systems” or “methods of operation,” but that he couldn’t garner a majority of justices willing to do so. Some justices were probably uncomfortable with the possible implications of a broad ruling, and preferred to rule on narrower grounds. Nonetheless, Justice Breyer wrote an opinion describing the Java API as a “system” and strongly suggesting that the declaring code deserved little, if any, copyright protection. (Slip op. at 24)
Dissenting, Justice Thomas (joined by Justice Alito), took the majority to task for declining to address the question of whether the software was copyrightable. Justice Thomas rejected any distinction between declaring code and implementing code:
Google’s argument … cannot account for Congress’ decision to define protected computer code as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” §101 (emphasis added)…. Implementing code orders a computer operation directly. Declaring code does so indirectly …. (Diss. op. at 6)
This argument is off the mark. All human-readable source code is used “indirectly” in a computer, because it first has to be compiled into object code or binary code (1s and 0s) in order for the computer to “directly” read it and execute it. The “directly or indirectly” language in the statute undoubtedly refers to the distinction between source code and object code, rather than to any distinction between two different types of source code (declaring code and implementing code).
Nonetheless, Justice Thomas is correct in one of his conclusions: “By skipping copyrightability, the majority gets the methodology backward, causing the Court to sidestep a key conclusion that ineluctably affects the fair-use analysis…. The result … is an opinion that makes it difficult to imagine any circumstance in which declaring code will remain protected by copyright.” (Diss. op. at 7-8) I fully agree; but since I signed an amicus brief arguing that the declaring code was not and should not be protected by copyright, I am entirely comfortable with that result.
The names of each individual method are not likely to be terribly original (a program to add numbers is probably called either “add” or “sum” rather than something truly original, like “Cathcart”); and individual names are not protected by copyright in any event. [37 C.F.R. § 201.1(a)] Instead, only a selection and arrangement of names can be protected. Java’s selection and arrangement was undoubtedly original under Feist. But programmers don’t use the names for their expressive content; they use the names in order to accomplish functional tasks. The result is very much like a QWERTY keyboard that uses names instead of letters for each key; the value lies in standardization, or network economic effects, rather than in the expressive value of the words chosen. From the point of view of economic policy, it makes much more sense to allow everyone to use the “standardized” method of operation, and to let them compete on different implementations of it.
In his concurring opinion in the Lotus v. Borland case, Judge Boudin described and confronted the standardization problem directly. His conclusion, altered minimally to fit this case, provides as good an explanation as any for what is ultimately a policy-driven decision:
But if a better [platform] comes along, it is hard to see why customers who have learned the [Java method calls] should remain captives of [Oracle] because of an investment in learning made by the users and not by [Oracle]. [Sun/Oracle] has already reaped a substantial reward for being first; assuming that the [Google Android platform] is now better, good reasons exist for freeing it to attract old [Java] customers: to enable the old customers to take advantage of a new advance, and to reward [Google] in turn for making a better product. If [Google] has not made a better product, then customers will remain with [Oracle] anyway.
49 F.3d 807, 821 (1st Cir. 1995) (Boudin, J., concurring). Judge Boudin concurred in the holding that the menu command structure in Lotus was not copyrightable as a “method of operation”; but he also suggested an alternative path to the same result: a type of privileged use. “The difference is that such a privileged use approach would not automatically protect [Google] if it had simply copied the [Java API], contributed nothing of its own, and resold [Java] under the [Android] label.” Id. He also recognized that “fair use” could be used to implement such a “privileged use” approach. Id. That is the route that the majority in Google v. Oracle chose to take.
Question Two: Was Google’s Use of Code from the Java API a Fair Use?
As readers familiar with copyright law are aware, the Copyright Act states simply that “the fair use of a copyrighted work … is not an infringement of copyright.” [17 U.S.C. § 107] The statute leaves it to courts to determine whether a particular use is fair on a case-by-case basis, with two sources of statutory guidance: six illustrative purposes (“for purposes such as criticism, comment, news reporting, teaching …, scholarship, or research”); and four factors to consider:
(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.
Unusually, the majority began its discussion of fair use with the second factor. In an empirical study, scholar Barton Beebe found that “the outcome of factor two typically has no significant effect on the overall outcome of the fair use test.” Barton Beebe, An Empirical Study of U.S. Copyright Fair Use Opinions, 1978-2005, 156 U. Pa. L. Rev. 549, 610 (2008). More recently, he found that “[f]air use opinions continue routinely to denigrate factor two as unimportant to the overall fair use analysis,” and that factor two “typically has a relatively minimal impact on the outcome of the overall four-factor test.” Barton Beebe, An Empirical Study of U.S. Copyright Fair Use Opinions Updated, 1978-2019, 10 N.Y.U. J. Intell. Prop. & Ent. L. 1, 30 (2020). Yet factor two occasionally can be quite important. For instance, in Harper & Row Publishers, Inc. v. Nation Enterprises, 471 U.S. 539 (1985) the Supreme Court repeatedly emphasized the previously unpublished nature of the material quoted from President Gerald Ford’s soon-to-published memoir, which overcome its otherwise factual nature and weighed heavily against fair use. Likewise, in Google v. Oracle, the majority opinion thought factor two sufficiently important that it began its fair use analysis with it.
Factor Two: The Nature of the Copyrighted Work
In discussing the second fair use factor, the majority noted testimony that Sun “sought to make the API ‘open’ and ‘then . . . compete on implementations.’” (Slip op. at 23). Thus, “Java’s creators … tried to find declaring code names that would prove intuitively easy to remember,” and the declaring code was “designed and organized in a way that is intuitive and understandable to developers so that they can invoke it.” (Id.) Moreover,
Unlike many other programs, [the declaring code’s] value in significant part derives from the value that … 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) Sun-related implementing programs that Google did not copy. (Slip op. at 24, emphasis added)
Thus, “for the reasons just described, the declaring code is, if copyrightable at all, further than are most computer programs (such as the implementing code) from the core of copyright.” (Id., emphasis added).
Justice Thomas’ dissenting opinion argued that “if anything, declaring code is closer to the ‘core of copyright.’ Developers cannot [or at least generally do not] even see implementing code. Implementing code thus conveys no expression to developers. Declaring code, in contrast, is user facing.” (Diss. op. at 10, citations omitted and bracketed comment inserted) In one sense, Justice Thomas is correct: if one was simply trying to decide which code was more “functional” and which code was more “expressive,” the answer would be that implementing code is more functional and declaring code is more expressive. (Justice Breyer attempts to debate this point by quoting record evidence describing the implementing code as “magic,” but the passage fails to convince.) But by Justice Thomas’ reasoning, object code or binary code (the 1s and 0s that actually interact with the computer) would be even more functional than implementing (source) code. The result would be difficult to square with Congress’ decision to protect software by copyright rather than by a sui generis intellectual property regime.
Instead, the ultimate policy question is: who should benefit from the investment that users have made in learning the names that Sun devised to organize and invoke the methods in its API? The majority believed that software programmers should not be “locked into” using Java simply because they had learned those names; instead, others should be free to use the names and to compete on their implementation of those names. (Slip op. at 34-35) The dissent believed that each new software platform should have to come up with its own names in order to compete for users. (Diss. op. at 14) I agree with the majority, for the reasons already discussed in my commentary on the first question presented, the one that the majority chose to avoid.
Factor One: The Purpose and Character of the Use
With regard to the first fair use factor, the central inquiry remains whether and to what the extent the defendant’s use is “transformative,” or “whether the copier’s use ‘adds something new, with a further purpose or different character, altering’ the copyrighted work ‘with new expression, meaning or message.’” (Slip op. at 24, quoting Campbell v. Acuff-Rose Music, Inc., 510 U.S. 569, 579 (1994)). The majority also quoted Judge Leval, who invented the “transformative” use concept, asking “whether the copier’s use ‘fulfill[s] the objective of copyright law to stimulate creativity for public illumination.’” (Slip op. at 24, quoting Leval, Toward a Fair Use Standard, 103 Harv. L. Rev 1105, 1111 (1990)).
Although “Google copied portions of the Sun Java API … for the same reason that Sun created those portions, namely, to enable programmers to call up implementing programs that would accomplish particular tasks” (slip op. at 25), the majority nonetheless held that “[t]o 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.” (Id.) The majority explained:
The record here demonstrates the numerous ways in which reimplementing an interface can further the development of computer programs. The jury heard that shared interfaces are necessary for different programs to speak to each other. It heard that the reimplementation of interfaces is necessary if programmers are to be able to use their acquired skills. It heard that the reuse of APIs is common in the industry. It heard that Sun itself had used pre-existing interfaces in creating Java. And it heard that Sun executives thought that widespread use of the Java programming language, including use on a smartphone platform, would benefit the company. (Slip op. at 26 (citations to the record omitted))
The statutory text also instructs courts to consider “whether such use is of a commercial nature or is for nonprofit educational purposes.” [17 U.S.C. § 107(1)] The majority acknowledged that Google’s use was commercial, but it brushed this consideration aside, noting that “many common fair uses are indisputably commercial,” including at least one statutory example, “news reporting.” (Slip op. at 27) This is consistent with the Campbell Court’s de-emphasis on the commercial nature of the use. The majority also gave some deference to “the jury finding in Google’s favor on hotly contested evidence,” and concluded that, on balance, factor one weighed in Google’s favor.
The difficulty with the “transformative” concept is that it substantially overlaps with one of the exclusive rights of the copyright owner: the exclusive right “to prepare derivative works based upon the copyrighted work.” [17 U.S.C. § 106(2)] A “derivative work” is defined as “a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted.” [17 U.S.C. § 101 (emphasis added)] Courts continue to struggle with the overlap and the distinction between derivative works that “transform” an original work of authorship and “transformative” purposes or uses that are entitled to greater consideration in a fair use analysis.
For a recent example, see the recent Second Circuit decision in Andy Warhol Foundation for the Visual Arts v. Goldsmith (decided March 26, 2021), in which the Second Circuit held that Warhol’s “Prince Series” of 16 artworks, based on a photograph of Prince taken by Goldsmith, was not a fair use. That court said: “It does not follow … that any secondary work that adds a new aesthetic or new expression to its source material is necessarily transformative” (op. at 19), and it suggested that “there exists an entire class of secondary works that add ‘new expression, meaning, or message’ to their source material but are nonetheless specifically excluded from the scope of fair use: derivative works.” (Op. at 20) That statement is clearly incorrect; there is nothing to suggest that either Congress or the Supreme Court intended to exclude all derivative works from the scope of fair use. To the contrary: in Campbell v. Acuff-Rose Music, Inc., for example, a unanimous Supreme Court held that a derivative rap version of the song “Pretty Woman” with altered lyrics could qualify as a “fair use” as a parody. 510 U.S. 569 (1994). The Warhol case might be ripe for rehearing (or even a cert. petition), in light of dicta in Google v. Oracle stating: “An ‘artistic painting’ might, for example, fall within the scope of fair use even though it precisely replicates a copyrighted ‘advertising logo to make a comment about consumerism.’” (Slip. op. at 25, quoting Netanel, Making Sense of Fair Use, 15 Lewis & Clark L. Rev. 715, 746 (2011).) (On the other hand, there may be good reasons to treat an advertising logo very differently from an artistic portrait photograph.) Perhaps the Warhol case is one of those instances in which courts should withhold an injunction and grant only a reasonable royalty as damages, as now-retired Ninth Circuit Judge Alex Kozinski suggested more than two decades ago. See Kozinski and Banner, What’s So Fair About Fair Use?, 46 J. Copyr. Soc’y USA 513 (1999).
Justice Thomas’ dissenting opinion makes the same mistake as the Warhol opinion when it complains that “the majority wrongly conflates transformative use with derivative use…. A work that simply serves the same purpose in a new context [smartphones instead of laptops and desktops] … is derivative, not transformative.” (Diss. op. at 17) A use can be both derivative and transformative; but some transformative uses will not be fair uses. The Supreme Court in Campbell suggested one way to distinguish fair uses from ordinary derivative uses was to look at market harm: “The market for potential derivative uses includes only those that creators of original works would in general develop or license others to develop.” 510 U.S. at 592. That’s a problem in this case, because there is evidence that Sun/Oracle was actively trying to license others to develop a compatible version of Java SE for smartphones. (See Factor Four) Perhaps Justice Thomas is correct when he opines in a footnote: “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.” (Diss. op. at 17 n.11)
Factor Three: The Amount and Substantiality of the Portion Used in Relation to the Copyrighted Work as a Whole
As noted in the facts, the 11,500 lines of declaring code that Google copied comprised about 3% of the 37 Java packages at issue, and about 0.4% of the 166 packages in the entire Java API. (The District Court used the former number, the Supreme Court majority used the latter. Slip op. at 28) As the majority acknowledged, the third factor is heavily dependent on the first factor: “The ‘substantiality’ factor will generally weigh in favor of fair use where, as here, the amount of copying was tethered to a valid, and transformative, purpose.” (Slip op. at 29) The majority held that this standard was satisfied:
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….
We do not agree with the Federal Circuit’s conclusion that Google could have achieved its Java-compatibility objective by copying only the 170 lines of code that are “necessary to write in the Java language.” 886 F.3d at 1206. In our view, that conclusion views Google’s legitimate objectives too narrowly. Google’s basic objective was not simply to make the Java programming language usable on its Android systems. It was to permit programmers to make use of their knowledge and experience using the Sun Java API when they wrote new programs for smartphones with the Android platform. In principle, Google might have created its own, different system of declaring code. But the jury could have found that its doing so would not have achieved that basic objective. In a sense, the declaring code was the key that it needed to unlock the programmers’ creative energies. And it needed those energies to create and to improve its own innovative Android systems. (Slip op. at 29-30)
Justice Thomas’ dissenting opinion tries to play with the numbers by saying that “the proper denominator is declaring code, not all code.” (Diss. op. at 18, emphasis in original) Of course, even if that is true, it is still the case that Google copied the declaring code from only 37 Java packages, rather than all of the 166 packages. (That’s about 22% of the declaring code if one assumes that each package is roughly the same size, which is probably not the case.) But again, the real dispute between the opinions is the policy one: who is entitled to take advantage of the investment that programmers have made in learning the Java method calls? As I have already discussed, the majority and the dissent differed on that fundamental issue.
Factor Four: The Effect of the Use upon the Potential Market for or Value of the Copyrighted Work
Under the fourth factor, the majority says that a court must consider not only “the amount of money that the copyright owner might lose,” but also “the source of the loss” (harms from substitution are “cognizable” while harms from criticism are not) and “the public benefits the copying will likely produce.” (Slip op. at 30-31) Having said that, it immediately disclaimed any universality to this analysis: “We do not say that these questions are always relevant …, [n]or do we say that these questions are the only questions that a court might ask.” (Slip op. at 31) In answering those questions here, the majority (unlike the Federal Circuit) deferred to the jury’s implicit findings of fact in Google’s favor:
[T]he jury could have found that Android did not harm the actual or potential markets for Java SE. And it could have found that Sun itself (now Oracle) would not have been able to enter those markets successfully whether Google did, or did not, copy a part of its API. First, evidence at trial demonstrated that, regardless of Android’s smartphone technology, Sun was poorly positioned to succeed in the mobile phone market…. It also heard that Sun’s many efforts to move into the mobile phone market had proved unsuccessful…. When Sun’s former CEO was asked directly whether Sun’s failure to build a smartphone was attributable to Google’s development of Android, he answered that it was not. Given the evidence showing that Sun was beset by business challenges in developing a mobile phone product, the jury was entitled to agree with that assessment.
Second, the jury was repeatedly told that devices using Google’s Android platform were different in kind from those that licensed Sun’s technology…. [The] record evidence demonstrates that, rather than just “repurposing [Sun’s] code from larger computers to smaller computers,” [Diss. op.] at 16, Google’s Android platform was part of a distinct (and more advanced) market than Java software. (Slip op. at 31-32)
In addition, “Google’s economic expert told the jury that Android was not a market substitute for Java’s software,” and “the jury also heard evidence that Sun foresaw a benefit from the broader use of the Java programming language in a new platform like Android, as it would further expand the network of Java-trained programmers.” (Slip op. at 32) Although “Sun presented evidence to the contrary,” “the jury’s fair use determination means that neither Sun’s effort to obtain a license nor Oracle’s conflicting evidence can overcome evidence indicating that, at a minimum, it would have been difficult for Sun to enter the smartphone market, even had Google not used portions of the Sun Java API.” (Slip op. at 33)
The majority then once again returned to the central policy question: who is entitled to take advantage of programmer’s investment in learning the names and method calls in the Java API? The majority’s answer to that question is clear:
When a new interface, like an API or a spreadsheet program, first comes on the market, it may attract new users because of its expressive qualities, such as a better visual screen or because of its superior functionality. As time passes, however, it may be valuable for a different reason, namely, because users, including programmers, are just used to it. They have already learned how to work with it. See Lotus Development Corp., 49 F.3d at 821 (Boudin, J., concurring).
The record here is filled with evidence that this factor accounts for Google’s desire to use the Sun Java API. This source of Android’s profitability has much to do with third parties’ (say, programmers’) investment in Sun Java programs. It has correspondingly less to do with Sun’s investment in creating the Sun Java API. We have no reason to believe that the Copyright Act seeks to protect third parties’ investment in learning how to operate a created work. (Slip op. at 33-34, emphasis added)
Justice Thomas again criticizes the majority, noting that a theater company can’t refuse to pay a copyright owner just because it has already memorized and rehearsed an existing work. (Diss. op. at 11) But a play or musical, of course, is used entirely for aesthetic and entertainment purposes. The dissenting opinion fails to grasp the important distinction between software and other works: software is functional, and therefore it is not only subject to section 102(b) (“In no case shall copyright protection extend to any idea, procedure, process, system, [or] method of operation”) (emphasis added), but it is also entitled to a narrower scope of protection under the second factor in the fair use doctrine. As the majority acknowledges, “[t]he fact that computer programs are primarily functional makes it difficult to apply traditional copyright concepts in that technological world.” (Slip op. at 35).
Commentary
I was pleasantly surprised that the Court ruled for Google, as I didn’t think the oral argument had gone particularly well for Google. The procedural posture, and the 6-2 vote, means that Justice Ginsburg’s death and Justice Barrett’s absence likely did not affect the outcome. (A 4-4 vote would have left the Federal Circuit’s rulings in favor of Oracle intact; and had Justice Ginsburg still been on the Court, she almost certainly would have voted to affirm.) Justice Breyer’s opinion was joined not only by Justices Kagan and Sotomayor, but also by Chief Justice Roberts and Justices Gorsuch and Kavanaugh, demonstrating once again that intellectual property cases rarely are decided along conventional political lines. I am somewhat disappointed that Justice Alito joined Justice Thomas in dissent, as Justice Alito authored one of the leading cases denying copyright protection to parts numbers: Southco, Inc. v. Kanebridge Corp., 390 F.3d 276 (3d Cir. 2004) (en banc) (even though Southco had devised an original “system” for numbering its parts, the application of that system to any particular part lacked any originality or creativity).
The issues presented in this case could have been (and should have been) decided 25 years ago, when the Court granted certiorari in the Lotus v. Borland case. Instead, Justice Stevens was recused, and the remaining judges split 4-4, affirming the result by an equally divided Court. But perhaps because observers believed that Justice Stevens would have voted against copyrightability in Lotus, the entire software industry accepted the First Circuit’s opinion that human-computer interface specifications were not copyrightable. It has operated on that assumption for the past two-and-a-half decades. Had the Supreme Court held in favor of Oracle, it would have had an incredibly disruptive influence on the entire software industry, a clear majority of whom thought Google should win the case. I imagine that some of the justices in the majority were at least somewhat influenced by the large number of amicus briefs from the software industry that supported Google.
When the Federal Circuit initially ruled that the Java API was copyrightable, it was a shock to the software industry: an issue that everyone thought had been settled in the 1990s was suddenly alive and well again. [See Peter Menell, Rise of the API Copyright Dead? An Updated Epitaph for Copyright Protection of Network and Functional Features of Computer Software, 31 Harv. J.L. & Tech. 305 (2018).] But the possibility of fair use on remand left most in the software industry cautiously optimistic. The jury’s ruling in favor of Google caused the majority of the software industry to exhale a sigh of relief: fair use was just an alternative route to the same result (albeit one that promised higher litigation costs). When the Federal Circuit reversed again, things looked bleak for developers: would they have to get permission to write any kind of interoperable software in the future? The Supreme Court’s ruling in favor of Google restores the status quo. I would have preferred that the majority had ruled instead on section 102(b) grounds; but at least it reached the right result.
The case also highlights the absence of any kind of laches doctrine in copyright law, a result of the Supreme Court’s opinion in Petrella v. MGM, in which Justice Ginsburg (writing for a 6-3 majority, with Justice Breyer, joined by Chief Justice Roberts and Justice Kennedy, dissenting) held that laches could not be invoked during the three-year statute of limitations period, which begins anew with each act of infringement. As noted above, when Google released Android in 2007, Sun Microsystems, the developer of the Java SE API, apparently didn’t think Google had done anything wrong. It was only after Oracle purchased Sun in 2010 that Oracle filed suit for copyright infringement. Had laches been available, Oracle might very well have been bound by its predecessor-in-interest’s implicit admission. As it was, the testimony of Sun’s former CEO likely influenced the jury’s decision in favor of Google.
Any Supreme Court opinion is important, and this one no doubt will be quoted often in future briefs and opinions. But other than clarifying the standard of review, I doubt the decision will have much impact on fair use cases that do not involve software. The economic and functional considerations that led the majority to rule in favor of Google simply don’t apply to most cases involving ordinary copyrighted works. For software developers and the software industry, however, the decision is momentous. Not only does it resolve a multi-billion dollar dispute between two Silicon Valley tech giants, but it finally settles a question that was only implicitly decided in 1996.
Finally, I am struck by how many times Google has taken an aggressive fair use position that led to expensive litigation, only to be ultimately vindicated in the end. It has happened at least four times. First, there was the extensive automated copying of text posted on the Internet in implementing Google’s search engine. See Field v. Google, Inc., 412 F. Supp. 2d 1176 (D. Nev. 2006) and Parker v. Google, Inc., 422 F. Supp. 2d 492 (E.D. Pa. 2006), aff’d, 242 Fed. Appx. 833 (3d Cir. 2007), cert. denied, 552 U.S. 1156 (2008). Then there was the extensive automated copying of photographs posted on the Internet in implementing Google’s image search engine. Although the Ninth Circuit initially ruled (in a case involving a different search engine) in favor of fair use for image thumbnails and against full-size display through inline linking, see Kelly v. Arriba Soft Corp., 280 F.3d 934 (9th Cir. 2002), it later withdrew the ruling on full-size display, see Kelly v. Arriba Soft Corp., 336 F.3d 811 (9th Cir. 2002), and it ultimately affirmed the propriety of Google’s conduct. Perfect 10, Inc. v. Amazon.com, Inc., 508 F.3d 1146 (9th Cir. 2007). Then there was the wholesale copying (but only limited public display) of books from several libraries in implementing Google Book Search. See Authors Guild v. HathiTrust, 755 F.3d 87 (2d Cir. 2014) and Authors Guild v. Google, Inc., 804 F.3d 202 (2d Cir. 2015). It is difficult to remember now that when the Google Books project was first announced in 2004, it was incredibly controversial; and Google was vindicated only after a tentative settlement to which the Justice Department objected, and a decade of litigation involving two appeals to the Second Circuit. Google v. Oracle likewise required a decade of litigation, two appeals to the Federal Circuit, and a trip to the Supreme Court. Only Google’s accumulated wealth enabled it to litigate all of those cases to their ultimate conclusion in its favor, instead of settling on less-favorable terms. Its efforts have permanently shaped the landscape of fair use as applied to new technologies.