Oracle has filed its appeal brief [PDF] in Oracle v. Google with the Court of Appeals for the Federal Circuit. I have it for you. Google must file its reply by March 28, according to the docket.
Guess how many lawyers are listed on the brief for Oracle? Twenty-eight: 6 from Boies Schiller, 5 from Kirkland & Ellis, 10 from Morrison & Foerster, and 7 from Orrick, Herrington. I'm assuming Oracle cares about the outcome plenty. You won't believe how the Introduction opens:
Ann Droid wants to publish a bestseller. So she sits down with an advance copy of Harry Potter and the Order of the Phoenix—the fifth book—and proceeds to transcribe. She verbatim copies all the chapter titles—from Chapter 1 (“Dudley Demented”) to Chapter 38 (“The Second War Begins”). She copies verbatim the topic sentences of each paragraph, starting from the first (highly descriptive) one and continuing, in order, to the last, simple one (“Harry nodded.”). She then paraphrases the rest of each paragraph. She rushes the competing version to press before the original under the title: Ann Droid’s Harry Potter 5.0. The knockoff flies off the shelves. J.K. Rowling sues for copyright infringement. Ann’s defenses: “But I wrote most of the words from scratch. Besides, this was fair use, because I copied only the portions necessary to tap into the Harry Potter fan base.” Yes. Ann Droid. You know what's wrong with this Introduction? Software is not a novel. The copyright rules are not identical. Duh. And that's not an accurate or fair description of what Google did. I'd expect them to say that to a jury, not the Federal Circuit.
Obviously, the defenses would fail.
Defendant Google Inc. has copied a blockbuster literary work just as surely, and as improperly, as Ann Droid—and has offered the same defenses.
02/11/2013 - 42 - BRIEF TENDERED from Appellant Oracle America, Inc.. Title: Opening Brief and Addendum of Plaintiff-Appellant. Service: 02/11/2013 by email. 
Oracle doesn't agree that the rules are different:
02/11/2013 - 43 - BRIEF FILED for Appellant Oracle America, Inc. . Title: Opening Brief and Addendum of Plaintiff - Appellant, [Non-Confidential version only]. Number of Pages: 77. Service: 02/11/2013 by email. Pursuant to ECF-10, filer is directed to file six copies of the brief in paper format. The paper copies of the brief should be received by the court on or before 02/19/2013. Cross-Appellant Google Inc. brief is due 03/28/2013. 
The court saw this software as just different. It believed that each line of source code Google copied is an unprotectable “method of operation,” 17 U.S.C. § 102(b), because it is just a command to carry out a pre-assigned function. However, if you read the Atari case, you will see for yourself the difference between software and novels, because the opinion explains in great detail that with software, first you have to strip out unprotectable elements of the software before you can look at copyright-covered elements. Nothing like that happens with novels. And note too that Atari wasn't about APIs. It was a reverse engineering case, about software programs.
This notion of software exceptionalism for any code is wrong. Congress chose to protect computer programs under copyright law. As this Court recognized in Atari Games Corp. v. Nintendo of America, Inc., 975 F.2d 832 (1992), software code is protectable expression because authors select and arrange lines of source code in an original way. Id. at 838. Under Atari, copyright law recognizes no difference between original expression embodied in the topic sentences or organization of Harry Potter and original expression embodied in like features in software. This Court should reverse the district court’s basic legal error.
Here's Atari Games v. Nintendo, so you can see what you think for yourself. But here's what I notice is not protected by copyright:
Under the Act, society is free to exploit facts, ideas, processes, or methods of operation in a copyrighted work. To protect processes or methods of operation, a creator must look to patent laws. It's there in black and white that methods of operation are not protected by copyright. So what is Oracle thinking? That the judges aren't familiar with the details of Atari? Chief Judge Randall Rader wrote the Federal Circuit's decision. So that can't be it.
I think it would be more accurate to say the Oracle would like to change the law now so APIs -- nay, their very arrangement -- is as protected as Harry Potter, not that the judge in the district court made an error of law.
How much can you do without permission with Harry Potter? That's right. Virtually nothing. Maybe in a review you could quote a little bit. But software isn't just expression. It's expression, yes, but it has to run, to do something. You don't just read software, as you would a novel. The computer runs it, and that means others have to be able to interact with your software somehow. Oracle, to its shame, would like all its software, including methods of operation like APIs -- which are how you interact with someone's software -- to be as proprietarily frozen and forbidden as that. Here's why the Atari decision says that isn't a good idea, providing the context for that passage:
The author does not acquire exclusive rights to a literary work in its entirety. Under the Act, society is free to exploit facts, ideas, processes, or methods of operation in a copyrighted work. See, e.g., Feist, --- U.S. at ----, 111 S.Ct. at 1289-90. To protect processes or methods of operation, a creator must look to patent laws. See Bonito Boats v. Thunder Craft Boats, 489 U.S. 141, 109 S.Ct. 971, 103 L.Ed.2d 118 (1989); Arrhythmia Research, 958 F.2d at 1053; see also The Law & Business of Computer Software, § 2.07 (D.C. Toedt III ed. 1991). An author cannot acquire patent-like protection by putting an idea, process, or method of operation in an unintelligible format and asserting copyright infringement against those who try to understand that idea, process, or method of operation. See, e.g., Feist, --- U.S. at ----, 111 S.Ct. at 1290; 17 U.S.C. § 102(b). The Copyright Act permits an individual in rightful possession of a copy of a work to undertake necessary efforts to understand the work's ideas, processes, and methods of operation.
I seem to be doomed to spend my life arguing with David Boies, one of the lawyers whose name appears on this piece of work.
This permission appears in the fair use exception to copyright exclusivity. Section 107 of the Copyright Act states that "fair use of a copyrighted work, including such use by reproduction in copies ... for purposes such as criticism, comment, news reporting, teaching ... scholarship or research" is not infringement. 17 U.S.C. § 107. The legislative history of section 107 suggests that courts should adapt the fair use exception to accommodate new technological innovations. H.R.Rep. No. 1476, 94th Cong., 2d Sess. 66 (1976), reprinted in U.S.C.C.A.N. 5659, 5679-80; 17 U.S.C. § 107; see also Twentieth Century, 422 U.S. at 156, 95 S.Ct. at 2044 ("When technological change has rendered its literal terms ambiguous, the Copyright Act must be construed in light of [its] basic purpose.").
Thus, the Act exempts from copyright protection reproductions for "criticism, comment ... or research." These activities permit public understanding and dissemination of the ideas, processes, and methods of operation in a work:
The copyright holder has a property interest in preventing others from reaping the fruits of his labor, not in preventing the authors and thinkers of the future from making use of, or building upon, his advances. The process of creation is often an incremental one, and advances building on past developments are far more common than radical new concepts. See Lewis Galoob Toys, Inc. v. Nintendo, 964 F.2d 965 (9th Cir.1992). Where the infringement is small in relation to the new work created, the fair user is profiting largely from his own creative efforts rather than free-riding on another's work. A prohibition on all copying whatsoever would stifle the free flow of ideas without serving any legitimate interest of the copyright holder.
Oracle isn't appealing its patent loss in this case, only the copyright losses. So, I'm puzzled why this appeal goes to the Federal Circuit.
[ Update 2: I had a chance to ask a lawyer, and here's the answer: whatever the case is when it starts decides whether it goes to the Federal Circuit. It isn't parsed out later. Here's the rule on jurisdiction and the Federal Circuit. What was confusing me was why the Microsoft v. Motorola appeal did not go to the Federal Circuit, since it's all about patents. He pointed me to this paragraph in the ruling by the Ninth Circuit Court of Appeals on why they had jurisdiction:
"Not all cases involving a patent-law claim fall within the Federal Circuit's jurisdiction." Holmes Group, Inc. v. Vornado Air Circulation Sys., Inc., 535 U.S. 826, 834, 122 S.Ct. 1889, 153 L.Ed.2d 13 (2002). The Federal Circuit has jurisdiction over an interlocutory appeal only if it would have jurisdiction over a final appeal in the case under 28 U.S.C. § 1295. 28 U.S.C. § 1292(c)(1). Microsoft's complaint sounds in contract and invokes the district court's diversity jurisdiction under 28 U.S.C. § 1332. We therefore have jurisdiction over this interlocutory appeal under 28 U.S.C. § 1292(a)(1). Interlocutory appeal means the case isn't done yet, but they are appealing an issue beforehand, and here's the rule on jurisdiction on that. So, the point is, usually whatever kind of case it is in a well-pled complaint, that's the deciding factor. And when Oracle began, it was a patent/copyright case, and when it's mixed, patents trump and it goes to the Federal Circuit who decide the mixed bag, applying whatever the law is in the circuit the case came from on all non-patent issues mixed in with the patent issues. So that's the answer. Here's a panel discussion on patents jurisdiction that SCOTUSblog has posted for those of us who are hard-core interested in jurisdiction. To follow it, you need this case, Gunn v. Minton, and here's 28 US Code Section 1338(a).] - End Update 2.]
[ Update 3: Dan Levine's article for Reuters lists a date for Google to file as being May. I heard from Florian Mueller saying he thought I was wrong to list March as the filing deadline. I always appreciate corrections, but after investigating, here's why I disagree.
He pointed to a motion by Oracle asking for more time, #33 on the docket [PDF], which he believed would give Google the equivalent extra time.
It's true that the motion says if Oracle was granted extra time, which
it was [PDF] in this order, it would not oppose Google getting an extension to match. He believed that this meant that when Oracle's motion was granted, it was automatic that Google got one too. Not so. Notice that in the motion, it says in the first paragraph that to get an equivalent extension, Google would have to present
a motion asking for it, but that if it did, Oracle agreed not to oppose it. Google is free to file such a motion, but it hasn't yet done so. And that is why, if you read the order, it says that only Oracle gets the extension, and in the clerk's notation on docket about Oracle filing its brief, it lists the March date, not a May date. Google may yet file such a motion, of course, and if it does, I'll let you know. But that is why I believe Reuters report was inaccurate. - End Update 3.]
I'll work on a text version for you. The whole thing is over 200 pages, with the addendum materials, but I'll do the brief itself, which is only 90.
Here is the brief as text, beginning at the Introduction, to the end, minus the opening and the addendum, which you can get from the PDF:
Ann Droid wants to publish a bestseller. So she sits down with an advance copy of Harry Potter and the Order of the Phoenix—the fifth book—and proceeds to transcribe. She verbatim copies all the chapter titles—from Chapter 1 (“Dudley Demented”) to Chapter 38 (“The Second War Begins”). She copies verbatim the topic sentences of each paragraph, starting from the first (highly descriptive) one and continuing, in order, to the last, simple one (“Harry nodded.”). She then paraphrases the rest of each paragraph. She rushes the competing version to press before the original under the title: Ann Droid’s Harry Potter 5.0. The knockoff flies off the shelves.
J.K. Rowling sues for copyright infringement. Ann’s defenses: “But I wrote most of the words from scratch. Besides, this was fair use, because I copied only the portions necessary to tap into the Harry Potter fan base.”
Obviously, the defenses would fail.
Defendant Google Inc. has copied a blockbuster literary work just as surely, and as improperly, as Ann Droid—and has offered the same defenses. The work was authored by software developers at Sun
Microsystems, Inc., now Oracle America, Inc.1
Sun’s developers spent years refining, writing, organizing, and promoting packages of computer source code to help outside application (“app”) programmers write new computer programs in the Java language faster and more efficiently by just incorporating the packages into their own Java programs. The packages were wildly popular, largely because they were written and organized in a way that made intuitive sense. A community of millions of application programmers coalesced around them. But everyone— IBM, Sony, Cisco, Red Hat, and others—understood that no one was allowed to use the packages without a license from Sun/Oracle.
Enter Google. Google was late to the smartphone market. Google’s top brass was desperate to develop its own mobile platform: Android. They concluded that the platform needed to include Sun’s popular Java packages. As one email to Google executives indelicately put it, the alternatives “all suck[ed].” A1168.
Google executives agreed that they “[m]ust take a license from Sun,” A1132, because “[S]un ... own[s] the brand and the IP,” A1200-01. But Google rejected the key terms that every other licensee accepted. Then, it just copied Sun’s work. Google admits that it literally copied into Android thousands of lines of original Sun/Oracle source code. The code Google copied embodied the elements and the detailed, complex structure and design of 37 packages of code, essentially the chapter and subchapter headings and the topic sentences from those packages—all copied verbatim. Google then paraphrased the rest.
The copying enabled Google to rush Android to market. It also made Android instantly familiar to the programming community Sun fostered. So millions of programmers who came of age on Sun’s Java source code, nomenclature, and organization eagerly wrote apps for Android. That helped make Android a phenomenal commercial success.
Had Google done exactly the same thing with a novel or a symphony, there would be no doubt that it copied protectable expression—both as to the large volume of work copied and the work’s organization. Copyright protects a short poem or even a Chinese menu or jingle. But the copied works here were vastly more original, creative,
and labor-intensive. Nevertheless, the district court stripped them of all copyright protection. The court saw this software as just different. It believed that each line of source code Google copied is an unprotectable “method of operation,” 17 U.S.C. § 102(b), because it is just a command to carry out a pre-assigned function.
This notion of software exceptionalism for any code is wrong. Congress chose to protect computer programs under copyright law. As this Court recognized in Atari Games Corp. v. Nintendo of America, Inc., 975 F.2d 832 (1992), software code is protectable expression because authors select and arrange lines of source code in an original way. Id. at 838. Under Atari, copyright law recognizes no difference between original expression embodied in the topic sentences or organization of Harry Potter and original expression embodied in like features in software. This Court should reverse the district court’s basic legal error.
But this Court should go a step further and reject Google’s fair-use defense as a matter of law. A commercial competitor may not copy verbatim crucial features of another’s expression, depriving the original author of a potential market for the work. Google copied the source
code upon which programmers most rely, incorporated that code into a competing mobile platform, and competed directly with Oracle which was already profiting from licensing the packages for mobile devices. That is decidedly unfair.
If, as the Supreme Court explained, “the best way to advance public welfare” is to “encourage” authors to engage in “individual effort by” offering them “personal gain,” Mazer v. Stein, 347 U.S. 201, 219 (1954); see U.S. Const. art. I, § 8, the principle applies at least as much to software as to novels and Chinese menus. Oracle would never have revolutionized the computer world if it knew up front that a court would find that “the public w[as] and remain[s] free to” co-opt its work for financial gain. A165. J.K. Rowling does not write blockbusters for everyone to knock off. Neither will innovators like Oracle.
The district court had jurisdiction under 28 U.S.C. §§ 1331, 1338(a), and entered final judgment on June 20, 2012. A171-72. The parties moved for judgment as a matter of law or, alternatively, a new trial. A1077-111, 1112-18. The court denied the final post-trial motion on September 4, 2012. A1119. Oracle timely appealed on October 3,
2012, and Google cross-appealed. A1120-23; Fed. R. App. P. 4(a)(1)(A), 4(a)(4)(A)(i). Because this action included patent claims, infra at 29 n.3, this Court has jurisdiction under 28 U.S.C. § 1295(a)(1).
STATEMENT OF THE ISSUES
1. Google copied thousands of lines of Oracle source code arranged in a manner that users find attractive. The district court found the code and the structure and organization it embodied original and creative. Does the Copyright Act protect the expression that Google copied?
2. Google inserted the code it copied (and the corresponding structure) into a commercial product in a market where Oracle was already competing. Does Google’s fair-use defense fail as a matter of law?
STATEMENT OF THE CASE
Oracle sued Google in the U.S. District Court for the Northern District of California, alleging that Google’s Android mobile operating system infringed Oracle’s copyrights and patents. A336-47, 524-35. The jury found no patent infringement. A1069-70. But the jury found that Google infringed Oracle’s copyright in the packages and a specific
computer routine (called “rangeCheck”). A41-43. The jury hung on Google’s fair-use defense. Id. Thereafter, the district court ruled that the infringed code and organization of the 37 packages were devoid of copyright protection. A163-70. It also denied Oracle’s motion for judgment as a matter of law on fair use. A129.
STATEMENT OF FACTS
Sun Revolutionizes Computer Programming With Java And Its
Packages Of Prewritten Programs
For years, computer programmers had to pick one platform when writing new programs. A20,463, 20,529-31. Computer giants like Apple and Microsoft had developed their own versions of programming languages. Thus, “when you wrote a program for [a] Microsoft Windows computer, that program would not run on ... an Apple MacIntosh computer.” A20,463. “So if you want something that ran on Windows and ... Apple ... , you would have to write that program twice.” Id.; accord A20,529-31.
Sun developers changed all that with the Java platform. Released in 1996, a distinguishing feature of the Java platform is the “virtual
machine,” which allows programmers “to write programs that ... run on different types of computer hardware without having to rewrite them.” A133. A programmer could now write a program once and it would run on any device with a Java virtual machine regardless of operating system. A20,549, 20,676-77. “Write once, run anywhere” became Java’s credo. A20,888-89, 20,463-64, 22,132.
Sun developers wrote a vast array of Java programs to perform often-needed functions and organized those programs into “packages.” A134, 139. Each package is arranged in an intricate hierarchy (more on that below) and consists of numerous modules of “tried-and-true pre-packaged programs” comprising a vast arrangement of functions. A141. These packages were a huge benefit to programmers writing apps for all sorts of devices. Whatever the problem, the programmer does not have to “re-invent the wheel” to write a solution. Id. The parties and the district court often called these software packages “APIs.”
TERMINOLOGY CLARIFICATION: “API,” which stands for “application programming interface,” is confusing because it is a verbal chameleon. It can describe a trivial communication protocol to pass information between programs. Or it can describe sophisticated computer programs, like the ones Sun wrote. Even in this case, the parties and court confusingly applied the same label to describe both the entire set of Java packages, see, e.g., A131-32, 134-36, and a single package of Java source code, see, e.g., A131-32, 167-68. To avoid confusion, we refer more precisely to what we are describing: a “package” or “packages” of source code.
Also, for ease of reference, this brief uses the term “developers” for software engineers who write new code for the Java platform and its packages, and “programmers” for those who use the Java packages to write new apps.
By way of illustration, in one package, Sun developers wrote a program called “URLConnection” to establish an internet connection (e.g., to a bank or store website). A10,013-28; 20,753-54. As simple as that sounds, it is exceedingly complex. Developers needed special expertise to write the network protocol and cryptographic algorithms. Once they did their work, a programmer wishing to write a program that connects to, say, BankofAmerica.com, could either (1) reinvent the wheel, writing his own algorithms or (2) simply “declare”—i.e., type— “new URL(‘http://bankofamerica.com’).openConnection()” in the program, which calls on Sun’s prewritten code. If the programmer used
the feature frequently, he would not bother looking it up, since using the package would become second nature. A20,937-38. Apropos of the terminology clarification, URLConnection is a computer program, not some trivial communication protocol between programs.
Every package consists of two related types of Java source code. First, each component in a package begins with one or more lines of code including, among other things, a description of the function, such as “public URLConnection openConnection() throws java.io. IOException.” Also, this code reflects the component’s place in the package hierarchy. A133, 136-39. The similar code that the programmer declares in order to invoke the prewritten program is: “URL(String spec).openConnection().” These lines of code are called declarations, headers, signatures, or names (depending on various factors not relevant here). In the interest of brevity, we call them all “declaring code” or simply “declarations.” The second type of code tells the computer how to perform the declared function. A133, 137-39. In the illustration above, this second category encompasses the lines of code opening the internet connection. Consistent with the district court’s terminology, we call them “implementing code.” A163.
As is evident from this description, a programmer does not have to invoke these packages to write a program in the Java language, any more than an avid networker must use Hallmark’s prewritten greetings to write to friends on special occasions. A20,458-59. The packages are shortcuts. With only a few minor exceptions (portions of three packages), programmers can write in Java without using the packages. A140-41, 20,946-49. Indeed, programmers not satisfied with the existing packages can create their own packages in the Java language with similar—or completely different—functionality. A22,388-89. Sun specified how the code in the packages works in the Java API Specification, a massive-40,000 page manual that details the Java declaring code and its hierarchical arrangement. A20,710-11, 20,775, 21,422-24. The Specification also describes the structure and organization of each package, its elements and their relationships, and how each element and package works. A20,754-55, 20,710-102. It “exactly” mirrors the declaring code in the package, including its structure and organization. A20,775-77.
Writing A Java Package Is An Iterative And Creative Exercise
The original Java Standard Edition Platform (“Java SE”) had “eight packages of pre-written programs.” A140. When Google began its copying in 2005, Java SE 5.0 had 166 packages. A141. It now contains 209. A20,766.
Writing any of these packages is an iterative and creative process. It took Sun’s “most senior[,] experienced and talented” developers years to write some of them. A20,459; see A20,791, 20,921. Much of the creativity lies in determining what to include in the packages and how to organize the declaring code in a way that programmers using the packages in their own apps will find appealing and intuitive. The process usually begins as a “high level exercise.” A20,790. Sun/Oracle developers identify areas of need in the Java programming community for new or different functions. A20,790, 21,410. Suggestions also come through the Java Executive Committee—Java’s governing body, composed of Oracle and its competitors like IBM and Google. A20,790-96, 20,471. Sun/Oracle developers then organize a “high level summary of ... a possible structure” for the package. A20,790-91; see A20,913. They wrestle with what functions to include in the package,
which to put in other packages, and which to omit entirely. Id. They send sketches “around to get comments from [their] colleagues,” and may “revise th[eir] design” based on “feedback.” A20,791. The developers work with a “clean slate,” A21,412; accord A20,913, so ex ante, their options are infinite.
Sun/Oracle invested hundreds of millions of dollars in these
labors. A20,454, 20,557. Sun registered Java SE—including all the
packages—with the Copyright Office. A1066, 2342-99, 2400-25,
2520-24, 5908-12; Supp. App’x Ex. 1076. It also invested millions in
teaching a community of programmers how to use those packages.
A20,557, 21,438-39. So, when Java programmers see
“URL.openConnection(),” they instantly conjure “creating an internet
connection,” just as surely as fans who see “Hermione Granger,”
instantly think, “brainy, fearless Harry Potter sidekick.”
Sun Develops A Licensing Regime To Foster A Community And
Although Oracle owns the copyright on Java SE and the corresponding packages, Oracle encourages their use by others—both a vast community of programmers writing clever apps and businesses
developing proprietary and competing products. To accommodate all comers, Sun/Oracle offers three different licenses:
(1) The General Public License (“GPL”) is free of charge, but subject to a strict—and legally binding—obligation: Licensees may use the packages (both declaring code and implementing code), but must “contribute back” the new work. It is called an “open source” license, not because it is open for all to use unconditionally, but because the licensee must expose his innovations publicly. A20,460, 20,537, 21,923-24.
Both the Specification and Commercial Licenses require that licensees’ programs pass a series of tests that ensure compatibility with the Java platform. A21,242, 21,226, 22,230. This compatibility requirement enforces adherence to Java’s critical “write once, run anywhere” principle. A133, 167, 20,549.
(2) The Specification License, unlike the GPL, does not permit the licensee to use the full Java source code. A20,469-70. Rather, the licensee can use only the Specification—which, as explained, recites the declaring code. So, a Specification Licensee may write packages using the familiar declaring code and organization of the Sun/Oracle packages but must write its own implementing code. A20,461-63.
(3) The Commercial License is for businesses that want to use and customize the full Java code in their commercial products and keep their code secret. Oracle offers a Commercial License in return for royalties. A21,225-26, 21,242.
Sun/Oracle’s investments in user-friendly, efficient, and intuitive source-code packages, combined with flexible licensing options, attracted millions of programmers to Java’s “write once, run anywhere” platform, A133, 167, 20,549, 20,688, and made Java “one of the world’s most popular programming languages and platforms,” A133. Corporations like Sony, Cisco, and General Electric, all took Commercial Licenses for software packages, A20,550-51, and IBM, SAP, and Oracle (before purchasing Sun), all took Specification Licenses, A20,46-67—each maintaining compatibility with the Java platform.
Even before the smartphone market exploded, Sun was licensing and profiting from a derivative version of the Java platform for use on mobile devices, called Java Micro Edition (“Java ME”). A20,889. Oracle licensed Java ME for use on feature phones and smartphones. A20,468, 20,551-52, 21,273, 21,658, 22,097. “[J]ust about every smart phone carrier ... around the world” used Java ME, A22,237, including Research in Motion in Blackberries, Danger in Sidekicks, Cisco in several of its systems, and Nokia in Series 60 devices, A20,551-52, 21,273, 21,760, 22,097. The royalties from these licenses were “very lucrative” and “quite valuable.” A22,237.
As is evident from those client lists, Sun/Oracle—a significant force in personal computers, servers, and web-based applications, A133, 141—was already a strong presence in mobile devices and poised to be a major force in smartphones, A22,237.
Until Google entered the picture.
Google Is Desperate To Include Certain Java Packages In The
The Google juggernaut rests on a grand bargain. A21,631. Google, famously, does not directly charge users. Instead, Google collects information about its users and makes money selling advertising targeted at them. Advertisers pay large sums for that targeting. A7898, 7902-04, 7916-18, 7922, 7979.
Since its founding in 1998, practically every penny of Google’s enormous revenue was tied to personal computers. A7898. By 2005, however, Google faced a grave threat. Increasingly, consumers were searching the internet from mobile devices rather than personal computers. A7959. But Google’s products were not optimized for mobile search. Id. Google was desperate to extend its market dominance to mobile search. As Google’s 10-K reported: Without quick action, Google would “fail to capture significant share of an increasingly
important portion of the market for online services.” Id.; A20,657-58, 21,631, 22,018.
Google set out to “build an Open Source handset solution with built-in Google applications.” A2026. Its strategy was to work with wireless carriers and manufacturers to incorporate a Google mobile operating system into handset designs. A1128. So, in 2005, Google acquired Android, Inc., which was developing a mobile software platform. A134.
Google could have tried to develop its operating system from scratch as Apple, Microsoft, and so many other technology companies have. But there were two problems. First, this had to be done yesterday. Designing a new operating system from scratch with its own array of pre-written software packages would take years. Second, Google executives understood that Android would rise or fall on “build[ing] a community force around Google handset APIs and applications.” A1148; see A21,627-30. That was because consumers choose smartphones over conventional cell phones mainly for the apps. Google needed immediate access to a community of independent programmers to write for Android all the useful, quirky, and
entertaining apps that users craved, from Solitaire to mobile banking to social networking. A1148, 21,627-30. But a community of loyal supporters does not coalesce overnight.
The only way for Google to get the technical and community-
building jobs done quickly was to hitch its wagon to the Java platform.
A21,890. Google’s internal documents detail why the prewritten Java
packages were “[c]ritical” to Google’s shortcut “strategy.” A1187,
1200-01. If Google could “[l]everage Java for its existing base of
[programmers],” it would not need to educate new programmers on a
whole new body of declaring code. A2033. The familiar packages would
expedite development of Android and its apps, id.; A2092, 21,627-28,
21,630-31, which, in turn, would “[d]ramatically accelerate [Google’s]
schedule,” A1187; see 21,636.
Google Acknowledges It Needs A License But Wants To Defy
“Write Once, Run Anywhere”
Google was fully aware that no one could use Sun’s software packages—or even just the declaring code that Specification Licensees use—without a license. Several former Sun engineers at Google were steeped in Sun’s licensing regime and knew how much effort and creativity went into designing each package. They were aware of the
many companies that took Specification Licenses to use the declaring code and write their own implementing code. See, e.g., A20,902-03, 20,906. Accordingly, Google never doubted it needed a license for Sun’s packages. Andy Rubin, the head of Google’s mobile efforts, conceded: Java “apis [sic] are copyrighted” and “I don’t see how you can open [J]ava without [S]un, since they own the brand and the IP.” A1200-01. Google “[m]ust take [a] license from Sun,” the Android team insisted in a presentation to top Google executives. A1132. It was “critical.” A1199. Even five years later, with litigation imminent, Google still knew it needed a license. Google cofounders ordered its engineers to investigate alternatives to using Sun’s packages. A1168. A former Sun engineer, A21,009, tasked to investigate responded bluntly: The alternatives “all suck.” A1168. “We need to negotiate a license for Java.” Id.
In keeping with Google’s understanding of the legalities, “[i]n late 2005, Google began discussing with Sun the possibility of ... a license.” A135. At no point in the ensuing five years did Google so much as suggest that it did not need a license. Instead, Google proposed a “custom” deal, A2837, 21,779—a “co-development partnership” or
“license to use and to adapt the entire Java platform for mobile devices,” A135. The parties reached an impasse. Id. The sticking point was Google’s insistence on terms that were anathema to “write once, run anywhere” A2837, 21,779, terms that Sun/Oracle denied all other licensees. Google wanted to be the only company ever allowed to use the Java packages commercially without making its implementation compatible with the Java virtual machine and therefore interoperable with other Java programs. A20,561-63, 22,233-35.
This was a nonstarter for Oracle. A20,561-63. When the parties
reached an impasse, Android’s chief advised Google executives: “If Sun
doesn’t want to work with us, we have two options: 1) Abandon our
work ... or 2) Do Java anyway and defend our decision, perhaps making
enemies along the way.” A1166. Google elected option 2.
Google Copies Verbatim The Declaring Code In 37 Java
Google wrote some of its own packages for Android in the Java language. Nothing wrong with that. What is objectionable is Google’s copying of portions of Sun’s packages. Google cherry-picked “the good stuff from Java,” A5874—the 37 packages that it “believed Java [programmers] would want to find ... in the new Android system
Packages Into Android
callable by the same names as used in Java.” A135; accord A21,503, 21,957-59 (the significance of the stolen 37 packages is “huge”). As to those 37 packages, Google admits it copied verbatim virtually all of Sun’s declaring source code, thereby replicating the entire detailed structure of each package, and then paraphrased the implementing code. A136, 976-97, 22,771-73. Google did what other businesses that took a Specification License to do—but without the requisite compatibility. A20, 461-63.
What Google copied. We illustrate pictorially what Google copied, below. Some technical jargon is necessary to appreciate the extent and significance of Google’s copying: Every Java package is arranged in a hierarchy and divided into related “classes” of defined source code files; classes contain numerous “methods”; each method performs a discrete function, A137-39, such as opening an internet connection, supra at 9-10.
Figure 1, below, represents a high-level schematic of a single package, java.io. A5730. Java.io generally manages system inputs and outputs. A10,029-33. Arrayed on the left are the numerous classes. Each relates to the overall input/output theme, ranging from
InputStreamReader (which translates data streams into human-readable text) to Writer (which enables devices to write streams of characters). Id. The classes are arranged in a hierarchy of their own. Classes can contain subclasses, which in turn can contain sub-subclasses, and so on. Figure 1 indicates that hierarchy by indentation.
Google copied the declaring code in the java.io package, including the classes shown in Figure 1. Figure 1 does not, however, show all the methods—569 of them, distributed among approximately 50 classes. SeeA1065. The InputStreamReader class, for example, has five methods, ranging from “read” (which reads a single character) to “ready” (which signals whether the stream is ready to read). A10,034-38. Other classes in java.io encompass between three and 39 methods. Google copied verbatim declaring code for all those methods, too.
Figure 1. High-Level Schematic of a Package.
Figure 2, below, begins to portray the intricacy of the work Google copied at the method level. (We use a simpler package, java.security, because java.io’s 569 methods cannot fit on one page.) Arrayed on the left are the class names (with subclasses indented down to sub-sub-sub-subclass). On the right is a layout of the methods. Each of the almost imperceptibly thin lines represents a method—362 in all—each of which begins with one or more lines of declaring code. Google copied verbatim the declaring code for the java.security methods.
We say Figure 2 begins to portray the intricacy, because it leaves out important detail. The declaring code that defines a method or class includes more information than just its name and function. A137-38. Most include “parameters,” which define its operation (e.g., “5” directs java.io.StringReader.skip to skip the next five characters); “exceptions” (e.g., “Here’s the type of error you must be prepared to handle”); and “fields,” which hold data values (e.g., pi). A138, 140. Figures 1 and 2 do not convey this information.
Figure 2. Schematic of a Package Including Methods
Moreover, the structure of the packages is not simply linear or purely hierarchical. A true schematic would be three dimensional, with an intricate web of interconnections. Imagine each colored grouping of lines in Figure 2 as the floor plan of one story in a 50-story building. Imagine a web of chutes and ladders connecting some floors to others and even to other buildings, representing other packages. Those connections are “interfaces” (not to be confused with interfaces associated with “API,” supra at 9), which group classes sharing similar characteristics. Figure 1 indicates interfaces in italics on the right: the lines connecting one class to another, both in this package and in other packages. A5730 (illustrating the latter interfaces with an accompanying icon); see A139 (explaining the difference between classes and interfaces). There are many other types of relationships, some of which transcend package and class. A20,770, 21,391, 21,411-12.
So far, the description of Google’s copying (assisted by Figures 1 and 2) has focused on individual packages. Now multiply by 37. The 37
packages Google copied from Oracle contain 677 classes and 6508 methods—totaling at least 7000 lines of declaring code. A1065.2
Google admits that it copied all of this declaring source code verbatim—thousands of specific package, class, and method declarations; the definitions and parameters; and the exceptions. A136. Because declaring code identifies, specifies, and defines the components and their arrangement within the packages, when Google copied Java’s declaring code, it also copied the “sequence and organization” of the packages (i.e., the three-dimensional structure with all the chutes and ladders), A984-85, 22,367, 22,771-73. Google’s “Java guru,” A142, conceded (and the district court found, A140-41) that Google did not need to engage in this massive copying in order to design its own platform in the Java language. A20,946-49.
What Google paraphrased. Once it had the declaring code, “do[ing] [the] implementation from scratch is a relatively easier job.”
A22,405-06. Google merely had to “follow th[e] map” laid out in the 40,000-page Specification and “fill in the details” (i.e., implementing code). Id.
Google hired Noser—a foreign contractor that the Android Project director described as “super shady,” A2177, 21,161-62—to help write Android’s implementing code, A2101, 21,858. Google’s programmers admit that they and Noser pored over the Specification as they did their paraphrasing. A21,153-56; see A1724, 21,422-25, 21,925.
Google’s Copying Fragments The Java Community And
Marginalizes Sun/Oracle In The Smartphone Market
As planned, Google released its incompatible Java-based Android system for free. A135. And as expected, Google reaped billions in advertising revenue in connection with searches on mobile devices. A135, 5977. The move hampered Sun/Oracle’s “very lucrative revenue stream” that had attracted “just about every smart phone carrier” to Java. A22,237. As Oracle’s President put it, “It’s pretty hard to compete with free.” A22,498. For example, although Amazon had paid for a Java Commercial License for the Kindle, A20,468, 20,553, the new Amazon Kindle Fire, runs on Android—not Java, A21,192-93, 21,206.
Google’s copying caused the very fragmentation Sun/Oracle strove
to prevent. Even while copying verbatim the declaring code from the 37
packages to attract loyal Java programmers, Google ultimately
designed Android to be incompatible with the Java platform, so that
apps written for one will not work on the other. Infra at 65-66; A2042-
43, 21,503-04; see A21,192-93 (Kindle Fire not compatible). Google
replaced “write once, run anywhere” with “write once, run only on
The Jury Finds Copyright Infringement, But The District Court
Oracle sued Google in 2010. Oracle alleged copyright infringement with respect to the 37 Java packages of source code. A526, 532-33.3
The parties “agreed that the judge would decide ... copyrightability and Google’s equitable defenses and that the jury would decide infringement, fair use, and whether any copying was de minimis.” A131. The court reserved decision on copyrightability until after trial. Id.
Finds No Copyright Protection
“[T]he jury found that Google infringed” “as to the compilable code for the 37 Java API packages.” Id.; accord A41-43. But it deadlocked on fair use. A131. The jury and the court also found that Google infringed nine files, including one called “rangeCheck.” A132, 1058A-B, which is the subject of Google’s cross-appeal.
The district court declined to order a new trial on fair use, because it held that the code and structure Google copied were completely devoid of copyright protection. A170. As to declaring code, the court held that “no matter how creative or imaginative,” “there is only one way to write” it and thus “the merger doctrine bars anyone from claiming exclusive copyright ownership” of it. A164. “Therefore, there can be no copyright violation in using the identical declarations.” Id. It also held that declaring code consists of unprotectable “names and short phrases.” A165.
The court acknowledged that the “structure, sequence and organization” of each package was “creative” and “original.” A166. Nevertheless, it held the structure and organization unprotectable under 17 U.S.C. § 102(b), as “a command structure for a system or method of operation,” A166.
SUMMARY OF ARGUMENT
I. A. Two axioms decide this case. Axiom 1: The Copyright Act’s
threshold for copyright protection is very low. Any “creative spark” counts, “no matter how crude [or] humble.” Feist Publ’ns, Inc. v. Rural Tel. Serv. Co., 499 U.S. 340, 345 (1991) (internal quotation marks omitted). Axiom 2: “[C]opyright protection extends to computer programs,” just as it does to any other literary work. Atari Games Corp. v. Nintendo of Am., Inc., 975 F.2d 832, 838 (Fed. Cir. 1992). The district court’s approach of exempting some software from the standard copyright rules is an assault on both principles.
B. Applying these axioms, the software Google copied is protectable on two independent bases. First, declaring code is protectable because it is expressive—many orders of magnitude more expressive than necessary to overcome the threshold. Google confessed to literal copying—7000 times over. Under this Court’s Atari opinion, the declaring code that Google copied is as protectable as any other literary work because Oracle “exercised creativity in the selection and arrangement of its instruction lines.” 975 F.2d at 840.
Second, the original and creative structure and organization of each package is protectable. This is protected both through the declaring code that embodies it and, independently, through “its ‘nonliteral’ elements, such as the program architecture, ‘structure, sequence and organization’, [and] operational modules.” Eng’g Dynamics, Inc. v. Structural Software, Inc., 26 F.3d 1335, 1341 (5th Cir. 1994) (as corrected). The package developers had infinite options for the structure and organization. They labored to create an organization for complex packages that programmers would find attractive—easy to learn and remember.
C. The district court erred in concluding that each individual line of declaring code is completely unprotected under the “merger” and “short phrases” doctrines. Merger holds that “[w]hen the ‘idea’ and its ‘expression’ are ... inseparable, copying the ‘expression’ will not be barred, since protecting the ‘expression’ in such circumstances would confer a monopoly of the ‘idea.’” Sid & Marty Krofft Television Prods., Inc. v. McDonald’s Corp., 562 F.2d 1157, 1168 (9th Cir. 1977) (citation omitted). Merger cannot apply here because, as the court found, “the Android method and class names could have been different from the
names of their counterparts in Java and still have worked,” A132, and the selection and organization could have been different as well.
The “short phrases” regulation prevents an author from copyrighting “work” consisting of a naked bit of text. It does not wipe out the copyright on an assemblage of 7000 lines of code.
D. The district court also erred in holding that the organization of the packages is devoid of protection as “a command structure, a system or method of operation” under 17 U.S.C. § 102(b). A166. The district court was mistaken. Under § 102(b), copyright protection does not “extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery.” That provision merely codifies the idea-expression dichotomy. The question under § 102(b) is whether “alternate expressions ... are available”—i.e., “a multitude of different ways to” perform a particular function. Atari, 975 F.2d at 840. The district court found: “[T]here were many ways to group the methods yet still duplicate the same range of functionality.” A133.
The court was wrong to hold that no line of declaring code “can receive copyright protection” because they are “commands to carry out pre-assigned functions.” A166-67. Since all software consists of
“commands to carry out pre-assigned functions,” that would mean that no software is protectable.
Equally mistaken was the court’s invocation of “[i]nteroperability.” A167. Interoperability is irrelevant to copyrightability. Copyrightability must be considered ex ante—from the perspective of the original developers of Oracle’s packages, considering what constrained them. What Google felt it needed to provide to programmers years later may bear on whether its subsequent use was fair, but not on copyrightability. In any event, Google’s copying was not about interoperability. Android is downright incompatible with the Java platform.
II. The district court should also have dismissed Google’s fair-use defense as a matter of law. Every factor cuts against fair use.
First, Google’s purpose was purely commercial. It was not transformative. The packages serve the identical purpose in Android as they do in Java. Second, the Java packages are the product of significant creative effort, years of labor, and hundreds of millions of dollars in research and development. Third, Google copied the most important portion of Oracle’s code—the parts that were both most
creative and most relevant to programmers writing programs. Fourth, Android competes directly with Java licensing business. Also, Android damaged Java by fragmenting the platform and undermining the central “write once, run anywhere” credo.
STANDARD OF REVIEW
“To resolve issues of copyright law, this [C]ourt applies the law as interpreted by the regional circuits, in this case, ... the Ninth Circuit.” Atari, 975 F.2d at 837. Whether particular expression is protected by copyright law “is a mixed question of law and fact ... subject to de novo review.” Ets-Hokin v. Skyy Spirits, 225 F.3d 1068, 1073 (9th Cir. 2000). “[D]enial of a motion for judgment as a matter of law after a jury trial” is upheld only “if there is substantial evidence to support the verdict.” Leatherman Tool Gp., Inc. v. Cooper Indus., 199 F.3d 1009, 1011 (9th Cir. 1999) (internal quotation marks omitted).
I. COPYRIGHT PROTECTS ORACLE’S SOFTWARE PACKAGES.
The Copyright Act sets a very low threshold for copyrightability, and the Act protects computer software as it does other “literary” work. § I.A. Applying these principles, what Google copied is creative and
protectable expression far exceeding this low threshold. § I.B. The district court’s contrary holdings are dangerously erroneous. §§ I.C & I.D.
A. The Copyright Act Sets A Low Threshold For
There can be no dispute as to the axioms that control this case.
Protection And Applies The Same Standard To
Software As Other Protectable Works.
Axiom 1: The Copyright Act protects “original” expression. 17 U.S.C. § 102(a). A work is “original” if “it possesses at least some minimal degree of creativity.” Feist, 499 U.S. at 345 (emphasis added). Oracle “obtained the benefit of a presumption” of copyrightability, Atari, 975 F.2d at 840, by registering the Java platform with the Copyright Office, A1066-68. But, even without the presumption, the packages are easily copyrightable, as “[t]he vast majority of works make the grade quite easily, as they possess some creative spark, no matter how crude, humble or obvious it might be.” Feist, 499 U.S. at 345 (quotation marks omitted; emphasis added).
Courts have no trouble finding the minimally sufficient “creative spark” in works that are “humble,” indeed. They include a Chinese yellow pages, Key Publ’ns, Inc. v. Chinatown Today Publ’g Enters.,
945 F.2d 509, 514 (2d Cir. 1991); estimates of coin values, CDN Inc. v. Kapes, 197 F.3d 1256, 1257-58, 1260-61 (9th Cir. 1999); and pitcher’s statistics, Kregos v. Associated Press, 937 F.2d 700, 702, 704 (2d Cir. 1991). Even a Chinese menu. Oriental Art Printing, Inc. v. Goldstar Printing Corp., 175 F. Supp. 2d 542, 548 (S.D.N.Y. 2001).
Axiom 2: As this Court explains, “copyright protection extends to computer programs,” just as it does to any other work. Atari, 975 F.2d at 838; Computer Assocs., Inc. v. Altai, Inc., 982 F.2d 693, 701-03 (2d Cir. 1992). The Copyright Act protects as “[l]iterary works” “works ... expressed in words, numbers, or other verbal or numerical symbols or indicia.” 17 U.S.C. § 101. Computer programs meet that definition. Atari, 975 F.2d at 838. That is Ninth Circuit law (which, as in Atari, controls here). It is also the universal view of the circuits. See, e.g., Hutchins v. Zoll Med. Corp., 492 F.3d 1377, 1385 (Fed. Cir. 2007); Altai, 982 F.2d at 702-03; Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240, 1249 (3d Cir. 1983).
The district court’s decision was an assault on both axioms. The code Google copied indisputably exceeds by many orders of magnitude the minimal level of creativity necessary for copyright protection. Yet
the opinion is a manifesto of software exceptionalism—the notion that software (or perhaps some undefined category of software) deserves less copyright protection than any other work. The court’s premise was that software innovation is entitled to copyright protection or patent protection, never both. A144, 161-62, 164, 167. The Court preferred patent protection because “copyright exclusivity lasts 95 years.” A144. This either/or notion is, of course, incorrect. The Supreme Court has “h[e]ld that ... [n]either the Copyright Statute nor any other says that because a thing is patentable it may not be copyrighted.” Mazer, 347 U.S. at 217.
The district court countered with an idea from a law review article: “As software patents gain increasingly broad protection, whatever reasons there once were for broad copyright protection of computer programs disappear.” A162 (citation and internal quotation marks omitted). If this Court adopts the district court’s rationale, “copyright protection of computer programs” will indeed “disappear.”
B. The Declaring Source Code And Organization Of Each
Under these axioms, Oracle’s packages are protectable. There was nothing humble about the expression Google copied. It was the
Package Is Protectable Expression.
programming equivalent of a magnum opus—an intensely creative endeavor involving thousands of subjective and intuitive, even artistic, judgments as to what sorts of elements, structures, and relationships a community of programmers would find intuitive, coherent, and aesthetically pleasing. As the chief architect of Oracle’s packages explained, his team strove for “something that we thought was coherent, would be easy to use and attractive to [programmers], but it could have ended up in many different ways and been just as good.” A20,766; accord A20,761, 21,949, 22,399. Even Google’s own “Java guru,” A142, admitted that designing the packages “is very much a creative process.” A20,917; accord A20,910-17, 20,920-22, 20,970.
Oracle’s chief architect also testified that the effort to reach that level of aesthetic appeal entailed “many, many design choices”—so many that “I wouldn’t know how to start counting them.” A20,798, 20,796-97; see A3003-49. The choices included:
[H]ow should classes be organized under other classes?
How should interfaces be organized under other interfaces?
How should classes and interfaces relate? Where should the methods be? What should the methods be named? What kinds of inputs do the methods take? What kind of outputs do the methods provide for the fields? How do ... they relate? Is the value in a field a color, or is it just a number, or is it a string, or is it something else?
A20,797-98. The structural options were infinite.
The district court acknowledged as much when it announced
(albeit in something of an understatement): “Yes, it is creative. Yes, it is original. Yes, it resembles a taxonomy.” A166. Embedded in these findings are two distinct bases for protecting Oracle’s source code. Either suffices: (1) the expressive declaring code; and (2) the creative arrangement of each package.
1. Declaring source code is protectable because it is
This is an uncommon copyright case. Usually, the accused infringer has created a work—whether a visual work, work of literature, or computer program—that bears similarities to the plaintiff’s work. And the court’s role is to determine whether the two are sufficiently similar to amount to plagiarism. Here, we have admitted plagiarism—at least 7000 times over—and the jury found infringement. A41-43, 136, 22,771-73.
The last time the Supreme Court addressed such a situation was Harper & Row Publishers, Inc. v. Nation Enterprises, 471 U.S. 539 (1985). The Nation Magazine obtained an advance copy of President Ford’s memoir. Id. at 543. “The Nation ... admitted to lifting verbatim
quotes ... totaling between 300 and 400 words,” id. at 548—probably less than 1% of the 655-page memoir, id. at 570. The Court took as granted that this “verbatim copying ... would constitute infringement unless excused as fair use.” Id. at 548.
The only way to reach a different conclusion here is to declare that different rules apply when the verbatim infringement is of source code. But, it is “well settled” that source code is protectable. Altai, 982 F.2d at 702; accord JustMed, Inc. v. Byce, 600 F.3d 1118, 1125 n.3 (9th Cir. 2009); Gen. Universal Sys., Inc. v. HAL, Inc., 379 F.3d 131, 142 (5th Cir. 2004). In Atari, Nintendo’s video game program included the “10NES program,” a single program far less sophisticated that Oracle’s web of declaring code. That simple program merely made it impossible for a game to work without transmission of the correct coded message. 975 F.2d at 836. Atari obtained and copied Nintendo’s security source code. Id. at 836, 841. This Court held that the “literal expression” in Nintendo’s security program was “protectable.” Id. at 840. Relying on non-software-specific copyright authority, Atari reasoned that “Nintendo ... exercised creativity in the selection and arrangement of its instruction lines.” Id. at 840. Because there were “alternative” ways of
achieving the same result—a security program—there was “creativity in the [code’s] selection and arrangement.” Id.
If Nintendo’s relatively simple security code cleared the creativity threshold, then the declaring code here does so with ease. Oracle’s developers began, too, with a “clean slate” when they set out to write their original code—including the declaring code—for each package. A20,734, 20,788. Neither programming conventions nor the Java language dictated what the declaring code would be.
Google’s decision not to copy some code (implementing code) does not make the code it did copy (declaring code) unprotectable. Like the topic sentences in Harry Potter, the modest memoir excerpts in Harper & Row, and the 10NES in Atari, the various sentences of infringed code do not lose protection just because Google found other code insufficiently valuable to copy. “As Judge Learned Hand said, ‘No plagiarist can excuse the wrong by showing how much of his work he did not pirate.’” Atari, 975 F.2d at 845 (quoting Sheldon v. Metro- Goldwyn Pictures Corp., 81 F.2d 49, 56 (2d Cir. 1936)).
Google’s effort to trivialize the proportion of the infringed code is especially misguided because what it copied—practically 100% of the
declaring code in 37 packages—was vastly more valuable to programmers than what Google paraphrased. Programmers do not know the implementing code. All they know, and all they need to know to program seamlessly, is the declaring code. Had Google selected different names for the thousands of packages, classes, and methods (e.g., “java.key” rather than “java.security”), the developer community Oracle fostered would not have been as immediately receptive to Android. A20,914-15. It would have been as unfamiliar, and possibly as unpopular, as an Ann Droid knock off that copied a Harry Potter plot, but substituted John Smith and Jane Doe for the protagonists and Duke Jones for the antagonist.
2. The organization of each package is protectable
The packages are independently protectable on two related bases, both arising from Google’s concession (and the district court’s explicit finding) “that the structure, sequence and organization of the 37 accused API packages in Android is substantially the same as the structure, sequence and organization of the corresponding 37 API packages in Java.” A985, 22,771-72. That structure, sequence and
as creative expression.
organization would be protectable, even if Google had not copied a single line of code, but all the more so because it copied 7000.
Copying of non-literal elements. If Ann Droid had paraphrased in the same order every chapter title and topic sentence without copying a single word verbatim, the entire plot that she copied—the structure, sequence, and organization of the overall work— would be protected. See Nichols v. Universal Pictures Corp., 45 F.2d 119 (2d Cir. 1930) (collecting cases). This principle applies equally to software. As with a novel, “[i]t is well-established ... that non-literal structures of computer programs are protected by copyright.” Altai, 982 F.2d at 702 (emphasis added); accord Gates Rubber Co. v. Bando Chem. Indus., Ltd., 9 F.3d 823, 836 (10th Cir. 1993). The reason is that Oracle developers, like novelists, make creative organizational choices, such as which methods go where.
In fact, many precedents involving accusations of copied software do not involve verbatim copying of any literal code elements. See, e.g., Altai, 982 F.2d at 696, 702. In Atari, this Court addressed infringement “[e]ven in the absence of verbatim copying.” Id. at 844. Atari copied the “unique” and “creative organization and sequencing” of Nintendo’s
security function. 975 F.2d at 840. This Court determined that Nintendo’s developers had “a multitude of different” organizations available to perform the needed function, so they “exercised creativity” in their selection. Id. Thus, this Court held that, “[a]t a minimum,” Nintendo could “copyright the unique and creative arrangement of” its work. Id. (emphasis added). The Ninth Circuit reached the same conclusion, on the same logic, in Johnson Controls Inc. v. Phoenix Control Systems, Inc., 886 F.2d 1173 (1989). It held—without regard to the program’s actual source code—that “the nonliteral components of a program, including the structure, sequence and organization ... may be protected by copyright where they constitute expression.” Id. at 1175-76. The key was that the developers had “some discretion and opportunity for creativity ... in the structure.” Id. at 1176.
Even if Google had not copied a single line of code, the organization of each package would be protected expression.
Verbatim copying of literal elements. Of course, Google did verbatim copy thousands of lines of source code, which embody the structure of each package, just as the chapter titles and topic sentences represent the structure of a novel. The verbatim copying of literal
elements encapsulating the overall structure, sequence and organization makes this an even more compelling case for copyrightability.
This is true even if not a single code element, by itself, were copyrightable. As the district court understood, “‘a combination of unprotectable elements is eligible for copyright protection ... if those elements are numerous enough and their selection and arrangement original enough that their combination constitutes an original work of authorship.’” A35 (quoting Lamps Plus, Inc. v. Seattle Lighting Fixture Co., 345 F.3d 1140, 1147 (9th Cir. 2003)). That principle comes directly from Supreme Court precedent: Even if elements of a work “contain absolutely no protectable written expression,” the original “selection or arrangement” of those elements are protected so long as they “entail a minimal degree of creativity.” Feist, 499 U.S. at 348; see Satava v. Lowry, 323 F.3d 805, 811 (9th Cir. 2003) (“It is true, of course, that a combination of [even] unprotectable elements may qualify for copyright protection.”).
Applying this principle, a Chinese Yellow Pages is copyrightable because it arranged the entries under ordinary Yellow Pages categories
and categories of “interest” that are “not common to yellow pages, e.g., ‘BEAN CURD AND BEAN SPROUT SHOPS.’” Key Publ’ns, 945 F.2d at 514. The Seventh Circuit likewise found copyright protection for a directory of dental procedures, in which the procedures were assigned numbers, classified into groups, and described in long and short form. Am. Dental Ass’n v. Delta Dental Plans Ass’n, 126 F.3d 977, 977-78 (7th Cir. 1997). Judge Easterbrook’s opinion explained that the directory was copyrightable as a creative “taxonomy,” because “[c]lassification is a creative endeavor” and “each scheme of classification [in the directory] could be expressed in multiple ways.” Id. at 978-81. The Ninth Circuit reached the same conclusion for a taxonomy of medical procedures. Practice Mgmt. Info. Corp. v. Am. Med. Ass’n, 121 F.3d 516, 517-20 (9th Cir. 1997) (as amended).
* * *
If the works in Atari and Johnson Controls (copying of non-literal
elements) and Practice Management, American Dental, and Key Publications (copying of literal elements embodying an arrangement) were protectable, the same is true many times over for Oracle’s works.
C. The District Court Erred In Concluding That Each
The district court surveyed the caselaw generally at length, but its section entitled “application of controlling law to controlling facts” was just a few pages. A163-70. The court first discussed the verbatim copying of lines of code (addressed in this section) and then turned to the structure and organization of each package (addressed below, § I.D).
Line Of Declaring Code Is Completely Unprotected.
As to the copyrightability of declaring code, the district court “h[e]ld that, under the Copyright Act, no matter how creative or imaginative a Java method specification [i.e., declaring code] may be, the entire world is entitled to use the same method specification (inputs, outputs, and parameters).” A164. The court packed its rationale into 22 lines. A164-65. It held that the “merger” and “short phrases” doctrines barred copyright protection. Each holding is erroneous.
1. The district court misapplied merger.
The merger doctrine represents an application of Baker v. Selden, 101 U.S. 99 (1880): The Copyright Act grants no protection for “the author’s generalized ideas and concepts,” only for the author’s expression (i.e., the “more precisely detailed realization of those ideas”).
Sparaco v. Lawler, Matusky & Skelly Eng’rs LLP, 303 F.3d 460, 468 (2d Cir. 2002). As the district court acknowledged, A164, the merger doctrine holds that “courts will not protect a copyrighted work from infringement if the idea underlying the copyrighted work can be expressed in only one way.” Satava, 323 F.3d at 812. When that happens, the idea and the expression merge.
Atari illustrates the limits of merger for software. Nintendo could not prevent anyone from writing a security program, but since there were many ways to achieve the same security function, Nintendo could copyright its “creative[e] ... selection and arrangement” of “arbitrary programming instructions” to unlock the console. 975 F.2d at 840. Nintendo’s specific choice of code was protectable: It did “not merge with the process,” because “alternative expressions [we]re available.” Id.
By the same token, merger cannot bar copyright protection for any single line of declaring code—much less for all 7000—unless the original authors had available to them “only one way” to write them. Satava, 323 F.3d at 812 n.5. But the authors had many options as to
each individual line and unlimited options as to the selection and arrangement of the 7000 lines Google copied.
As to the individual lines, take the district court’s go-to “simple” snippet: “java.lang.Math.max.” A139. That name was not preordained. A20,970. The developers could have called it “Math.maximum,” “Equations.compare,” “Arith.bigger,” “MeasuringStick,” etc. The computer would have accepted “Rumpelstiltskin.” A20,788. The district court observed that “the Android method and class names could have been different from the names of their counterparts in Java and still have worked.” A132; accord A133, 140-41. That necessarily means that the idea and the expression did not merge.
Even more fundamentally, the court erred in ending its merger analysis at the individual line of declaring code without taking stock of the larger body of declaring code of which it is a part. In so doing, the court made the mistake that so many appellate courts warn against: dissecting a work down to the most minute level of abstraction. That will “result in almost nothing being copyrightable because original works broken down into their composite parts would usually be little more than basic unprotectable elements like letters, colors and
symbols.” Boisson v. Banian, Ltd., 273 F.3d 262, 272 (2d Cir. 2001) (internal quotation marks omitted); see Softel, Inc. v. Dragon Med. & Sci. Commc’ns, 118 F.3d 955, 963 (2d Cir. 1997). The court must not miss the forest for the leaves.
The conclusion that merger does not defeat the copyrightability of any particular line of declaring code applies with even greater force to the thousands of methods and the overall structure described by the large body of declaring code. Here, too, Oracle had an infinite number of choices for which methods to include and how to arrange them. Different software platforms handle the same problems in very distinct ways, as demonstrated by alternative Java packages with quite different designs, written by other developers. A21,412-16. As the district court recognized, granting the original authors copyright protection would not prevent Android from providing even the exact same functions with different organizations:
This could have been done by re-arranging the various methods under different groupings among the various classes and packages (even if the same names had been used). In this sense, there were many ways to group the methods yet still duplicate the same range of functionality.
A132-33 (emphasis added); accord A165-66. Indeed, for over 100 packages in Android, Google wrote its own declaring code with its own internal structure and organization. But not as to each of the 37 packages at issue. A136. Because “alternative expressions are available,” merger does not apply.Atari, 975 F.2d at 840; Satava, 323 F.3d at 812.
The district court also misunderstood another basic point. Whether the focus is on the individual line of declaring code (where the court focused) or the entire body of declaring code, the proper focus in copyright is on the options available to the original author. It must be. After all, “[c]copyright in a work ... subsists from its creation and ... endures for [the copyright] term.” 17 U.S.C. § 302(a). Elevating “Java rules” over copyright law, the district court observed that “[t]o carry out any given function, the method specification as set forth in the declaration must be identical.” A164. To be sure, once the original author chooses “java.lang.Math.max,” programmers who want to use Oracle’s pre-packaged software have to call it by that name. And once J.K. Rowling turned her work into a blockbuster, a plagiarist who wants to tap into that Harry Potter fan base must copy her work. But
that does not mean that the original work never had copyright protection. What a plagiarist feels it must copy to benefit from the original work is irrelevant, because copyright “subsists from ... creation and ... endures.” 17 U.S.C. § 302(a); see PMI, 121 F.3d at 520 n.8 (rejecting theory that a work loses copyright protection when use became pervasive due to government agency requirement).
2. The district court misapplied “short phrases.”
The district court also disqualified every single line of declaring code in an isolated and unexplained sentence: “[N]or can there be any copyright violation due to the name given to the method ... , for under the law, names and short phrases cannot be copyrighted.” A165. The court invoked a Copyright Office regulation that lists “works not subject to copyright,” including: “[w]ords and short phrases such as names, titles, and slogans; familiar symbols or designs; [and] mere variations of typographic ornamentation, lettering or coloring.” 37 C.F.R. § 202.1(a).
The regulation prevents an author from copyrighting a “work” consisting of a naked bit of text. That is what trademark protection is for. The regulation continues: “The Copyright Office cannot register claims to exclusive rights in brief combinations of words.” Id. So,
Nicholas Sparks cannot register the title Safe Haven, thereby precluding anyone from ever using that phrase. A videogame manufacturer may not be able to copyright a naked line of code, “consist[ing] merely of 20 bytes of initialization code plus the letters S-E-G-A,” that “is of such de minimis length that it is probably unprotected under the words and short phrases doctrine.” Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1524 n.7 (9th Cir. 1992) (as amended) (cited by A144).
In contrast, “short phrases” does not eliminate all copyright protection for an assemblage of 7000 lines of code, which Google itself conceded was not de minimis. A976-97; accord A22,777. Imagine our hypothetical plagiarist decided to write a Broadway hit, Ann Droid’s Glengarry Glen Ross. She transcribes every short sentence (which is practically all Mamet ever writes) and paraphrases the rest. No one would say that what she copied was unprotected because each isolated sentence was a short phrase. That is because the “work” she stole was not isolated phrases, but many, many phrases carefully authored and assembled in a specific order and melded together into a coherent whole. “Copyright protection does not protect individual words and
‘fragmentary’ phrases when removed from their form of presentation and compilation,” but short phrases are “subject to copyright in the form in which [they are] presented.” Hutchins v. Zoll Med. Corp., 492 F.3d 1377, 1385 (Fed. Cir. 2007); accord Salinger v. Random House, Inc., 811 F.2d 90, 98 (2d Cir. 1987).
The Eighth Circuit illustrated the point in a case involving the copyrightability of a personality test with 550 concededly “short, simple, declarative sentences,” such as “I am a good mixer” and “No one seems to understand me.” Applied Innovations, Inc. v. Regents of Univ. of Minn., 876 F.2d 626, 634-35 (8th Cir. 1989). The court had no trouble finding the questionnaire protectable.
Here, again, the district court reached the wrong conclusion because it dissected the work too minutely—fixating on the individual line of code rather than the larger arrangement of which it was a part. Supra at 50-51. Moreover, applying “short phrases” as the district court did would invalidate practically any computer program. Virtually every line of the typical program is a short phrase. If each were unprotectable without regard to its relation to the larger whole, there would be nothing left of the program. And nothing left of Atari.
Even if it were appropriate to apply this principle to isolated sentences in a larger work, that could not justify stripping every single line of Oracle’s declaring code of protection. The First Circuit explained (in an opinion Justice (Ret.) Souter joined): Copyrightability “turns on the specific short phrases at issue, as not all short phrases will automatically be deemed uncopyrightable.” Soc’y of the Holy Transfiguration Monastery, Inc. v. Gregory, 689 F.3d 29, 50-52 (1st Cir. 2012) (collecting authorities). Take, for example, the declaring code for a method in the java.security.cert package:
A10,042. Or the declaring code for a class in java.nio.channels:
A10,044. Even shorter declaring code in isolation is not necessarily
unprotected, for “a short phrase may command copyright protection if it exhibits sufficient creativity.” Syrus v. Bennett, 455 F. App’x 806, 809
(10th Cir. 2011) (quoting 1-2 Nimmer on Copyright § 2.01[B] at 2-17). Google’s “Java guru,” A142, admitted: There can be “creativity and artistry even in a single method declaration.” A20,970. Whatever might be said of “math.max,” the declaring code above—and even “java.beans,” A1065—are not devoid of creativity.
D. The District Court Erred In Holding That The
The district court next turned to the independent basis for copyrightability—structure and organization. Its “main answer” was less than half a page. A166. The court acknowledged that “thousands of commands arranged in a creative taxonomy” can still be creative and original. Id. But it held that the structure and organization—no matter how “creative” and “original” or how much “it resembles a taxonomy”—was not protectable on the ground that the commands are a “command structure, a system or method of operation” under 17 U.S.C. § 102(b).
Organization Is Devoid Of Protection.
That analysis is wrong for reasons we address below. But as important, it is also not dispositive because it addresses only half the argument. As is explained above, there are two related reasons why the structure and organization are copyrightable: (1) the copying of non-
literal elements of the structure; and (2) verbatim copying of literal elements of the structure. Supra at 43-47. The court’s focus on the “commands” that “carry out pre-assigned functions,” A166-67, has no bearing on the first rationale, which has nothing to do with specific “commands.” Like paraphrasing Harry Potter without copying a single word, the non-literal claim relates only to the organization that enables a programmer to figure out where to find particular methods, without regard to what names are assigned. The district court gave no reason to deny copyright protection to that organization. The method-of-operation point is irrelevant to that theory of protection. After all, Oracle’s developers could have “put all of the classes [of the platform] into one giant package”—devoid of all structure—since the virtual machine does not care where the code resides. A20,788.
The irony of the court’s approach is that it found the entire assemblage devoid of protection because of copying of literal elements; i.e., because the “commands” or declaring code were not, in its view, protected. But, even if Google wrote different declaring code for every method and class, it would still have copied a creative organization that is protected. It is enough that Google organized the Android package
elements to map directly onto Oracle’s organization. Altai, 982 F.2d at 702. For that reason, alone, the judgment must be reversed.
In any event, even if the focus were just on structure and organization of specific commands, the court’s “method of operation” analysis was wrong—devastatingly so, for the software industry. So, too, was the “interoperability” concept it invoked to support its analysis.
1. The district court erred in dismissing the
Copyright does not “extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery.” 17 U.S.C. § 102(b). Section 102(b) codifies the traditional idea/expression dichotomy and the merger doctrine that flows from it. Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435, 1443 & n.11 (9th Cir. 1994). The § 102(b) argument fails for the same reason merger fails. Supra at 48-53.
organization as an unprotected “method of operation.”
Regarding software in particular, courts routinely invoke Congress’s explanation that § “102(b) is intended ... to make clear that the expression adopted by the programmer is the copyrightable element in a computer program,” but “that the actual processes or methods
embodied in the program are not.” H.R. Rep. No. 94-1476 (1976) (emphasis added) (quoted in Altai, 982 F.2d at 703, and Apple Computer, 714 F.2d at 1252-53).
This Court’s Atari opinion applied this consensus. It described merger and “method of operation” in the same breath and then conducted the inquiries together: “This court, in applying Ninth Circuit law, must determine whether each component of the 10NES program ‘qualifies as an expression of an idea, or an idea itself.’” 975 F.2d at 839-40 (citing Johnson Controls, 886 F.2d at 1175). The security code was not a “method of operation” for the same reason that it did not run afoul of the merger doctrine: there were “alternate expressions ... available.” Id. at 840.
So, too, here. Since, as we demonstrate above, the original authors of Oracle’s packages had limitless “alternate expressions ... available” for selecting and arranging the various programs in each package, the idea for each package does not merge into the expression, and § 102 is not implicated. Supra at 51-53.
Instead of following this Court’s and the Ninth Circuit’s definition of a “method of operation,” the district court substituted its own
definition. It reasoned that not a single line of declaring code “can receive copyright protection” because they are “commands to carry out pre-assigned functions.” A166-67. That is wrong. That definition is essentially the same as the Copyright Act’s definition of protectable “computer program”: “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” 17 U.S.C. § 101 (emphasis added). If a computer program is unprotectable simply because it “carr[ies] out pre-assigned functions,” no computer program is protectable.
The software cases the district court discussed disprove its rationale. Those cases recognize the copyrightability of source code, even though it consists of “commands to carry out pre-assigned functions.” The Seventh Circuit, for example, rejected the district court’s theory, reasoning that “word-processing software” does not become an unprotectable “‘system’ just because it has a command structure for producing paragraphs.” Am. Dental, 126 F.3d at 980. The Tenth Circuit agreed: “[A]lthough an element of a work may be characterized as a method of operation, that element may nevertheless contain expression that is eligible for copyright protection.” Mitel, Inc.
v. Iqtel, Inc., 124 F.3d 1366, 1372 (1997); see Toro Co. v. R & R Prods. Co., 787 F.2d 1208, 1212 (8th Cir. 1986) (that a work is a “system” under § 102(b) does not preclude copyright protection for the “particular expression” of the system); 1-2 Nimmer on Copyright § 2.03[D].
The district court was evidently influenced by a line in Lotus Development Corp. v. Borland International, Inc., 49 F.3d 807, 810 (1st Cir. 1995), aff’d by equally divided court, 516 U.S. 233 (1996), that has no bearing here. There, the defendant copied a relatively simple menu system and interface but “did not copy any ... underlying computer code.” Id. at 810. Lotus, therefore, does not address and cannot apply to verbatim copying of source code.
To be sure, Lotus defines “method of operation” very expansively: as “the means by which a person operates something.” Id. at 815. But that definition cannot be applied beyond the facts of that case, because it would strip all computer programs of copyright protection despite Congress’s decision to protect software.
No other circuit adopts the Lotus formulation and no opinion applies it to a case like this. At least one circuit explicitly “decline[d] to adopt the Lotus court’s approach to section 102(b).” Mitel, 124 F.3d at
1372. The breadth of the definition was undoubtedly part of the reason the Supreme Court granted certiorari in Lotus. That the case split the Court 4-4 confirms that the holding is highly in doubt and the definition on which it was based almost certainly doomed. 516 U.S. 233 (1996).
2. The district court erred in invoking
Equally mistaken was the court’s view that “[i]nteroperability sheds further light on the character of the command structure as a system or method of operation.” A167. The court adopted Google’s argument that declaring code in Oracle’s 37 packages lost all copyright protection—years after they were written—because they became wildly popular and Google wanted the Java community of programmers to flock to Android. It is like Ann Droid saying: “No one would buy my book unless I copied the key parts of a wildly popular series. Ergo, that material must not have any copyright protection.” Google’s argument is wrong on the law and the record.
interoperability in support of “method of
Doctrinally, interoperability is irrelevant to whether the packages are copyrightable. The court’s interoperability rationale suffers from the same focus on the wrong author as its merger analysis. Supra at
52-53. Here, again, the copyrightability analysis must be conducted ex ante—from the perspective of the original authors of Oracle’s packages, and what constrained them. Oracle’s developers wanted a bestseller. For the reasons already explained, Oracle’s developers were not in the least bit constrained by an imperative to cater to some competitor who might come along years later and want to copy all of their declaring code without a promise of compatibility.
If interoperability is relevant at all, it would be only to fair use (discussed infra at 68-77), as in the cases the district court invoked. A152-61, 168 (discussing Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d 596, 602-08 (9th Cir. 2000); Sega, 977 F.2d at 1522-23). But, in any event, for the reasons explained above, an interoperability defense has no bearing on whether the work was protectable—and specifically, on whether it was a method of operation. See17 U.S.C.
Apple Computer rejected Google’s exact argument. There, the
defendant justified its infringement because there were only “a limited number of ways to arrange operating systems to enable a computer to run ... Apple-compatible software.” 714 F.2d at 1253 (quotation marks
omitted). The court held: “[Defendant] may wish to achieve total compatibility with independently developed application programs[,] ... but that is a commercial and competitive objective which does not enter into the somewhat metaphysical issue of whether particular ideas and expressions have merged.” Id.
The Ninth Circuit agrees. In PMI, it rejected the argument that everyone could copy the plaintiff’s medical coding system because the
system had become the “industry standard.” 121 F.3d at 520 n.8. Like Google here, competitors remained free to “develop comparative or better coding ... and lobby” for their adoption. Id. Copyright “prevents wholesale copying of an existing system.” Id.
Moreover, Google’s copying was not about interoperability. Interoperability means that programs written for Android would run on the Java platform and vice versa. Google wanted the opposite: to copy enough code to make Android familiar enough to “[l]everage” the millions of Java programmers who knew Oracle’s packages, A2033, but not copy all the code that would be required for interoperability. Accordingly, many programmers now write Android-only programs that do not work on the Java platform. In so doing, Google made Android
unusable for many of the “millions of lines of code [that] had been written in Java before Android arrived.” A167; see A22,397-98, 22,463.
Don’t take our word for it. Google’s internal “Android Press Q&A” answering the most important questions upon Android’s release said it all:
Q48. Does Android support existing Java apps?
A2205. That was not some mistake by a benighted PR department. If one person at Google knew the definitive answer to the question, it would have been its Technical Program Manager for Android Compatibility. A21,172. He testified that “Android does not support Java applications” and “is not Java compatible.” A21,179; see also A21,503-04 (“[Y]ou don’t really have compatibility. You can’t ship code from one platform to another.”).
Q49. Is Android Java compatible?
The district court worried that “[t]o accept Oracle’s claim would be
to allow anyone to copyright one version of code to carry out a system of
commands and thereby bar all others from writing their own different versions to carry out all or part of the same commands.” A170. Not so. The issue is not Google’s different implementing code. Rather, it is Google’s violation of the Copyright Act by co-opting thousands of the exact lines of code Oracle wrote and the exact creative organization Oracle designed that made its work so popular.
Congress, the courts, and the Founders determined that “the best way to advance public welfare” is to “encourage” the authors of such works to engage in “individual effort by” offering them “personal gain.” Mazer, 347 U.S. at 219; accord U.S. Const. art. I, § 8; 17 U.S.C. § 106. That wisdom applies as much to Oracle’s declaring code as to all other literary works. Oracle invested years and hundreds of millions of dollars to author software packages that it would license others. The surest way to guarantee that no company ever makes an investment like that again is to declare that “the public w[as] and remain[s] free to ... us[e] exactly the same [declaring code] ... and organiz[ation].” A165.
II. GOOGLE CANNOT ESTABLISH THAT ITS
COMMERCIALLY MOTIVATED AND ILLICIT VERBATIM
COPYING IS FAIR USE
This Court should not stop at finding that Google infringed Oracle’s copyrighted work. A remand to decide fair use is pointless. This Court should rule, as a matter of law, that Google’s commercial use of Oracle’s work in a market where Oracle already competed was not fair use.
Fair use is “an affirmative defense”—a limited exception to the copyright holder’s exclusive rights, where Google bears the burden of proof. Harper & Row, 471 U.S. at 561. The district court should have declared, as a matter of law, that Google’s copying was not fair use, A129, as the Supreme Court and Ninth Circuit frequently have done. Harper & Row, 471 U.S. at 561; see Monge v. Maya Magazines, Inc., 688 F.3d 1164, 1184 (9th Cir. 2012); Worldwide Church of God v. Phil. Church of God, Inc., 227 F.3d 1110, 1121 (9th Cir. 2000).
The relevant facts are discussed at length above, so we focus on the law and reference (but do not repeat) prior factual discussions.
Congress framed the “fair use” inquiry around four nonexclusive factors:
(1) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;
17 U.S.C. § 107. “The central purpose of the investigation is to see ... whether the new work merely supersedes the objects of the original creation.” Campbell v. Acuff-Rose Music, Inc., 510 U.S. 569, 579 (1994);accord Harper & Row, 471 U.S. at 550. “[F]air use ... always preclude[s] a use that supersedes”—i.e., replaces—“the use of the original.” Harper & Row, 471 U.S. at 550. This is what happened when Android preempted the burgeoning market for Java in smartphones. Every factor cuts against Google here.
(2) the nature of the copyrighted work;
(3) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and
(4) the effect of the use upon the potential market for or value of the copyrighted work.”
A. Google’s Copying Was Commercially Motivated, Not
Google’s use of Oracle’s code is purely commercial. Id. at 562. Android is one of the most lucrative endeavors of the past decade. Google’s counsel conceded that “the fact that it’s a commercial use is not in dispute .... The evidence is pretty clear that they created it to
Transformative, And Illicit.
provide a platform on which other Google product[s] could do better.” A21,591. The district court agreed: “Google’s internal documents show how many billions of dollars they expected to make off of [Android].... This was intended for commercial purposes with large amounts of money at stake and, therefore, it was not fair use. It was copying.” A21,594.
In considering the first factor, courts also inquire whether the copied material substitutes for the original or, instead, adds or changes the purpose of the original, thereby “transform[ing]” it in a meaningful way. Campbell, 510 U.S. at 579. Google’s use of Java declaring code was anything but transformative. Mere alteration is not transformation. A use of copied material is not transformative unless the material is used “in a different manner or for a different purpose from the original.” Hon. Pierre Leval, Toward a Fair Use Standard, 103 Harv. L. Rev. 1105, 1111 (1990); see Campbell, 510 U.S. at 579.
Google’s use of the declaring code was exactly the same as in Java: to call upon prewritten packages to perform the same functions. The packages also serve the identical purpose: solving the same complex problems and performing the same often-needed functions programmers
desire. While using the declaring code in exactly the same way as the original, Google deployed that purloined code in Android to compete directly with commercially licensed derivatives of Oracle’s work. Oracle licenses Java in the mobile market and licensed it for smartphones specifically, including RIM’s Blackberry, Nokia’s Series 60 phones, and Danger’s Sidekick/Hiptop. Supra at 15-16.
Such superseding use is “always” unfair. Harper & Row, 471 U.S. at 550 (emphasis added); id. at 569 (“[A] use that supplants any part of the normal market for a copyrighted work would ordinarily be considered an infringement.” (citation omitted)). Copying work to use for the same purpose simply cannot be fair use. See Peter Letterese & Assocs. v. World Inst. of Scientology Enters., Int’l, 533 F.3d 1287, 1311, 1318 (11th Cir. 2008) (book about sales techniques superseded the original even though it “adopt[ed] a different format, incorporate[d] pedagogical tools ... , and condense[d] the material in the [original] book”); Elvis Presley Enters., Inc. v. Passport Video, 349 F.3d 622, 628- 30 (9th Cir. 2003) (documentary containing “significant portions” of video clips supersedes original and is not fair use); Twin Peaks Prods., Inc. v. Publ’ns Int’l, Ltd., 996 F.2d 1366, 1375-77 (2d Cir. 1993) (holding
that a comprehensive guide to the characters and plot of a television show supersedes the show and is not fair use).
Finally, “[f]air use presupposes good faith and fair dealing.” Harper & Row, 471 U.S. at 562 (internal quotation marks omitted). Google considered, negotiated, and ultimately rejected the opportunity to license the packages, deciding to “[d]o Java anyway and defend our decision, perhaps making enemies along the way.” A1166. That Google knew it needed a license, and then sought but did not obtain one, weighs heavily in showing “the character of the use” was not fair. Los Angeles News Serv. v. KCAL-TV Channel 9, 108 F.3d 1119, 1122 (9th Cir. 1997). Google “knowingly ... exploited a purloined work for free that could have [otherwise] been obtained.” Id.
B. Google Copied A Creative Work.
The nature of Oracle’s copyrighted work also precludes fair use. The Java platform is the product of “substantial creative effort.” Rogers v. Koons, 960 F.2d 301, 304 (2d Cir. 1992). Indeed, Google’s “Java guru,” A142, explained: Designing packages is “a noble and rewarding craft,” where “creative[ity]” and “aesthetic[s] matter.” A20,917, 20,920- 22. Java developers’ creative efforts resulted in thousands of lines of
original declaring code, embodying a sophisticated design and organization that programmers find easy to use. “Of course” this was “creative,” the district court found. A164.
Wall Data Inc. v. Los Angeles County Sheriff’s Dep’t, 447 F.3d 769, 778 (9th Cir. 2006), is instructive. The defendant there also copied software. Id. at 778. Because designing the software took “several years” work and a “multi-million dollar” investment, “the nature of the copyrighted work weigh[ed] against a finding of fair use.” Id. at 780. Accordingly, the Ninth Circuit rejected fair use.
Here too. Oracle invested years of labor and hundreds of millions of dollars in researching and developing the packages. Java’s chief architect spent almost two years developing a single set of related packages. A22,403-04. Oracle’s substantial and ongoing development effort cost “hundreds of millions of dollars” a year just “on Java.” A20,557.
C. Google Verbatim Copied The Code And Structure That Matters To A Java Programmer.
Google also loses under “the amount and substantiality of the portion used” factor. Harper & Row is critical. The 300-400 words that The Nation copied verbatim were less than 1% of the original work. But
the Court held this factor favored the copyright owner because the infringing work was “structured around the quoted excerpts which serve as its dramatic focal points.” 471 U.S. at 566. Indeed, the infringer “quoted these passages precisely because they qualitatively embodied” the author’s “distinctive expression.” Id. at 565. The “expressive value of the excerpts and their key role in the infringing work” meant the use was not fair. Id. at 566.
The same is true here. Google copied the only code with any relevance to programmers: the declaring code. Supra at 20-21, 43-44. Google “quoted these passages precisely because they qualitatively embodied” Oracle’s “distinctive expression” and were familiar to programmers. Harper & Row, 471 U.S. at 565; A5874 (Google took “the good stuff from Java”); accord A21,503, 21,957-59. As in Harper & Row, the “expressive value of the excerpts and their key role in the infringing work” mean that this factor does not support fair use. 471 U.S. at 566.
Google’s defense that it created its own implementing code is beside the point. The Nation wrote 87% of its article. But, like The Nation, Google copied the “focal point” of the work, id.—the declaring
code. “[T]he amount and substantiality of the portion used” factor does not favor Google.
D. Google’s Copying Damaged The Value Of The Java
Google also fails the final factor—“the effect of the use upon the potential market for or value of the copyrighted work.” To prevail, Google must establish that Android did “not materially impair the marketability of the work which is copied.” Harper & Row, 471 U.S. at 566. “This inquiry must take account ... harm to the original [and] ... derivative works,” id. at 568; see 17 U.S.C. § 106(2) (exclusive statutory right “to authorize ... derivative works based upon the copyrighted work”), and the effect on the potential market if the challenged use “become[s] widespread,” Harper & Row, 471 U.S. at 568. In two different ways Android materially impaired the actual and potential market for Oracle’s derivative works and superseded the original and its derivatives, thereby compelling a conclusion against Google on this “single most important element of fair use.” Id. at 566.
Platform In The Smartphone Market.
First, Android was designed to be incompatible with and thereby fragment the Java platform. As explained, Android undercuts the “write once, run anywhere” credo that is central to Java’s value
proposition and replaces it with “write once, run only on Android.” Supra at 66-67. Android thereby deprives Java of the value of compatibility with those additional applications.
Second, Android was designed to replace Java SE derivative works in the smartphone market. Android gave handset manufacturers, wireless carriers, and software vendors a Java-friendly programming environment without licensing fees. A21,631, 21,763. If similar unauthorized, commercial use of the declaring code by other infringers became “widespread,” Harper & Row, 471 U.S. at 568, that would decimate all Java commercial licensing opportunities of every kind.
When Google copied the Java packages and released Android, Oracle was licensing in the mobile and smartphone markets. Supra at 15-16. Where the plaintiff is “in the business of selling [the work] and [has] done so in the past” it “unequivocally demonstrates a market for the [work].” Monge, 688 F.3d at 1181. Android thus substantially harmed Oracle’s already “very lucrative,” commercial opportunities. A22,237. Indeed, Android “now comprise[s] a large share of the United States [smartphone] market,” A135, with 750,000 new devices activated
every day, A21,188. Google gives away Android for free, A135, and competes against Oracle’s licensing of Java derivatives. As Oracle’s President and CFO pointedly observed: “It’s pretty hard to compete with free,” A22,498, which Oracle learned the hard way with Amazon. Supra at 29.
Nothing about Google’s use was fair.
For the foregoing reasons, this Court should reverse the judgment.
Dated: February 11, 2013
By: /s/ E. Joshua Rosenkranz
E. Joshua Rosenkranz
Orrick, Herrington & Sutcliffe LLP
Attorney for Plaintiff-Appellant
Excerpt Of Transcript of Proceedings (Including Order Regarding Google's Fair Use Defense)
[PJ: See PDF, pages 91-176 for transcript; pages 177-178 for the May 10, 2012 Order on Motions for Judgment as a Matter of Law (you can also find it as text on Groklaw here; pages 179-220, Order Re Copyrightability of Certain Replicated Elements of the Java Application Programming Interface, dated May 31, 2012 (which you can also find as text on Groklaw here; pages 221-223 for Final Judgment, dated June 20, 2012; pages 224-227 for Order Denying MOtion for Judgment as a Matter of Law and New Trial, dated July 13, 2012.]
DATED MAY 9, 2012
1 Sun’s developers spent years refining, writing, organizing, and promoting packages of computer source code to help outside application (“app”) programmers write new computer programs in the Java language faster and more efficiently by just incorporating the packages into their own Java programs. The packages were wildly popular, largely because they were written and organized in a way that made intuitive sense. A community of millions of application programmers coalesced around them. But everyone—IBM, Sony, Cisco, Red Hat, and others—understood that no one was allowed to use the packages without a license from Sun/Oracle.
Enter Google. Google was late to the smartphone market. Google’s top brass was desperate to develop its own mobile platform: Android. They concluded that the platform needed to include Sun’s popular Java packages. As one email to Google executives indelicately put it, the alternatives “all suck[ed].” A1168.
2 The district court estimated 7000, which, it believed, represented 3% of the lines of code in those 37 packages. E.g., A136. We do not challenge those numbers on appeal but note that they are too low. The classes and methods, alone, number 7000, and declaring code for a single element can be several lines long. See infra at 57.
3 Oracle is not appealing from the jury’s verdict on patent infringement or copyright infringement by Google’s Android documentation.