decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
Day 3, Patent Phase of Oracle v. Google Trial, Oracle's [Mostly] Denied Motion For JMOL on Fair Use, as text ~ pj Updated 3Xs
Friday, May 11 2012 @ 09:54 AM EDT

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

__________

I. INTRODUCTION

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

1

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.

2

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.

1. Originality

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

3

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?

A. Yes.

(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?

A. Yes.

4

(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?

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.

(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.

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.

5

(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 defendant").

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

6

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 Files

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

7

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 Minimis.

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 De Minimis.

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

8

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 Specifications

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
Descriptions Were Copied From The Java API Specifications.

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:

9

J2SE 5.0 Android
A pair of channels that implements a unidirectional pipe.

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.
Mr. Lee expressed regret that such paraphrasing had occurred:

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 substantially similar.
(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
Java API Packages From Java Specifications Into Android Specifications

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.

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.").)

10

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
And Not "Transformative"

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."

11

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

12

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 that,

[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:

13

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).)

14

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.)

15

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 architects.
(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 at 630.

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.)

16

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 Copyrighted Work

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 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.

17

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.

18

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
Copyrightability.

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,

19

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,

20

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

21

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

22

class by that name will exist. (RT 684:16-685:2 (Reinhold); 2196:1-4 (Astrachan); TX 1062; TX 984.)

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
Implementations Of The 37 API Packages From Java Specifications

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.

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.

23

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?

A. That is 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:

24

Q. And the method declarations are like the sub-sub-sub-chapter headings in this structure, sequence and organization; correct, sir?

A. I think that's one analogy that's reasonable.

(RT 2215:2-5 (Astrachan).) Google copied Oracle's detailed outline into the Android code.

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?

A. No.

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.

(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.

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 reference.

V. CONCLUSION

For the foregoing reasons, Oracle is entitled to judgment in its favor on its copyright infringement claim and against Google on Google's defenses.

25

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.

_______________
1 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 of law.

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.)

3 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.

26


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )