Supreme Court Sides With Google In Decade-Long Fight Over API Copyright; Google's Copying Of Java API Is Fair Use
from the good-news dept
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 different tasks that a programmer may wish to use. These tasks range from the most basic to the enormously complex. Ask the computer, for example, to tell you which of two numbers is the higher number or to sort one thousand numbers in ascending order, and it will instantly give you the right answer. 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. In Sun’s API (which we refer to as the Sun Java API), each individual task is known as a “method.” The API groups somewhat similar methods into larger “classes,” and groups somewhat similar classes into larger “packages.” This method-class-package organizational structure is referred to as the Sun Java API’s “structure, sequence, and organization,” 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 (such as telling you, of two numbers, which is the higher). See Oracle, 872 F. Supp. 2d, at 979–980. 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, i.e., that will instruct the computer so that your program will find the higher of two numbers. If a particular computer might perform, say, a million different tasks, 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 (i.e., the placement of a method within a particular class and the placement of a class within a particular package). In this sense, the declaring code and the method call form a link, allowing the programmer to draw upon the thousands of prewritten tasks, written in implementing code. See id., at 979–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 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. For example, a programmer building a new application for personal banking may wish to use various tasks to, say, calculate a user’s balance or authenticate a password. To do so, she need only learn the method calls associated with those tasks. In this way, the declaring code’s shortcut function is 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. As those analogies demonstrate, one can think of the declaring code as part of an interface between human beings and a machine.
The second, less obvious, function is to reflect the way in which Java’s creators have divided the potential world of different tasks into an actual world, i.e., precisely which set of potentially millions of different tasks we want to have our Java-based computer systems perform and how we want those tasks arranged and grouped. In this sense, the declaring 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 that categorizes books into an accessible system or a travel guide that arranges a city’s attractions into different categories. Language itself provides a rough analogy to the declaring code’s organizational feature, for language itself divides into sets of concepts a world that in certain respects other languages might have divided differently. The developers of Java, for example, decided to place a method called “draw image” 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, analogy that illustrates how the API is actually used by a programmer. Imagine that you can, via certain keystrokes, instruct a robot to move to a particular file cabinet, to open a certain drawer, and to pick out a specific recipe. With the proper recipe in hand, the robot then moves to your kitchen and gives it to a cook to prepare the dish. This example mirrors the API’s task-related organizational system. Through your simple command, the robot locates the right recipe and hands it off to the cook. In the same way, typing in a method 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 a “tax 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, its boundaries and conditions, the existence of exceptions and exemptions, all by exercising its own constitutional power to 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 would dispense with Oracle’s copyright claims. 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. We shall ask instead whether Google’s use of part of that API was a “fair use.” Unlike the Federal Circuit, we conclude 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 from books, films, and many other “literary works” in that such programs almost always serve functional purposes. These and other differences have led at least some judges to complain that “applying copyright law to computer programs is like assembling a jigsaw puzzle whose pieces do not quite fit.” 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 and hard about whether to grant computer programs copyright protection. 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 that copyright “should not grant anyone more economic power than is necessary to achieve the incentive to create.” Id., at 12. And it believed that copyright’s existing doctrines (e.g., fair use), applied by courts on a case-by-case basis, could prevent holders from using copyright to stifle innovation. Ibid. (“Relatively few changes in the Copyright Act of 1976 are required to attain these objectives”). Congress then wrote 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. It can help to distinguish among technologies. It can distinguish between expressive and functional features of computer code where those features are mixed. It can focus on the legitimate need to provide incentives to produce copyrighted material while examining the extent to which yet further protection creates unrelated or illegitimate harms in other markets or to the development of other products. In a word, it can carry out its basic purpose of providing a context-based check that can help to keep a copyright monopoly within its lawful bounds. See H. R. Rep. No. 94– 1476, pp. 65–66 (1976) (explaining that courts are to “adapt the 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 use in the context of copying to preserve compatibility); Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F. 3d 596, 603–608 (CA9 2000) (applying fair use to intermediate copying necessary to reverse engineer access to unprotected functional elements within a program); Sega Enterprises Ltd. v. Accolade, Inc., 977 F. 2d 1510, 1521–1527 (CA9 1992) (holding that wholesale copying of copyrighted code as a preliminary step to develop a competing product was a fair 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 have shielded computer programs from the ordinary application of copyright’s limiting doctrines in this way. By defining computer programs in §101, Congress chose to place this subject 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 to “prepare derivative works.” 17 U. S. C. §106. But that also means that exclusive rights in computer programs are limited like any other works. Just as fair use distinguishes among books and films, which are indisputably subjects of copyright, so too must it draw lines among computer programs. And just as fair use takes account of the market in which scripts and paintings are bought and sold, so too must it consider the realities of how technological works are created 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’s method calls) embodies a different kind of creativity. Sun Java’s creators, for example, tried to find declaring code names that would prove intuitively easy to remember. Id., at 211. They wanted to attract programmers who would learn 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 way that is intuitive and understandable to developers so that they 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 declaratory code and the innovative implementing code....
These features mean that, as part of a user interface, the declaring code differs to some degree from the mine run of computer programs. Like other computer programs, it 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) Sun-related implementing programs that Google did not copy.
Although copyrights protect many different kinds of writing, Leval 1116, we have emphasized the need to “recogni[ze] that some works are closer to the core of [copyright] than others,” Campbell, 510 U. S., at 586. In our view, 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. That fact diminishes the fear, expressed by both the dissent and the Federal Circuit, that application of “fair use” here would seriously undermine the general copyright protection that Congress provided for computer programs. And it means that this factor, “the nature of the copyrighted work,” 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 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. 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 of Science 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 that copying was not commercial in nature tips the scales in favor of fair use. But the inverse is not necessarily true, as many common fair uses are indisputably commercial. For instance, the text of §107 includes examples like “news reporting,” which is often done for commercial profit. So even though Google’s use was a commercial endeavor—a fact no party disputed, see 886 F. 3d, at 1197—that is not dispositive of the first factor, particularly in light of the inherently transformative role that the reimplementation played in the 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 fair use analysis. 510 U. S., at 585, n. 18. We find this skepticism justifiable, as “[c]opyright is not a privilege reserved for the well-behaved.” Leval 1126. We have no occasion here to say whether good faith is as a general matter a helpful inquiry. We simply note that given the strength of the other factors pointing toward fair use and the jury finding in 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 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. Further, Google’s basic purpose was to create a different task-related system for a different computing environment (smartphones) and to create a platform—the Android platform—that would help achieve and popularize that objective. 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. Supra, at 25–26; see Campbell, 510 U. S., at 586–587 (explaining that the factor three “enquiry will harken back to the first of the statutory factors, for . . . the extent of permissible copying varies with the purpose and character of the use”).
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.
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 the Sun Java API, to allow enforcement of Oracle’s copyright here would risk harm to the public. Given the costs and difficulties of producing alternative APIs with similar appeal to programmers, allowing enforcement here would make of the Sun Java API’s declaring code a lock limiting the future creativity of new programs. Oracle alone would hold the key. The result could well prove highly profitable to Oracle (or other firms holding a copyright in computer interfaces). But those profits could well flow from creative improvements, new applications, and new uses developed by users who have learned to work with that interface. To that 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 Development Corp., 49 F. 3d, at 820 (Boudin, J., concurring). In doing so here, we have not changed the nature of those concepts. We do not overturn or modify our earlier cases involving fair use—cases, for example, that involve “knockoff ” products, journalistic writings, and parodies. Rather, we here recognize that application of a copyright doctrine such as fair use has long proved a cooperative effort of Legislatures and courts, and that Congress, in our view, intended that it so continue. As such, we have looked to the principles set forth in the fair use statute, §107, and set forth in our earlier cases, and applied them to this different kind of copyrighted work.
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 will help others “create new products.” Ibid; accord, ante, at 26 (Google’s copying “can further the development of computer programs”).
That new definition eviscerates copyright. A movie studio that converts a book into a film without permission not only creates a new product (the film) but enables others to “create products”—film reviews, merchandise, YouTube highlight reels, late night television interviews, and the like. Nearly every computer program, once copied, can be used to create new products. Surely the majority would not say that an author can pirate the next version of Microsoft Word 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 is quantitatively 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 what made 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.
Filed Under: api, apis, clarence thomas, copyright, declaring code, fair use, java, java apis, stephen breyer
Companies: google, oracle, sun
