Supreme Court Sides With Google In Decade-Long Fight Over API Copyright; Google's Copying Of Java API Is Fair Use
It's taken over a decade, but the Supreme Court has finally said that Google's copying of the Sun Java API for Android was clearly fair use in a 6-2 ruling (Barrett did not take part since she was not on the Court when the case was heard). The background of this case is actually kind of important to understanding what just happened, so here's a quick(ish) recap.
As you'll probably know, this case began in 2010 when Oracle, which had just taken over Sun, sued Google for patent infringement. The patent parts were quickly tossed out and what remained was what referred to as a "sideshow" to the main event: a question about whether APIs could be covered by copyright. Pretty much all historical evidence, including an important Supreme Court ruling from the 1990s, said no, interfaces are not covered by copyright.
Oracle and friends then spent the next decade deliberately gaslighting basically everyone who doesn't understand what an API is, and insisting that it's the same as executable code. The district court, under Judge William Alsup, who somewhat famously taught himself Java to better understand the issues in the case (he already knew how to code and was a hobbyist programmer), correctly found that APIs are not subject to copyright as they represent a "system or method of operation" which is explicitly not covered by copyright, as per Section 102(b) of the Copyright Act.
Rather than go to the 9th Circuit (as it should have) the case went to the Federal Circuit, which hears all patent appeals. That was because the case began as a patent case, even though it no longer was. CAFC judges are somewhat infamous for never finding a patent issue they couldn't screw up, and decided to extend that to copyright. In the ruling overturning the lower court, they made it clear that because they were code illiterate they could not understand the difference between executing code and an API, even though it's like the difference between a novel and a dictionary.
The case went back to the district court, where the jury this time sided with Google, this time saying that the use of the code was covered under fair use. That whole trial was a little weird, because reading between the lines, you could see that nearly all the arguments for why copying an API was fair use were really about why an API shouldn't be covered by copyright at all (as per Alsup's original ruling) and then squeezing that square peg into the round hole of fair use to make it work. Once again, however, CAFC got flummoxed by an API looking like code and overturned -- which is quite crazy because CAFC had, in its first ruling, insisted that the jury should decide this issue (as a matter of fact) and then when the jury said "fair use" CAFC suddenly decided that it was a matter of law that it could overrule.
Finally, we get to the Supreme Court. From oral arguments, it wasn't clear where the court was leaning -- with some good questions and some crazy questions. But with today's ruling, it's clear that the smarter questioners won out. The majority opinion was written by Justice Breyer, who has always been the best Justice on copyright issues, and had the support of Justices Roberts, Kagan, Gorsuch, Kavanaugh, and Sotomayor.
Breyer starts out by noting (thankfully, unlike the CAFC judges) that it's important to understand just what an API actually is.
Consider in more detail just what an API does. A computer can perform thousands, perhaps millions, of differenttasks that a programmer may wish to use. These tasksrange from the most basic to the enormously complex. Askthe computer, for example, to tell you which of two numbersis the higher number or to sort one thousand numbers inascending order, and it will instantly give you the right answer. An API divides and organizes the world of computingtasks in a particular way. Programmers can then use theAPI to select the particular task that they need for theirprograms. In Sun's API (which we refer to as the Sun JavaAPI), each individual task is known as a method." The APIgroups somewhat similar methods into larger classes," andgroups somewhat similar classes into larger packages."This method-class-package organizational structure is referred to as the Sun Java API's structure, sequence, andorganization," or SSO.
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 (suchas telling you, of two numbers, which is the higher). SeeOracle, 872 F. Supp. 2d, at 979-980. The implementingcode (which Google independently wrote) is not at issuehere. 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 programswithout drawing on prewritten task-implementing programs to execute discrete tasks.
But how do you as the programmer tell the computerwhich of the implementing code programs it should choose, i.e., which task it should carry out? You do so by enteringinto your own program a command that corresponds to thespecific task and calls it up. Those commands, known asmethod calls," help you carry out the task by choosingthose programs written in implementing code that will dothe trick, i.e., that will instruct the computer so that yourprogram will find the higher of two numbers. If a particularcomputer might perform, say, a million different tasks, different method calls will tell the computer which of thosetasks 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 programmertypes) actually locate and invoke the particular implementing code that it needs to instruct the computer how to carryout a particular task? It does so through another type ofcode, which the parties have labeled declaring code." Declaring code is part of the API. For each task, the specificcommand 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 eachtask within the API's overall organizational system (i.e., theplacement of a method within a particular class and theplacement of a class within a particular package). In thissense, the declaring code and the method call form a link,allowing the programmer to draw upon the thousands ofprewritten tasks, written in implementing code. See id., at979-980. 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 in the Sun Java API. The first, more obvious, function is that the declaring code enables a set ofshortcuts 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.For example, a programmer building a new application forpersonal banking may wish to use various tasks to, say, calculate a user's balance or authenticate a password. To doso, she need only learn the method calls associated withthose tasks. In this way, the declaring code's shortcut function is similar to a gas pedal in a car that tells the car tomove faster or the QWERTY keyboard on a typewriter thatcalls up a certain letter when you press a particular key. Asthose analogies demonstrate, one can think of the declaringcode as part of an interface between human beings and amachine.
The second, less obvious, function is to reflect the way inwhich Java's creators have divided the potential world ofdifferent tasks into an actual world, i.e., precisely which setof potentially millions of different tasks we want to haveour Java-based computer systems perform and how wewant those tasks arranged and grouped. In this sense, thedeclaring code performs an organizational function. It determines the structure of the task library that Java's creators have decided to build. To understand this organizational system, think of the Dewey Decimal System thatcategorizes books into an accessible system or a travel guidethat arranges a city's attractions into different categories.Language itself provides a rough analogy to the declaringcode's organizational feature, for language itself dividesinto sets of concepts a world that in certain respects otherlanguages might have divided differently. The developersof Java, for example, decided to place a method called drawimage" inside of a class called graphics."
Not a bad description for an 82-year-old Supreme Court Justice (kudos to his clerks and the various parties and amici that briefed this). One of the big debates in the lead up to the case, and at oral arguments, was what "analogy" best represented what an API was. You can see above Breyer mention the Dewey Decimal System, which is a pretty good analogy. Then he includes another:
Consider a comprehensive, albeit farfetched, analogythat illustrates how the API is actually used by a programmer. Imagine that you can, via certain keystrokes, instructa robot to move to a particular file cabinet, to open a certaindrawer, and to pick out a specific recipe. With the proper recipe in hand, the robot then moves to your kitchen andgives it to a cook to prepare the dish. This example mirrorsthe API's task-related organizational system. Throughyour simple command, the robot locates the right recipe andhands it off to the cook. In the same way, typing in amethod call prompts the API to locate the correct implementing code and hand it off to your computer. And importantly, to select the dish that you want for your meal,you do not need to know the recipe's contents, just as a programmer using an API does not need to learn the implementing code. In both situations, learning the simple command is enough.
Of course, reading this you might hope that Breyer is about to go all the way to the point that he should and say that APIs, as systems and methods, are clearly not covered by copyright under 102(b). But, unfortunately, he does not. The majority opinion goes for the 2nd best option, just saying that this is fair use. But there are still some fascinating tidbits on the way there. Incredibly, Breyer quotes Thomas Macaulay's amazing speech on copyright in 1841 that we've quoted on Techdirt many times before. I wasn't expecting to see it here, however. But here is Breyer explaining how copyright is a "tax":
Macaulay once said that the principle of copyright is atax on readers for the purpose of giving a bounty to writers." T. Macaulay, Speeches on Copyright 25 (E. Miller ed.1913). Congress, weighing advantages and disadvantages,will determine the more specific nature of the tax, itsboundaries and conditions, the existence of exceptions andexemptions, all by exercising its own constitutional powerto write a copyright statute.
And then he notes that Congress has put limits on copyright, including the limits on what is subject to copyright (Section 102), and then other limitations found throughout the Copyright Act, including fair use (Section 107). Breyer then notes that even though Google asked the Court to say APIs are not covered by copyright, since they can answer the fair use question and dispose of the issue, the court will just assume that APIs are subject to copyright for the sake of exploring fair use, and leave the actual question of copyright and APIs to another day (groan).
A holding for Google on either question presented woulddispense with Oracle's copyright claims. Given the rapidlychanging technological, economic, and business-related circumstances, we believe we should not answer more than isnecessary to resolve the parties' dispute. We shall assume,but purely for argument's sake, that the entire Sun JavaAPI falls within the definition of that which can be copyrighted. We shall ask instead whether Google's use of partof that API was a fair use." Unlike the Federal Circuit, weconclude that it was.
Still, the fair use analysis itself is quite interesting. It notes that software copyright has been a tricky question in general, given that it has both creative literary elements and functional elements (which are not supposed to be covered by copyright).
Generically speaking, computer programs differ frombooks, films, and many other literary works" in that suchprograms almost always serve functional purposes. Theseand other differences have led at least some judges to complain that applying copyright law to computer programs islike assembling a jigsaw puzzle whose pieces do not quitefit." Lotus Development Corp. v. Borland Int'l, Inc., 49 F.3d 807, 820 (CA1 1995) (Boudin, J., concurring).
These differences also led Congress to think long andhard about whether to grant computer programs copyrightprotection. In 1974, Congress established a National Commission on New Technological Uses of Copyrighted Works(CONTU) to look into the matter. 201-208, 88 Stat.1873-1875. After several years of research, CONTU concluded that the availability of copyright protection for computer programs is desirable." Final Report 11 (July 31,1978). At the same time, it recognized that computer programs had unique features. Mindful of not unduly burdening users of programs and the general public," it wrote thatcopyright should not grant anyone more economic powerthan is necessary to achieve the incentive to create." Id., at12. And it believed that copyright's existing doctrines (e.g.,fair use), applied by courts on a case-by-case basis, couldprevent holders from using copyright to stifle innovation.Ibid. (Relatively few changes in the Copyright Act of 1976are required to attain these objectives"). Congress thenwrote computer program protection into the law. See 10,94 Stat. 3028.
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. Itcan help to distinguish among technologies. It can distinguish between expressive and functional features of computer code where those features are mixed. It can focus onthe legitimate need to provide incentives to produce copyrighted material while examining the extent to which yetfurther protection creates unrelated or illegitimate harmsin other markets or to the development of other products.In a word, it can carry out its basic purpose of providing acontext-based check that can help to keep a copyright monopoly within its lawful bounds. See H. R. Rep. No. 94-1476, pp. 65-66 (1976) (explaining that courts are to adaptthe doctrine [of fair use] to particular situations on a caseby-case basis" and in light of rapid technological change");see, e.g., Lexmark Int'l, Inc. v. Static Control Components,Inc., 387 F. 3d 522, 543-545 (CA6 2004) (discussing fair usein the context of copying to preserve compatibility); SonyComputer Entertainment, Inc. v. Connectix Corp., 203 F. 3d596, 603-608 (CA9 2000) (applying fair use to intermediatecopying necessary to reverse engineer access to unprotectedfunctional elements within a program); Sega EnterprisesLtd. v. Accolade, Inc., 977 F. 2d 1510, 1521-1527 (CA91992) (holding that wholesale copying of copyrighted codeas a preliminary step to develop a competing product was afair use).
Breyer notes his confusion over Justice Thomas' dissent (we'll get there) and says that Congress clearly meant for fair use to apply to software:
We do not understand Congress, however, to haveshielded computer programs from the ordinary applicationof copyright's limiting doctrines in this way. By definingcomputer programs in 101, Congress chose to place thissubject matter within the copyright regime. Like other protected works, that means that the owners of computer programs enjoy the exclusive rights set forth in the Act, including the right to reproduce [a] copyrighted work" or toprepare derivative works." 17 U. S. C. 106. But that alsomeans that exclusive rights in computer programs are limited like any other works. Just as fair use distinguishesamong books and films, which are indisputably subjects ofcopyright, so too must it draw lines among computer programs. And just as fair use takes account of the market inwhich scripts and paintings are bought and sold, so toomust it consider the realities of how technological works arecreated and disseminated. We do not believe that an approach close to all or nothing" would be faithful to the Copyright Act's overall design.
Breyer notes that CAFC got things correct in saying that fair use is both a matter of fact (for juries) and of law (for judges) -- though leaves out that in the first go-round, the CAFC suggested otherwise. So he rejects Google's suggestion that the jury ruling on fair use should stand without judicial review. However, he still says that the jury was correct in the finding of fair use after going through the standard four factor test. The fact that the work in question was an API weighs heavily in the fair use determination, as part of the "nature of the work" test (the second of the four factors). The majority opinion notes that the key parts of the API, the declaring code, are not that "close to the core" of the purpose of copyright:
The declaring code (inseparable from the programmer'smethod calls) embodies a different kind of creativity. SunJava's creators, for example, tried to find declaring codenames that would prove intuitively easy to remember. Id.,at 211. They wanted to attract programmers who wouldlearn the system, help to develop it further, and prove reluctant to use another. See post, at 10 (Declaring code . . .is user facing. It must be designed and organized in a waythat is intuitive and understandable to developers so thatthey can invoke it"). Sun's business strategy originally emphasized the importance of using the API to attract programmers. It sought to make the API open" and then . . .compete on implementations." App. 124-125. The testimony at trial was replete with examples of witnesses drawing this critical line between the user-centered declaratorycode and the innovative implementing code....
These features mean that, as part of a user interface, thedeclaring code differs to some degree from the mine run ofcomputer programs. Like other computer programs, it isfunctional in nature. But unlike many other programs, itsuse is inherently bound together with uncopyrightableideas (general task division and organization) and new creative expression (Android's implementing code). Unlikemany other programs, its value in significant part derivesfrom the value that those who do not hold copyrights,namely, computer programmers, invest of their own timeand effort to learn the API's system. And unlike many otherprograms, 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 programsthat Google did not copy.
Although copyrights protect many different kinds of writing, Leval 1116, we have emphasized the need torecogni[ze] that some works are closer to the core of [copyright] than others," Campbell, 510 U. S., at 586. In ourview, for the reasons just described, the declaring code is, ifcopyrightable at all, further than are most computer programs (such as the implementing code) from the core of copyright. That fact diminishes the fear, expressed by both thedissent and the Federal Circuit, that application of fairuse" here would seriously undermine the general copyrightprotection that Congress provided for computer programs.And it means that this factor, the nature of the copyrightedwork," points in the direction of fair use.
As for the purpose and character of the use, that also leans towards fair use in important ways -- highlighting the transformative nature of Google's use for Android here:
Here Google's use of the Sun Java API seeks to createnew products. It seeks to expand the use and usefulness ofAndroid-based smartphones. Its new product offers programmers a highly creative and innovative tool for asmartphone environment. To the extent that Google usedparts of the Sun Java API to create a new platform thatcould be readily used by programmers, its use was consistent with that creative progress" that is the basic constitutional objective of copyright itself. Cf. Feist, 499 U. S.,at 349-350 (The primary objective of copyright is not to reward the labor of authors, but [t]o promote the Progress ofScience and useful Arts'" (quoting U. S. Const., Art. I, 8,cl. 8)).
The opinion also rejects the idea that just because Google was copying the API for commercial reasons somehow means it's not fair use:
There is no doubt that a finding thatcopying was not commercial in nature tips the scales in favor of fair use. But the inverse is not necessarily true, asmany common fair uses are indisputably commercial. Forinstance, the text of 107 includes examples like news reporting," which is often done for commercial profit. So eventhough Google's use was a commercial endeavor-a fact noparty disputed, see 886 F. 3d, at 1197-that is not dispositive of the first factor, particularly in light of the inherentlytransformative role that the reimplementation played inthe new Android system.
One of the key arguments Oracle and its supporters made was that Google's actions were done in "bad faith" because it first tried to negotiate a license with Sun, and when that failed, just copied the API. However, Breyer points out that this just doesn't matter:
As for bad faith, our decision in Campbell expressed some skepticism about whether bad faith has any role in a fairuse analysis. 510 U. S., at 585, n. 18. We find this skepticism justifiable, as [c]opyright is not a privilege reservedfor the well-behaved." Leval 1126. We have no occasionhere to say whether good faith is as a general matter a helpful inquiry. We simply note that given the strength of theother factors pointing toward fair use and the jury findingin Google's favor on hotly contested evidence, that factbound consideration is not determinative in this context
On the "amount and substantiality of the portion used", again the majority says this leans towards fair use. It mentions, in passing, that some of this could depend on whether the whole product being copied is all of Java or just the API, but then notes that doesn't really matter. The important question is whether or not Google copied more than it needed to to achieve the transformative use it set out to accomplish. And there the court says that Google did not go too far:
Google copied those lines not because of their creativity, their beauty, or even (in a sense) because of theirpurpose. It copied them because programmers had alreadylearned to work with the Sun Java API's system, and itwould have been difficult, perhaps prohibitively so, to attract programmers to build its Android smartphone systemwithout them. Further, Google's basic purpose was to create a different task-related system for a different computingenvironment (smartphones) and to create a platform-theAndroid platform-that would help achieve and popularizethat objective. The substantiality" factor will generallyweigh in favor of fair use where, as here, the amount of copying was tethered to a valid, and transformative, purpose.Supra, at 25-26; see Campbell, 510 U. S., at 586-587 (explaining that the factor three enquiry will harken back tothe first of the statutory factors, for . . . the extent of permissible copying varies with the purpose and character ofthe use").
We do not agree with the Federal Circuit's conclusionthat 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 simplyto make the Java programming language usable on its Android systems. It was to permit programmers to make useof their knowledge and experience using the Sun Java APIwhen they wrote new programs for smartphones with theAndroid platform. In principle, Google might have createdits own, different system of declaring code. But the jurycould have found that its doing so would not have achievedthat basic objective. In a sense, the declaring code was thekey that it needed to unlock the programmers' creative energies. And it needed those energies to create and to improve its own innovative Android systems.
Finally, there's the impact on the market question. The majority opinion goes back and forth presenting the arguments on both sides and then notes that if Oracle was allowed to completely lock up the Java API, it would go against copyright's basic objectives and potentially harm the public! It's really nice to hear that stated so clearly:
Finally, given programmers' investment in learning theSun Java API, to allow enforcement of Oracle's copyrighthere would risk harm to the public. Given the costs anddifficulties of producing alternative APIs with similar appeal to programmers, allowing enforcement here wouldmake of the Sun Java API's declaring code a lock limitingthe future creativity of new programs. Oracle alone wouldhold the key. The result could well prove highly profitableto Oracle (or other firms holding a copyright in computerinterfaces). But those profits could well flow from creativeimprovements, new applications, and new uses developedby users who have learned to work with that interface. Tothat extent, the lock would interfere with, not further, copyright's basic creativity objectives
Finally, Breyer notes that all of this is completely consistent with past Supreme Court precedent, and they're not overturning anything:
The fact that computer programs are primarily functional makes it difficult to apply traditional copyright concepts in that technological world. See Lotus DevelopmentCorp., 49 F. 3d, at 820 (Boudin, J., concurring). In doing sohere, we have not changed the nature of those concepts. Wedo not overturn or modify our earlier cases involving fairuse-cases, for example, that involve knockoff " products,journalistic writings, and parodies. Rather, we here recognize that application of a copyright doctrine such as fair usehas long proved a cooperative effort of Legislatures andcourts, and that Congress, in our view, intended that it socontinue. As such, we have looked to the principles set forthin the fair use statute, 107, and set forth in our earliercases, and applied them to this different kind of copyrightedwork.
Well done. It would have been nicer if they'd also offered a clean answer on whether or not APIs are subject to copyright at all, but in absence of that, this will be a useful fair use case going forward.
As for the dissent from Justices Thomas (co-signed by Alito)... it's weird. First it says that the majority should not have ignored the copyrightability question -- though it argues that if that had been explored, APIs would clearly be covered (again, I believe this is wrong). Thomas falls for the same trap that the CAFC judges did -- insisting that because it's all confusing to them, API code and executable code are basically the same thing, because they "are bound together." This is just weird. The Supreme Court has, in the past, recognized that multiple parts of the same work, even those that are bound together, can have some elements that are covered by copyright and some that are not. Why Thomas and Alito ignore this is beyond me.
Their fair use analysis is similarly just wrong. Whereas the majority found all four factors favored Google, Thomas/Alito insist that three "decisively favor Oracle." Again, Thomas demonstrates his technical ignorance in insisting that declaring code and implementing code are effectively no different. Regarding the harm on the market, Thomas insists that the majority is all speculative, and the fact that the European Commission has fined Google for antitrust practices shows that if the Court is worried about lock-in, it should be worried about Google, not Oracle. There is a kernel of a point in there, but it's got nothing to do with the case at hand.
Thomas then gives the freakout we've been hearing from Oracle supporters for the last decade: that saying an API is not covered by copyright (or copying it is fair use) will somehow eviscerate copyright on software.
Now, we are told, transformative"simply means-at least for computer code-a use that willhelp others create new products." Ibid; accord, ante, at 26(Google's copying can further the development of computerprograms").
That new definition eviscerates copyright. A movie studio that converts a book into a film without permission notonly creates a new product (the film) but enables others tocreate products"-film reviews, merchandise, YouTubehighlight reels, late night television interviews, and thelike. Nearly every computer program, once copied, can beused to create new products. Surely the majority would notsay that an author can pirate the next version of MicrosoftWord simply because he can use it to create new manuscripts.
But that's just ludicrous. The majority decision lays out all the ways Google copying the API resulted in new products -- because it enabled more programmers to write apps for Android. It's not saying that the Android copy itself was to create products. Thomas is completely misreading the issue, and I can assure you that no court is going to read the majority decision to say that standard piracy is now fair use.
Thomas claims that the majority is conflating transformative use with derivative use, but it's actually Thomas who is doing that with the above paragraph. The majority is not saying that derivative use is obviously fair use, but if the effort is transformative, using functional specs to create a system for others to make use of, then it can be transformative. Google's use wasn't derivative -- it was building an entirely different system, and wanted to include some familiar guideposts for developers.
Hilariously, after previously insisting that the Java declaring code and implementing code were too inextricably tied together to separate out what was copyrightable and what was not, Thomas then rejects that in looking at the amount used factor -- saying we must only look at the declaring code.
But the proper denominator is declaring code, not all code. A copied work isquantitatively substantial if it could serve as a market substitute for the original" work or potentially licensed derivatives" of that work. Campbell, 510 U. S., at 587. The declaring code is what attracted programmers. And it is whatmade Android a market substitute" for potentially licensed derivatives" of Oracle's Java platform. Google's copying was both qualitatively and quantitatively substantial.
The entire dissent is a mess of nonsense and question-begging.
In the end, this is a good decision and helps avoid the disaster that would have occurred if Oracle's viewpoint had won out. Somewhat ironically, as we've pointed out before, Google winning on this argument is actually good for competition, as it will also create more opportunities for new companies to undermine Google's own position in the market as well. This is a good ruling and the entire software development community can breathe a bit easier.