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
