I thought you'd like to see the Oracle motion that the Hon. William Alsup denied Wednesday, after a couple of hours of oral argument. I see at least one person tweeting that the judge has ruled that APIs are not copyrightable. He hasn't ruled on that yet. This was something else. You can read about the judge's ruling here.
What he did rule on were two motions for judgment as a matter of law.
If a party feels at any point that after hearing all the evidence, its case can be decided by the judge without a jury because no jury could reasonably find for the other party, it can file a motion asking for judgment as a matter of law. It's common to see that near or at the end of the presentation of evidence in a trial. That kind of motion is called a Rule 50(A) motion. Here, Oracle's motion, dated May 1st, was asking the judge to rule, among other things, that Oracle is entitled to judgment as a matter of law on Google’s fair use defense. It's that motion that was denied. Google's JMOL was also denied. The bigger question, whether APIs are even copyrightable, is still pending.
So what does this ruling mean? That the issue of Google's fair use defense, at a minimum, remains alive and it has to go to a jury, a new one, unless the judge in his pending ruling decides that APIs aren't copyrightable.
Here's the Oracle motion [PDF], and I've done it as text for you. It's not the ruling we are waiting for, but it's a pretty significant decision anyhow, because it slams the door on Oracle's attempt to get a $1 billion payday from its copyright claims.
Of course, there will be appeals. And Oracle could win something in the patent phase of the litigation, now going on in the courtroom. But it means that we won't have to read any more headlines about a possible $1 billion win for Oracle. That chapter is closed in this trial.
No $6 billion and now no $1 billion. Oracle's hand keeps getting smaller and smaller. The most that is on the line at the moment from copyright claims is $150,000 for 9 lines of code no longer in current Android products, so it's not even an ongoing tax on Android. Oracle is now arguing it shouldn't have to accept statutory damages; it wants infringer's profits, blah blah, but Rachel King just tweeted the judge's reaction this morning:
Alsup said Oracle is making a "mistake" Also said "It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
We have a reporter in the courthouse today, I'm happy to tell you, so I'll post any info when it comes in.
Here's Google similar motion [PDF; text] for judgment as a matter of law. It was also denied. That means neither party wins *this way*, that the remaining issue of fair use is for the jury to decide. This jury decided some of the issues, and a new jury will eventually decide the issue of fair use, unless there is some kind of settlement or the judge rules in the interim that APIs are not copyrightable.
Keep in mind that what Google was accused of is this: "Google copied into Android the structure, sequence, and organization ("SSO") of 37 Java API packages". Oracle's position is that the selection, sequence and organization of uncopyrightable items, like the names of the 37 APIs, can be copyrighted. That's what this motion dealt with, the SSO of the APIs. What the judge will be deciding later is whether or not the 37 APIs are even copyrightable. Do you see the distinction? I hope I made it clear. It means we have two things to worry about from this case, thanks to Oracle: can APIs be copyrighted? and even if not, can the sequence, selection and organization of APIs be copyrighted? They are related but not identical.
[ Update: I wanted to let you know that our reporter has her report, very detailed, about Tuesday's session, which I've added to the day as Update 3. It covers the day through Google's opening statement in phase 2, where Google explains to the jury that they never used either patent in suit, that Android and Dalvik use a different and totally independent design. I think you'll see why Google didn't care about invalidity of the '104 patent -- it says it never used it or in fact either of them.]
[ Update 2: The judge has granted Oracle's motion with respect to the test files, question 3b in the jury's instructions. The order is in the next article.]
[ Update 3: All the trial exhibits are now available as PDFs here. Some are also done as text. Look for the date nearest the day, as they are listed by the date they were entered, which could be a day or so after the date of their use in the courtroom.]
Here's the Oracle motion, as text, without the header, table of contents and list of cases, which I'll try to add later. It lays out Oracle's case pretty clearly, so if you want to understand the API SSO claim, for example, this is your clear opportunity. It lost, however, on this motion, and the jury ruled against Oracle on several issues in the motion, finding for example that Google did not infringe Oracle's documentation, that it didn't infringe the comments, etc., so don't let the bombastic tone fool you, as the jury already sent most of this to the bottom of the ocean. But this is how Oracle saw its case and it wanted the judge, in effect, to overrule the jury, but he declined the invitation:
ORACLE AMERICA, INC.'S CORRECTED RULE 50(A) MOTION
Google has infringed Oracle's registered copyrights in Java 2 Standard Edition,
Version 1.4 ("J2SE 1.4") and Java 2 Standard Edition, Version 5.0 ("J2SE 5.0") in three distinct
ways: (1) Google copied into Android the structure, sequence, and organization ("SSO") of 37
Java API packages; (2) Google copied Java code into twelve Android code files; and (3) Google
copied material from Java API specifications into Android's specifications. All three varieties of
copying were submitted to the jury for resolution.1However, in light of Google's admissions and
the weight of the evidence, Google's copyright infringement can be determined as a matter of
law, as no reasonable jury could find for Google.
The SSO is the backbone of the 37 Java API packages, supplying both taxonomy and
definition. Within the Android and Java code, the SSO is embodied in the names of the API
elements (packages, classes, interfaces, methods, and fields), the organization and
interrelationships among those elements, and the class and method declarations, and is expressed
in more than 7000 lines of code. This SSO, as a core feature of the copyrighted Java software
platform, is protected by copyright. Johnson Controls, Inc. v. Phoenix Control Sys., Inc., 886
F.2d 1173, 1175 (9th Cir. 1989).
Assuming the Court confirms the copyrightability of the SSO under governing Ninth
Circuit authority, Google's infringement is manifest. Google and its witnesses admit that (1) the
Java APIs are original; (2) Android engineers and contractors directly copied the SSO of the 37
Java API packages from Java specifications into Android; (3) the SSO is not de minimis;
(4) Google copied Java code into twelve Android code files; and (5) Google paraphrased the Java
specifications in writing the Android specifications. The unabashedly commercial, non-transformative nature of Google's copying undermines its fair use defense. And Google has
failed to meet its burden of proving its equitable defenses. For all of these reasons, Oracle is
entitled to judgment as a matter of law.
II. LEGAL STANDARD FOR JUDGMENT AS A MATTER OF LAW
Judgment as a matter of law is appropriate when "a party has been fully heard on an issue
during a jury trial and the court finds that a reasonable jury would not have a legally sufficient
evidentiary basis to find for the party on that issue." Fed. R. Civ. P. 50(a)(1). "[T]he trial judge
must direct a verdict if, under the governing law, there can be but one reasonable conclusion as to
the verdict." Anderson v. Liberty Lobby, Inc., 477 U.S. 242, 250 (1986).
III. NO REASONABLE JURY COULD FIND THAT GOOGLE DID NOT
INFRINGE ORACLE'S JAVA-RELATED COPYRIGHTS
To establish copyright infringement, Oracle must show that: (1) Oracle is the owner of an
original copyrighted work; and (2) Google copied elements from the copyrighted work. (ECF
No. 1018, JI 23-24.) Feist Publ'ns, Inc. v. Rural Tel. Serv. Co., Inc., 499 U.S. 340, 361 (1991).
Copying can be established either by (1) proving direct copying, or (2) showing that the accused
infringer had access to the copyrighted work and there are substantial similarities or virtual
identity between the copyrighted work and the accused work. (ECF No. 1018, JI 24.) Range
Road Music, Inc. v. East Coast Foods, Inc., 668 F.3d 1148, 1154 (9th Cir. 2012) ("`substantial
similarity' is irrelevant in a case [involving] direct copying of copyrighted works"); Jada Toys,
Inc. v. Mattel, Inc., 518 F.3d 628, 636-37 (9th Cir. 2008). Under the second approach, the Court
has determined that copying of the SSO and twelve code files should be evaluated using the
substantial similarity test, while copying of the API specifications should be evaluated using the
virtual identity test.2(ECF No. 1018, JI 24.)
As discussed below, all elements of copyright infringement have been established in this
case by Google's own stipulated admissions, the clear admissions of Google witnesses, and/or the
overwhelming weight of the evidence.
A. Oracle Owns The Asserted Copyrights3
The issue of copyright ownership was not posed to the jury. (ECF No. 1018, JI 23.)
Oracle owns the copyrights to J2SE 1.4 and J2SE 5.0. The copyright registrations were admitted
into evidence (TX 464, 475, 476), along with the complete contents of both versions of the
platform. (RT 689:21-691:23 (Reinhold); TX 610.2, 622, 623, 1076.) Oracle is entitled to a
presumption that the facts stated on the front of the copyright registrations are correct. 17 U.S.C.
§ 410(c) (certificate of registration "shall constitute prima facie evidence of the validity of the
copyright and of the facts stated in the certificate"). Google "has the burden of rebutting the facts
set forth in the copyright certificate." United Fabrics Int'l, Inc. v. C&J Wear, Inc., 630 F.3d
1255, 1257 (9th Cir. 2011). Google has submitted no evidence to rebut the facts reflected in
Oracle's copyright registrations.
Accordingly, Oracle is entitled to judgment that it is the owner of valid copyrights to J2SE
1.4 and J2SE 5.0, covering all components of those works, including the individual code files and
the SSO of the API packages.
B. Google Infringed By Copying The SSO Of The 37 Java API Packages
Google's admissions and the weight of the evidence prove that (1) the Java API packages
are original, (2) Google engineers directly copied the SSO of the 37 API packages into Android,
and (3) the SSO of the 37 packages is not de minimis. If the Court confirms that the SSO of the
API packages is copyrightable (addressed below), infringement will follow as a matter of course.
Google has not challenged the originality of the copyrighted Java API packages, and,
accordingly, this issue was not posed to the jury. Google has admitted that the Java APIs meet
the required threshold: "The Java APIs as a whole meet the low threshold for originality required
by the Constitution." (ECF No. 938 (Order deeming issues undisputed based on Google's
admission) at 1.) Moreover, because Oracle holds registered copyrights covering the asserted
works, it is entitled to a presumption of originality. Swirsky v. Carey, 376 F.3d 841, 851 (9th Cir.
2004) ("Because One has a valid certificate of registration with the copyright office, however,
Swirsky is entitled to a presumption of originality").
The evidence of originality is overwhelming and uncontroverted. The threshold for
establishing originality is low. Feist, 499 U.S. at 345 ("Original, as the term is used in copyright,
means only that the work was independently created by the author (as opposed to copied from
other works), and that it possesses at least some minimal degree of creativity"). Numerous
witnesses confirmed that API design is highly creative and challenging. (RT 513:14-18
(Screven); 627:21-628:1 (Reinhold).) Dr. Bloch stated that designing an API is a work of
craftsmanship, requiring the API author to exercise creativity and aesthetic judgment. (RT 751:5-752:14; TX 624 at p. 47.) Dr. Reinhold testified that it took him and a team of engineers two
years to develop just one API package, java.nio. (RT 623:17-624:1.) Based on the evidence and
Google's admission, the originality of the 37 API packages is beyond dispute.
2. Direct Copying
Where there is evidence of direct copying, there is no need to apply the substantial
similarity test. Range Road, 668 F.3d at 1154 ("`substantial similarity' is irrelevant in a case
[involving] direct copying of copyrighted works"). In this case, the evidence shows that Google
directly copied the SSO of the 37 Java API packages into Android.
Former Google engineer Bob Lee was the core libraries lead for Android in the 2006-2007
time period. (RT 980:14-981:6.) Mr. Lee testified that Android implements parts of the Java
APIs and that such implementation was based on consulting the Java API specifications:
Q. You consulted the Java API specifications to make sure that the Android code for the
corresponding core libraries would be consistent with those specifications, correct?
(RT 982:25-983:3; see also RT 981:7-21.) Mr. Lee also testified that Google's outside
contractor, Noser, was hired to implement core libraries based on the Java API specifications:
Q. Noser was an outside contractor hired by Google to implement core libraries according
to the Java API specifications, correct?
(RT 985:3-6.) Former Google engineer Dan Bornstein confirmed that his team had used the Java
specifications to derive information for implementing the APIs in Android:
Q. Now, you testified on direct, sir, that you and your team looked at the Java
specifications for these application programming interfaces while you were doing your
work on Android; correct, sir?
(RT 1836:19-1837:2.) Because the Java specifications are directly derived from the underlying
source code (RT 606:14-608:3 (Reinhold); TX 1046 at p.19), the Android engineers effectively
had access to the SSO of the source code itself. The fact that Google literally copied some Java
code (discussed below) demonstrates that they had direct access to the code as well.
A. That's right.
Q. And you did that in order to derive from these specifications the information you
needed in order to write that code; correct, sir?
A. Some of the information.
By deriving the Android class libraries from the Java API specifications, the Android
engineers wound up copying the entire SSO of the 37 API packages into Android. Mr. Bornstein
confirmed that "the names and declarations" are the same between Java and Android. (RT
1791:21-1792:6 (Bornstein).) Google's expert, Dr. Astrachan, admitted that the SSO of the 37
packages is "virtually identical" between Java and Android. (RT 2214:3-9 (Astrachan).) Based
on the evidence of direct copying, Oracle has proven infringement.
3. Access and Substantial Similarity
Oracle has proven copying under the substantial similarity test as well. That test requires
a showing that the infringer had access to the copyrighted work and that the accused and
copyrighted works are substantially similar. See Jada Toys, 518 F.3d at 636-37. The Java API
specifications that detail the SSO of the API packages were publicly available on Sun's website.
(RT 983:4-6 (Lee).) The testimony of Messrs. Lee and Bornstein cited above demonstrates that
Google had access to the Java specifications. As for substantial similarity, Google admits that the
SSO of the 37 API packages is substantially the same between Java and Android:
Google agrees 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.
(ECF No. 1018, JI 19; see also ECF No. 946 (Stipulation); RT 1337:21-24.) Dr. Astrachan went
further, agreeing that the SSO in Java and Android is "virtually identical." (RT 2214:3-9.)
During its closing argument, Google compared the code that embodies the SSO of the 37
Java API packages in Android to the complete code for the 166 packages in J2SE 5.0 and argued
that the two are not substantially similar because the latter is far more voluminous than the
former. This approach is wrong as a matter of law. First, as already noted, since the evidence
shows that Google engineers and contractors directly copied the SSO from Java specifications,
there is no need to apply the substantial similarity test at all. Second, even under the substantial
similarity test, an infringer cannot escape liability by arguing that it only took a small portion of
the overall copyrighted work that is qualitatively significant. See Warner Bros. Entm't Inc. v.
RDR Books, 575 F. Supp. 2d 513, 535 (S.D.N.Y. 2008) (finding that Harry Potter Lexicon
"copie[d] a sufficient quantity of the Harry Potter series to support a finding of substantial
similarity," even if the copied elements "amount to only a fraction of the seven-book series");
Paramount Pictures Corp. v. Carol Publ'g Group, 11 F. Supp. 2d 329, 334 (S.D.N.Y 1998)
("Copying only small portions of a series of copyrighted works offers no protection for a
Under Google's theory, a copier who takes a portion of a piece of software could never be
liable, even when the copied portion is qualitatively significant, as is the case with the SSO of the
37 API packages. While the number vastly understates its significance, the SSO is embodied in
more than 7,000 lines of code (names and declarations), without which the Android platform
would not function as designed. (RT 2212:3-19 (Astrachan).) The copied SSO in Android is
qualitatively substantial even as compared to the 166 Java API packages, and the two are
substantially similar in that regard.
4. Google Admits That The SSO Is Not De Minimis
The Court instructed the jury that to find copyright infringement it must also find that the
amount of copying was not de minimis. (ECF No. 1017, JI 24.) However, Google dropped this
argument as to the SSO of the 37 API packages on the last day of trial. As reflected in the jury
instructions, the "parties are in agreement that the structure, sequence, and organization of the
API packages is more than de minimis." (ECF No. 1018, JI 27.)
Between Google's admissions and the evidence in the case, Oracle has proven that Google
infringes Oracle's copyrights by copying the SSO of the 37 Java API packages into Android.
C. Google Infringed By Copying Java Code Into Twelve Android Code
Google admits that it copied protected Java code into twelve Android code files. The only
issue here is whether the copying was de minimis. As explained below, it was not.
1. Direct Copying
There is not dispute that Google copied Java code and comments into twelve Android code files. (TX 1072.) As reflected in the jury instructions, Google admits copying the code:
With respect to the infringement issues concerning the rangeCheck and other similar files, Google agrees that the accused lines of code and comments came from the copyrighted material.
(ECF No. 1018, JI 27.) With respect to the rangeCheck code within the TimSort.java and ComparableTimSort.java files, Josh Bloch, who authored the code while working at Sun, acknowledged the likelihood that he copied that code from Sun copyrighted code. (RT 827:5-17.) Dr. Mitchell confirmed that the accused code and comments in the twelve Android files are identical to the copyrighted Java code and comments (RT 1254:1-1255:15, 1258:24-1260:18, 126:2-1263:10 (Mitchell)), and Google did not offer any testimony to rebut this.
2. Google's Code Copying Was Not De Minimis
Copying can only be de minimis “if it is so meager and fragmentary that [compared to the work as a whole] the average audience would not recognize the appropriation." (ECF No. 1018, JI 28.) Fisher v. Dees, 794 F.2d 432 n.2 (9th Cir. 1985). The extent of the copying "is measured by considering the qualitative and quantitative significance of the copied portion in relation to the plaintiff's work as a whole." Newton v. Diamond, 388 F.3d 1189, 1195 (9th Cir. 2003); see also Merch. Transaction Sys., Inc. v. Nelcela, Inc., 2009 U.S. Dist. LEXIS 25663, at *61 (D. Ariz. Mar. 17, 2009) ("Thus, Nelcela will not escape liability unless it can show that the protectable elements in the Lexcel software constitute an insignificant (quantitatively and
qualitatively) portion or aspect of the Lexcel software"). Even if the copied material is a
"quantitatively very small part" of the work as a whole, "[t]he smallness alone is not enough by
itself to avoid liability." Mktg. Tech. Solutions, Inc. v. Medizine LLC, 2010 U.S. Dist. LEXIS
50027, at *10 (S.D.N.Y. Apr. 23, 2010).
Under the Court's jury instructions, the copied code and comments in the twelve Android
files must be compared to the contents of the corresponding Java files from which the copied
material came. (ECF No. 1018, JI 29.) Professor Mitchell provided detailed and uncontested
testimony that Google literally copied either the entirety of the accused files or a qualitatively
significant portion. Google has made no showing that the copied code was "so meager and
fragmentary" that it would not be recognized as an appropriation. Under the appropriate
comparison, no reasonable jury could find that Google's code copying was de minimis.
a. Google's Copying of Eight Decompiled Files Was Not De
During trial, Professor Mitchell explained that Google decompiled eight Java files and
copied the decompiled source code into certain Android files. (RT 1258:7-1259:15 (Mitchell);
TX 1072, 896.1-896.8, 1031-1038.) Google does not dispute that these files were copied. (ECF
No. 1018, JI 27.)
When compared on a file-to-file basis (per the Court's jury instructions), it is clear that
Google's copying of the eight files was not de minimis. Google copied each entire file, so by
definition, the copying is both quantitatively and qualitatively significant. (See RT 1260:11-1262:1 (Mitchell); compare TX 896.1-896.8 (Sun decompiled files) with TX 1031-38 (Android
files).) No reasonable jury could find that the copying of the decompiled files was de minimis.
b. Google's Copying of the RangeCheck Method Was Not
Professor Mitchell testified that the rangeCheck method is qualitatively significant and
"useful" to Android. (RT 1316:17-19.) He explained that the rangeCheck method operates on
Android devices, including on Samsung phones. (RT 1255:22-25, 1264:19-23.) To determine
how useful the rangeCheck method is on devices, Professor Mitchell experimented with an
Android device and found that it called the rangeCheck method no less than 2,600 times during
start up. (RT 1329:9-21.) Google did not present any testimony to rebut this.
c. Google's Copying Of Comments Was Not De Minimis
Professor Mitchell compared Oracle's CodeSource.java file (TX 623.9) against Android's
CodeSourceTest.java file (TX 1039) and concluded that, except for some HTML commands,
certain English-language comments are "syntactically . . . identical." (RT 1262:13-1263:4.) He
reached the same conclusion with respect to Android's CollectionCertStoreParametersTest.java
file. (RT 1253:9-10; compare TX 1040 (Android) to TX 623.10 (Java)). These literally copied
comments are quantitatively significant: they amount to about 25% of Oracle's
CollectionCertStoreParameters.java file (TX 623.10), and about 2.90% of Oracle's
CodeSource.java file (TX 623.9).
D. Google Infringed By Copying From Java Specifications Into Android
The Court submitted to the jury the question of whether Google has infringed Oracle's
copyrights by copying the English-language descriptions of API elements from the Java
specifications into the Android specifications. (ECF No. 1018, JI 21.) The Court did not submit
the issue of whether the SSO of the 37 API packages, as expressed in the Java specifications, was
also copied into the Android specifications. These issues should be considered together. Oracle
is entitled to judgment on both of these issues, based on the weight of the evidence.
1. The Evidence Shows That Android’s English-Language
Android developer Bob Lee testified that the English-language descriptions within the Android specifications were paraphrased from Sun’s specifications and were therefore
“substantially similar.” (RT 1191:4-13.) He was shown three examples of such paraphrasing, and he acknowledged that the same level of similarity evident in those examples exists across the full documentation for the 37 Java API packages within Android. (RT 1175:25-1176:3; TX 26 610.2, 767 (full Android and Java documentation).) One of the examples is shown below:
Descriptions Were Copied From The Java API Specifications.
Mr. Lee expressed regret that such paraphrasing had occurred:
| J2SE 5.0|| Android|
A pair of channels that implements a
A pipe consists of a pair of channels: A writable sink channel and a readable source channel. Once some bytes are written to the sink channel they can be read from source channel in exactly the order in which they were written.
|A pipe contains two channels, forming a unidirectional pipe. One is the writable sink
channel, and the other is the readable source
channel. When bytes are written into the writable channel they can be read from the readable channel. Bytes are read in the order in which they were written.|
I actually wasn't even a big fan of including these. I would have preferred that we
just point people to Sun's site for this specific documentation because you
shouldn't really be rewriting a contract. And in doing so they are going to be
(RT 1175:25-1176:3.) Mr. Lee's admission that the English-language descriptions in the Android
specifications were paraphrased from the Java specifications is evidence of direct copying, which
entitles Oracle to judgment on this point.
2. Evidence Also Shows That Google Copied The SSO Of The
While the Court only submitted the issue of English-language description copying to the
jury, Google is also liable for copying the SSO of the Java API packages into the Android
documentation. The facts are uncontroverted and Oracle is entitled to judgment on this issue.
Java API Packages From Java Specifications Into Android
There is no question that Google copied the SSO of the 37 Java API packages into the
Android documentation. As explained by Dr. Reinhold, the structure expressed in the API
documentation is the same as the structure within the compilable code because the code is run
through the Java Documentation Extractor (or "Javadoc") to pull out the structure and English
language comments to produce a webpage that reflects the same SSO of the API that is in the
code. (RT 606:14-608:3 (Reinhold); TX 1046 at p.19.) The Android documentation is created
the same way from the Android code. (RT 1169:8-15 (Lee agreeing that like Java documentation,
Android documentation was "created by a tool that actually reads portions of the source code and
then places it in a kind of template that's available on the web as a source of documentation.").)
It is undisputed that the SSO of the 37 Java API packages is identical in both the Java and
Android code and documentation. (ECF No. 984 at 10 (Google's JMOL motion: "As such, if
based on the same starting point the names of the 37 API packages at issue the structure,
sequence, and organization of the Android and Java documentation inevitably will be the same."))
Regardless of whether the SSO is expressed in the compilable code or the API
documentation, it is protectable expression in both cases. See, e.g., Situation Mgmt. Sys., Inc. v.
ASP Consulting Group, 560 F.3d 53, 61 (1st Cir. 2009) ("creative choices [in training manuals] in
describing those processes and systems, including the works' overall arrangement and structure,
are subject to copyright protection" even when describing uncopyrightable system); CDN Inc. v.
Kapes, 197 F.3d 1256, 1262 (9th Cir. 1999) (prices in guide for collectible coins); Jacobsen v.
Katzer, 2009 U.S. Dist. LEXIS 115204, at *9-10 (N.D. Cal. Dec. 10, 2009) (text files reflecting
decoder information from model railroad manufacturers).
As currently presented to the jury, it is possible Google will be found liable for copying
the SSO into the Android code, but not liable for copying the very same SSO into Android
specifications. That makes no sense. Oracle is entitled to judgment on both forms of copying.
E. Google's Copying Is Not Fair Use
As the Court instructed the jury, Google had the burden to prove its fair use defense based
on the four factors identified in 17 U.S.C. § 107(1). (ECF No. 1018, JI 26.) As demonstrated
below, consideration of those factors weighs overwhelmingly against a finding of fair use.
Because no reasonable juror could find based on the trial evidence that Google has met its burden,
Oracle is entitled to judgment as a matter of law on Google's fair use defense.
1. Google's Use Of The Copyrighted Work Is Purely Commercial
The first fair use factor--"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(1))--
weighs entirely against a finding of fair use. Google exploits Oracle's copyrighted work for
significant commercial gain, and its use of the work is not "transformative."
And Not "Transformative"
a. Google's Use Is Purely Commercial
"Although not controlling, the fact that a new use is commercial as opposed to non-profit
weighs against a finding of fair use." Elvis Presley Enters. Inc. v. Passport Video, 349 F.3d 622,
627 (2003). As explained by the Supreme Court:
"[Every] commercial use of copyrighted material is presumptively an unfair
exploitation of the monopoly privilege that belongs to the owner of the copyright."
Sony Corp. of America v. Universal City Studios, Inc., 464 U.S. [417, 451 (1984)].
... The crux of the profit/nonprofit distinction is not whether the sole motive of the
use is monetary gain but whether the user stands to profit from exploitation of the
copyrighted material without paying the customary price.
Harper & Row Publishers, Inc. v. Nation Enters., 471 U.S. 539, 562 (1985) (citations omitted);
see also Passport Video, 349 F.3d at 627 ("[T]he degree to which the new use exploits the
copyright for commercial gain--as opposed to incidental use as part of a commercial enterprise--
affects the weight we afford commercial nature as a factor").
In Harper & Row, the Court found that the first factor weighed against a news magazine's
use of quotes from Gerald Ford's unpublished presidential memoir because of the magazine's
"stated purpose of scooping the forthcoming hard cover and Time abstracts" and despite its "not
purely commercial" purpose of "news reporting." 471 U.S. at 562. Similarly, in Passport Video,
the Ninth Circuit upheld the district court's finding that the first factor weighed against fair use
for television performance excerpts in a broadcast Elvis Presley biography, despite
acknowledging that "[i]t would be impossible to produce a biography of Elvis without showing
some of his most famous television appearances for references purposes." 349 F.3d at 629.
Here, unlike in Harper & Row or Passport Video, it is undisputed that Google's use of the
Java APIs is purely for commercial purposes. Google has "profit[ed] from exploitation of the
copyrighted material without paying the customary price" (Harper & Row., 471 U.S. at 562) and
24 "exploit[ed] the copyright for commercial gain" (Passport Video, 349 F.3d at 627).
Google's distribution of the Android platform is to increase use of Google services, which
generate advertising revenue for Google. (RT 1458:12-16 (Schmidt). Google copied the 37 Java
API packages in order to capture a large developer community and penetrate the market more
quickly. (See RT 1783:15-22 (Bornstein) ("The goal of the project was to provide something that
was familiar to developers"). Indeed, the evidence showed that Android was hugely profitable.
(RT 1458:12-16; 1456:15-19 (Schmidt); 2225:18-2226:24 (Agrawal).) One Google internal
document described how Android and Chrome were "critical" platforms for five different Google
business units, each one identified as a $10 billion opportunity for Google. (TX 431 at 3.) This
evidence of Google's purely commercial use of the Java APIs weighs heavily against fair use.
b. Google's Use Was Not Transformative
Google argues that even though its use of the Java APIs was purely commercial and
highly exploitative, its use was "transformative." This argument fails as a matter of law because
Google has presented no evidence to support a conclusion that its use of Java APIs is
"transformative" within the meaning of controlling case law.
The leading case on "transformative" use is Campbell v. Acuff-Rose Music, Inc., 510 U.S.
569 (1994). Campbell, which involved a claim of fair use in a song parody, held that "parody,
like other comment or criticism, may claim fair use under § 107." 510 U.S. at 579. Ninth Circuit
cases following Campbell have emphasized that "transformative" is intended to refer to a work--
like a criticism or a parody--that has a purpose entirely different from the original and is not
intended to apply to a competing work with a parallel object or purpose. For example, in Kelly v.
Arriba Soft Corp., 336 F.3d 811 (9th Cir. 2003), in holding that a search engine operator's use of
"thumbnail" pictures of copyrighted images was "transformative" fair use, the court explained
[T]he thumbnails were much smaller, lower-resolution images that served
an entirely different function than Kelly's original images. Kelly's images are
artistic works intended to inform and to engage the viewer in an aesthetic
experience . . . . Arriba's use of Kelly's images in the thumbnails is unrelated to
any aesthetic purpose.
336 F.3d at 818 (emphasis added).
Similarly, in Perfect 10, Inc. v. Amazon.com, Inc., 487 F.3d 701 (9th Cir. 2007), which
followed Kelly and held that Google's search engine "thumbnail" photographs were
"transformative" uses of the plaintiff's photographs and hence fair use, the Ninth Circuit
emphasized that the search engine used the photographs for an entirely different function:
Although an image may have been created originally to serve an entertainment,
aesthetic, or informative function, a search engine transforms the image into a
pointer directing a user to a source of information . . . . [A] search engine provides
social benefit by incorporating an original work into a new work, namely, an
electronic reference tool . . . . In other words, a search engine puts images in a
different context so that they are transformed into a new creation.
487 F.3d at 721 (emphasis added) (internal citations and quotations omitted).
In Leadsinger, Inc. v. BMG Music Publ'g, the Ninth Circuit started its analysis by
considering whether the allegedly transformative use of copying song lyrics for karaoke fell
within the statutory examples. 512 F.3d 522, 530 (9th Cir. 2008). The Court concluded it did
not, and emphasized that "Leadsinger's basic purpose remains a commercial one to sell its
karaoke device for a profit. And commercial use of copyrighted material is `presumptively an
unfair exploitation of the monopoly privilege that belongs to the owner of the copyright.'" Id. at
530 (citation omitted).
Here, unlike the parody in Campbell, Google's use of the copied materials in Android is
nothing like "the examples given in the preamble to § 107." See 17 U.S.C. § 107. Nor is its use
for "an entirely different function" (Kelly, 336 F.3d at 818) or "in a new context to serve a
different purpose" (Perfect 10, 487 F.3d at 722). It is for the same intrinsic purpose--supplying
core library APIs in a software platform--as used in the Java platform, but in a competing
product. Google simply copied the SSO of the 37 Java API packages over into Android, to serve
the same purpose that it does in Java. (RT 2184:22-2185:9 (Astrachan) ("that structure of the
names of the classes, packages, and methods needs to be the same so that the code will work on
both platforms").) There is nothing "transformative" about that use.
Nor can the fact that Android is a smart phone platform render Google's use
"transformative." There is nothing new or "transformative" in the fact that Android is a
smartphone platform: the uncontroverted evidence at trial established that Java technology is
used in the RIM Blackberry smartphones, and was used in the Danger Sidekick/Hiptop
smartphones and Nokia's Series 60 phones. (RT 959:20-23 (Swetland); 1585:21-23 (Rubin);
300:18-19 (Ellison); 383:6-9 (Kurian); 1102:3-10 (Cizek); 1922:22-25 (Gering).)
If Google's argument were accepted, the idea of "transformation" would swallow up
copyright protection: anyone claiming to have a better business model for distributing the
copyrighted work would be able to copy it, sell it, and claim "fair use." Movie makers would be
hard-pressed to enforce their copyrights against infringing distributors where there were no
previous distributors; book publishers could not enforce against e-Book publishers if they were
not already distributing e-Books; musicians could not enforce against FM or satellite radio
stations if their songs were broadcast only on AM stations. This is not the law. As the Ninth
Circuit noted in Perfect 10:
[D]uplicating a church's religious book for use by a different church was not
transformative. See Worldwide Church of God v. Phila. Church of God, Inc., 227
F.3d 1110, 1117 (9th Cir. 2000). Nor was a broadcaster's simple retransmission of
a radio broadcast over telephone lines transformative, where the original radio
shows were given no "new expression, meaning, or message." Infinity Broad.
Corp. v. Kirkwood, 150 F.3d 104, 108 (2d Cir.1998).
487 F.3d at 722.
Here, Google took the SSO of 37 Java API packages that are implemented by Oracle, or
by others under license, from the Java documentation and computer software and copied it into
the Android documentation and computer software. This is not "an entirely different function"
(Kelly, 336 F.3d at 818); it is the same function and "the same intrinsic purpose" (Worldwide
Church of God, 227 F.3d at 1117). Google's parallel use of the Java APIs is thus not
"transformative" as a matter of law.
2. The Copyrighted Work Is Creative In Nature
The second factor—“the nature of the copyrighted work”—favors creative expression. Though computer programs are generally “utilitarian” and “functional,” “[t]o the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer’s choice of program structure and design may be highly creative and idiosyncratic.” Sega, 977 F.2d at 1524.
Witness after witness testified to the highly creative nature of API design. Larry Ellison testified that API design is “arguably, its one of the most difficult things we do at Oracle. . .done by our most senior experienced and talented software engineers.” (RT 289:25-291:16.)
Numerous other witnesses confirmed that API design is very complex, requiring significant
design choices and creativity. (RT 513:12-18 ("[designing API's] is a very creative process");
513:21-514:12; 515:14-23 (Screven); 627:21-628:1 (Reinhold); 741:9-742:3; 747:5-9; 748:7-13;
752:5-14; 831:17-832:4 (Bloch); 1220:6-12; 1238:11-1239:12; 1240:17-20 (Mitchell); 1775:3-16
(Bornstein); 2209:7-8 (Astrachan) ("Q: Is it difficult to write good APIs? A: Yes.")).
Google's chief Java architect, Joshua Bloch, testified that:
API design is really a creative process. There are many, many kinds of decisions
that go into API design. Often, the people who do API design are called software
(RT. 1238:13-15; see also TX 624 at 2, 20-21, 47 (Bloch presentation entitled "How to Design a
Good API and Why it Matters.").)
3. Google Uses Valuable, Core Portions Of Copyrighted Work
The third statutory factor is "the amount and substantiality of the portion used in relation
to the copyrighted work as a whole." 17 U.S.C. §107(3). "This factor evaluates both the quantity
of the work taken and the quality and importance of the portion taken." Passport Video, 349 F.3d
In Harper & Row, the Supreme Court overruled the Court of Appeals and found that the
use of 300 words out of 200,000 from Gerald Ford's unpublished presidential memoir was not
fair use, emphasizing that "[t]he portions actually quoted were selected . . . as among the most
powerful passages in those chapters." 471 U.S. at 565-66. The Court also cited favorably Roy
Export Co. Establishment v. Columbia Broad. Sys., Inc., 503 F. Supp. 1137, 1145 (S.D.N.Y.
1980), which held that a jury could reasonably have held that the defendant's use of short excepts
from Charlie Chaplin films chosen for a broadcast program about Chaplin because they were
among the best moments, was both "quantitatively substantial" and "qualitatively great" (503
F.Supp. at 1145). Harper & Row, 471 U.S. at 565 ("taking of 55 seconds out of 1 hour and 29-minute film deemed qualitatively substantial").
The Court has ruled that for purposes of fair use analysis, "the `work as a whole' means
the contents (including name, declarations and English-language comments) of the documentation
for all of the 166 API packages (not just the 37) in the registered work." (ECF No. 1018, JI 29.)
Thirty-seven out of 166 packages--more than 22%--is a sizeable percentage of the work as a
whole and significant quantitatively. This 22% represents an extraordinary amount of work. (See
RT 617:2-15 (Reinhold) (testifying that the specifications for the 37 API packages amount to
about 11,000 pages when printed out), 1248:11-1249:7, 2279:16-2280:6 (Mitchell) (testifying that
the 37 API packages included "around 400 classes" and about "5,000 methods").)
Google also cannot dispute that the APIs it took were qualitatively significant. Mr.
Bornstein testified that these 37 API packages in particular were the most suited for smartphones
and the ones that Google believed developers would use and expect. (RT 1782:6-9, 1783:23-1784:1 (Bornstein); 981:22-982:21 (Lee); 1331:10-15 (Mitchell).) For these reasons, the third
statutory factor cuts strongly against fair use.
4. Google's Use Harms The Potential Market For And Value Of
The final fair use factor--"the effect of the use upon the potential market for or value of
the copyrighted work" (17 U.S.C. § 107(4))--"is undoubtedly the single most important element
of fair use." Harper & Row, 471 U.S. at 566. "Fair use, when properly applied, is limited to
copying by others which does not materially impair the marketability of the work which is
copied.'" Id. at 566-67, quoting 1 Nimmer § 1.10[D], at 1-87. In assessing the fourth factor, it is
necessary to "consider not only the extent of market harm caused by the particular actions of the
alleged infringer, but also `whether unrestricted and widespread conduct of the sort engaged in by
the defendant . . . would result in a substantially adverse impact on the potential market' for the
original." Campbell, 510 U.S. at 590.
The Copyrighted Work
The first and fourth factors are powerfully connected because, as the Supreme Court has
held, the proof required to demonstrate present or future market harm (the fourth factor) varies
with the purpose and character of the use (the first factor):
A challenge to a noncommercial use of a copyrighted work requires proof either
that the particular use is harmful, or that if it should become widespread, it would
adversely affect the potential market for the copyrighted work. . . . If the intended
use is for commercial gain, that likelihood [of market harm] may be presumed.
But if it is for a noncommercial purpose, the likelihood must be demonstrated.
Sony Corp. v. Universal City Studios, Inc., 464 U.S. 417, 451 (1984) (cited in A&M Records,
Inc. v. Napster, Inc., 239 F.3d 1004, 1016 (9th Cir. 2001). See also Leadsinger, at 532 ("we have
not hesitated to apply this presumption"); Passport Video, 349 F.3d at 631. As noted above in
discussing the first factor, it is uncontested that Google's use of the Java APIs is purely
commercial in nature and has greatly enhanced Google's very substantial Android profits.
Undisputed evidence at trial also established that Google's infringing use of the Java API
packages substantially impaired the value of the Java Platform. Google's Technical Program
Manager for Android testified that the number of Android-compatible device activations per day
was on average 750,000, and each of those devices has the 37 API packages from Java. (RT
1017:4-16 (Morrill).) Google's Android phones compete directly with Java smart phones (such
as the RIM Blackberry) that were on the market prior to Android's introduction. (RT 1922:22-25
(Gering); see also RT 2062:5-12 (McNealy) (testifying that while he was the Chairman of the
Board at Sun, Sun had a "very lucrative revenue stream from J2ME, which was the handset
version of Java.") 2057:24-2058:14 (McNealy).)
Google has also significantly harmed the value of the APIs by fragmenting Java and
undercutting its "write once, run anywhere" capability. (TX 172 (email from Bornstein to Rubin
describing Android as a "fork" of Java); RT 2287:13-2288:5 (Mitchell) (testifying that beyond the
37 API packages, Android and Java "are different and incompatible, and the way in which things
are prepared to run and execute is different"); see also RT 984:22-24; 981:19-21 (Lee); 1010:1-7
(Morrill) (testifying that Android is not Java compatible).
Google knows this fragmentation is harmful. Google itself imposes terms requiring
Android users to refrain from fragmenting its APIs. (TX 749 at 8-9 (Android Compatibility
Definition Document).) Moreover, both Larry Page, CEO and co-founder of Google, and Tim
Lindholm, Google engineer and former Sun Distinguished Engineer, testified that they knew that
Sun was concerned about fragmentation of Java. (RT 471:6-18 (Page); 844:3-7 (Lindholm).)
Google seeks to use "compatibility" to justify what was actually a deliberate fragmenting of a
compatible ecosystem that Sun, Oracle and many other companies spent years nurturing.
No reasonable jury could find that Google has met its burden of fair use, and Oracle is
therefore entitled to JMOL on that defense.
IV. OTHER ISSUES THAT ARE NOT BEING PRESENTED TO THE JURY
A. Oracle Is Entitled To Judgment As A Matter Of Law On
Oracle understands that the Court will be determining copyrightability of the 37 API
packages based upon the evidence submitted at trial. At the Court's request, the parties will be
submitting proposed findings of fact and conclusions of law to the Court on Wednesday, May 2.
Oracle will set forth the evidence at trial that relates to copyrightability in greater detail in that
submission, which it incorporates by reference here. Nonetheless, out of an abundance of
caution, and because Oracle believes it is entitled to judgment on copyrightability as a matter of
law, Oracle addresses the issue of copyrightability here as well.
The evidence on copyrightability presented at trial was overwhelming. Fact and expert
witnesses from both sides testified that designing APIs is a creative and challenging task. (See
RT 2209:7-8 (Astrachan); 1238:13-16 (Mitchell); 627:21-629:5 (Reinhold); 513:14-18 (Screven);
751:14-18, 830:18-19, 831:7-12 (Bloch); see also TX 624 at 47 (Bloch presentation).) Nobody
testified to the contrary.
The API packages themselves are expressed in a detailed and complex structure, with
many hierarchies and interdepencies. These were illustrated in part in TX 1028, the Java API
package poster used by developers when programming for J2SE version 5.0. The intricate
structure of the API packages poster reflects only the high level class and interface relationships
for some of the API packages in version 5.0, because it would be impossible to fit a description of
all the relationships even on a large poster with tiny print. RT 599:15-600:3 (Reinhold). These
relationships extend within and across the different packages. The types of relationships that
were shown at trial included the following: (1) classes can have one or more subclasses, each of
which inherits the methods and fields of the classes above it in the hierarchy (RT 1225:10-16
(Mitchell)); (2) interfaces are used to relate different classes that share common characteristics
among different classes located in the same, or different packages (RT 589:13-17, 590:5-23,
601:22-25 (Reinhold)); (3) methods can contain parameters that are defined in other classes
located within, or outside, the package in which the method is found (RT 1239:24-1240:8
(Mitchell)); (4) classes and subclasses can be contained within the hierarchy of one package but
defined in another (RT 601:14-24 (Reinhold)); (5) interfaces themselves are often arranged
hierarchically in a manner similar to classes (RT 1219:14-23 (Mitchell)).
The detailed expression of this structure cannot possibly be just an idea, as Google has
sometimes claimed. Nor is it driven or constrained by function as Google has also contended.
Dr. Reinhold testified that very little structure is required for the APIs to operate with the virtual
machine or computer. If function were the only concern, all of the classes could have been placed
in a one giant package. (RT 619:13-23). A primary purpose of the structure, sequence and
organization of the APIs is to make them easy to learn and easy for developers to use. (RT
619:24-620: 6 (Reinhold); RT 741:2-742:2 (Bloch); TX 624 at 4.)
Google has argued in the past that the doctrines of merger and scenes a faire apply to bar
copyrightability of APIs. The Court warned Google on summary judgment of the standard it
would have to meet if it hoped to establish this. The Court stated that:
If Google believes, for example, that a particular method declaration is a scene a
faire or is the only possible way to express a given function, then Google should
provide evidence and argument supporting its views as to that method
declaration. ... This approach ignores the possibility that some method
declarations (for example) may be subject to the merger doctrine or may be scenes
a faire, whereas other method declarations may be creative contributions subject to
copyright protection. Google has not justified the sweeping ruling it requests.
Google has not even identified which categories of specification elements it deems
unprotectable under these doctrines. This order declines to hold that API package
specifications, or any particular category of elements they contain, are
unprotectable under the merger or scenes a faire doctrines.
(ECF No. 433 at 9.) Google's evidence at trial was no better. Indeed, Google chose to not even
try to meet this standard; it submitted no evidence whatsoever to establish that any particular
method declaration was a scene a faire or was the only possible way to express a given function.
Nor could it have. It is obvious, given the complexity of the structure, that there are
countless ways to design and express the Java API packages, so the doctrine of merger does not
apply. See Satava v. Lowry, 323 F.3d 805, 812 n.5 (9th Cir. 2003) ("Under the merger doctrine,
courts will not protect a copyrighted work from infringement if the idea underlying the
copyrighted work can be expressed in only one way, lest there be a monopoly on the underlying
idea"). Dr. Reinhold testified that "In anything except the most trivial API design, there are so
many choices to be made that I wouldn't even know how to start counting them." (RT 627:21-628:1 (Reinhold); see also id. at 628:22-629:6 (discussing design options for java.nio). Professor
Mitchell agreed, emphasizing that API design starts with a "clean slate." (RT 1240:9-20.) No
Google witness disputed this.
Google also did not put on any evidence at trial to establish scenes a faire. "Under the
scenes a faire doctrine, when certain commonplace expressions are indispensable and naturally
associated with the treatment of a given idea, those expressions are treated like ideas and
therefore not protected by copyright." Swirsky v. Carey, 376 F.3d 841, 850 (9th Cir. 2004).
Google never tried to establish this for any one of the 37 API packages, let alone all of them. The
evidence in the record is that APIs solving the same kinds of problems can be designed very
differently. Dr. Reinhold gave the example of the java.util.logging API package, which has
different relationships, interfaces, names and elements from a competing open source Java
logging API called Log4J. (RT 630:11-631:18 (Reinhold).) Dr. Mitchell discussed how data
collections are handled in different ways in APIs in Java, C++ and Smalltalk, and how even
within Java, the design of the Java.util package has changed significantly over time. (RT
1240:23-1244:16 (Mitchell).) In pretrial briefing, Google stated that it was "reserving the right to
present evidence that many aspects of the APIs are unoriginal." (ECF No. 823 at 9.) It never did.
The many creative choices exercised by API designers extend not just to the structure, but
to the decision as to what to include in the API in the first place, and even whether to include a
particular API package in the library. Since the API packages are just pre-written code supplied
for the benefit of developers, there is no set requirement that any particular API be included. The
Java API packages have grown dramatically, from the seven API packages that were included in
the first release, to the 166 packages included with version 5.0, to 209 packages included with
version 7.0. (RT 631:19-25 (Reinhold).) Dr. Reinhold testified that Sun and Oracle did not have
to create so many Java API packages, but did so "in order to to encourage the adoption of the
Java platform by adding more and more facilities to make it an attractive platform for developers
to use." (Id. at RT 632:1-6.) Other software platforms have taken a different approach. For
example, C is one of the world's most popular programming languages, but Dr. Reinhold testified
that "the C Standard Library is really very simple and primitive" and does not even contain basic
data structures." (Id. at RT 632:7-20.)
The Court should also issue judgment as a matter of law in Oracle's favor on the
copyrightability of the selection and arrangement of the names in the 37 Java APIs. The Court
expressly left this issue open on summary judgment. (ECF No. 433 at 8.) The evidence showed
that the choice of names is significant, and that API designers thoughtfully selected thousands of
names for aesthetic purposes and consistency. (RT 628:2-21 (Reinhold)); TX 624 (Bloch
presentation) at 7 ("Code should read like prose.").) (RT 746:20-748:13 (Bloch).) The names, of
course, are organized within the same complex and creative structure as the API elements they
label, and Oracle's selection and arrangement of those names should be found copyrightable. See
Lamps Plus, Inc. v. Seattle Lighting Fixture Co., 345 F.3d 1140, 1147 (9th Cir. 2003 ("[A]
combination of unprotectable elements is eligible for copyright protection only if those elements
are numerous enough and their selection and arrangement original enough that their combination
constitutes an original work of authorship.").
Google has contended in the past that the 37 API packages are simply a "functional
requirement for compatibility." This is not the correct legal standard, but Google still failed to
meet it. As discussed above, the API package designs are not simply functional, and the
undisputed evidence at trial is that Android is not compatible with Java in any event. (See, e.g.,
RT 1007:6-11 (Morrill); TX 383 at 8; RT 1331:16-1332:2 (Mitchell).) The API packages are not
like a hardware interface that Google had to adopt if it wanted to use the Java programming
language. Google designed many of its own API packages, and the experts agreed that Google
could have designed its own corresponding 37 API packages if it wanted to. (RT 2212:25-2213:19, 220:1-7 (Astrachan); 2288:6-13 (Mitchell).) Only about 60 classes must be present in
the APIs for the Java language to function, and for most of those classes there is no requirement
that the class contain any particular method or methods -- the language simply expects that a
class by that name will exist. (RT 684:16-685:2 (Reinhold); 2196:1-4 (Astrachan); TX 1062; TX
Finally, as discussed in section II.D.2 above, numerous witnesses testified at the trial that
the structure, sequence and organization of the API packages is identical in the documentation
and the class libraries because both are derived from the source code. The SSO of the source
code falls squarely within the Ninth Circuit's holding in Johnson Controls, 886 F.2d at 1175.
The written description of this highly expressive structure contained in the documentation is no
less protectable than the expression of the structure in the source code. The structure, sequence
and organization is copyrightable in both formats. It would be a perverse result if Google were
found to infringe one but not the other.
In sum, based on the uncontroverted evidence presented at trial, the Court can grant
judgment as a matter of law on copyrightability in Oracle's favor.
B. Google Infringed Oracle's Copyrights By Deriving Its
The Android source code implements the functions specified in the English descriptions
of Oracle's copyrighted specifications, and it also incorporates the SSO of the 37 Java API
packages as described in the specifications. By copying the SSO and implementing the prose
descriptions of the Java API specifications, converting from English text into Java-language code,
Google has created an unauthorized derivative work.
Implementations Of The 37 API Packages From Java Specifications
A "derivative work" is defined as "a work based upon one or more preexisting works,
such as a translation . . . or any other form in which a work may be recast, transformed, or
adapted." 17 U.S.C. § 101. Ninth Circuit law supports Oracle's derivative works claim. In
Micro Star v. Formgen, Inc., 154 F.3d 1107, 1112 (9th Cir. 1998), the seller of new levels for a
video game claimed it had not copied any protectable expression from the game's creator because
its level files "reference the source art library, but do not actually contain any art files
themselves." Id. at 1112. The Ninth Circuit disagreed, finding that "[i]n making this argument,
Micro Star misconstrues the protected work. The work that Micro Star infringes is the D/N-3D
story itself." Id. The court thus reversed the district court's denial of a preliminary injunction.
See also Twin Peaks Prods. v. Pul'n Int'l Ltd., 996 F.2d 1366, 1373-74 (2nd Cir. 1993) (finding
detailed recounting of plot elements of television series was infringement)
Similarly, Google's argument that the implementing source code in Android copies only
unprotectable ideas from Oracle's specifications misconstrues Oracle's derivative works claim.
Professor Mitchell testified that the narrative in the Oracle API specifications is reflected in the
Android source code: "[T]he narrative is reflected in the source code because the source code is a
program that in a sense carries out that narrative, does what the explanation requires for this
method." (RT 1253:16-18 (Mitchell).) Google's expert, Dr. Astrachan, acknowledged that the
Android source code was "based on the specification." (RT 2219:7-18 (Astrachan).) That
admission tracks the very definition of a "derivative work" in the Copyright Act: "A `derivative
work' is a work based upon one or more preexisting works . . . ." 17 U.S.C. § 101.
Oracle is not claiming that Google is liable for implementing any single method or even a
group of methods. Google is liable for implementing the entire SSO of the 37 Java API packages,
including the methods described therein. Even if Google were correct that the implementation
steps of a given method are an uncopyrightable idea--the same way that individual plot elements
in a film might be uncopyrightable--Google implemented Oracle's descriptions thousands of
times in the same structure, sequence, and organization in which Oracle wrote them. "[A] claim
of copyright infringement can be based on infringement of a combination of unprotected
elements." Dream Games of Ariz., Inc. v. PC Onsite, 561 F.3d 983, 988 (9th Cir. 2009). No
reasonable fact finder could conclude that Google did not derive the SSO, as well as the meaning,
of the code for the Android core libraries from Oracle's API specifications. Google's expert
Professor Astrachan testified that corresponding elements in Java and Android APIs are
structured, sequenced, and organized in the same way:
Q. It has to be in the same position in the application programming interface structure,
sequence and organization, correct?
(RT 2215:24-2216:2 (Astrachan).) He further testified that the method declarations in the
Android code are like the detailed headings in an outline:
A. That is correct.
Q. And the method declarations are like the sub-sub-sub-chapter headings in this
structure, sequence and organization; correct, sir?
(RT 2215:2-5 (Astrachan).) Google copied Oracle's detailed outline into the Android code.
A. I think that's one analogy that's reasonable.
Google's argument that it was required to copy to use the Java language fails. With the
exception of a very few classes, the Java APIs are not required to use Java at all. (RT 684:16-685:2 (Reinhold).) Google could have written its own APIs that provided similar functionality, as
Professor Astrachan testified: "it would be possible to provide an API that performed similar
functionality; not maybe exactly the same but similar." (RT 2213:8-10 (Astrachan).) Google
actually did write many of its own APIs. (See RT 2213:17-19 (Astrachan) (noting that Android
developers wrote most of their own core libraries).) Google did not have to copy.
Nor did "compatibility" compel Google's copying. Android is not, in fact, compatible
with Java. (See TX 383 at 8 ("Q49. Is Android Java compatible? A. No.").) As Google engineer
Dan Bornstein testified, Google did not even attempt full compatibility with the Java platform:
Q. Did Android implement all the API packages present in any particular Java Platform?
(RT 1783:15-22 (Bornstein).) True compatibility with Java would have required Google to
incorporate all of the Java API packages, not just some. (RT 374:4-24 (Kurian).) Accordingly,
Google cannot use compatibility to excuse copying a select set of API packages into Android.
Q. All right. And why not?
A. That wasn't a goal of the project. The goal of the project was to provide something that
was familiar to developers. It wasn't to provide any particular preexisting set of packages.
C. Google's Equitable Defenses Fail
Google has failed to carry its burden of establishing its equitable defenses of waiver,
estoppel, implied license, and laches. These defenses will be addressed in Oracle's Findings of
Fact and Conclusions of Law to be filed on May 2, 2012, which Oracle incorporates herein by
For the foregoing reasons, Oracle is entitled to judgment in its favor on its copyright
infringement claim and against Google on Google's defenses.
Dated: May 1, 2012
MICHAEL A. JACOBS
MARC DAVID PETERS
DANIEL P. MUINO
MORRISON & FOERSTER LLP
By: /s/ Michael A. Jacobs
Michael A. Jacobs
Attorneys for Plaintiff
ORACLE AMERICA, INC.
With respect to specification copying, the Court only submitted the issue of whether
English-language descriptions were copied. (ECF No. 1018, Jury Instruction ("JI") 21.) As
discussed further below, Oracle reiterates its position that the descriptions should not be viewed
in isolation and that the specifications also express the SSO of the 37 API packages which was
copied into Android's code and specifications. Judgment can be granted on this issue as a matter
2 Oracle maintains its objection to the Court's use of the virtual identity test for evaluating
the copying of the API specifications. (See ECF No. 1016 at 2.)
This issue will be addressed in more detail in Oracle's Findings of Fact and Conclusions
of Law regarding issues for the Court to resolve, to be filed on May 2, 2012. Oracle incorporates
that discussion herein by reference.