Oracle America, Inc. v. Google Inc.
Filing
1048
REPLACED BY CORRECTED PROPOSED FINDINGS OF FACT #1049 Proposed Findings of Fact by Oracle America, Inc.. (Holtzman, Steven) (Filed on 5/2/2012) Modified on 5/3/2012 (mjj2, COURT STAFF).
1
2
3
4
5
6
7
8
&
C A L I F O R N I A
S C H I L L E R
B O I E S ,
10
O A K L A N D ,
F L E X N E R
L L P
9
11
12
13
14
15
16
17
18
MORRISON & FOERSTER LLP
MICHAEL A. JACOBS (Bar No. 111664)
mjacobs@mofo.com
MARC DAVID PETERS (Bar No. 211725)
mdpeters@mofo.com
DANIEL P. MUINO (Bar No. 209624)
dmuino@mofo.com
755 Page Mill Road, Palo Alto, CA 94304-1018
Telephone: (650) 813-5600 / Facsimile: (650) 494-0792
BOIES, SCHILLER & FLEXNER LLP
DAVID BOIES (Admitted Pro Hac Vice)
dboies@bsfllp.com
333 Main Street, Armonk, NY 10504
Telephone: (914) 749-8200 / Facsimile: (914) 749-8300
STEVEN C. HOLTZMAN (Bar No. 144177)
sholtzman@bsfllp.com
1999 Harrison St., Suite 900, Oakland, CA 94612
Telephone: (510) 874-1000 / Facsimile: (510) 874-1460
ALANNA RUTHERFORD (Admitted Pro Hac Vice)
arutherford@bsfllp.com
575 Lexington Avenue, 7th Floor, New York, NY 10022
Telephone: (212) 446-2300 / Facsimile: (212) 446-2350
ORACLE CORPORATION
DORIAN DALEY (Bar No. 129049)
dorian.daley@oracle.com
DEBORAH K. MILLER (Bar No. 95527)
deborah.miller@oracle.com
MATTHEW M. SARBORARIA (Bar No. 211600)
matthew.sarboraria@oracle.com
500 Oracle Parkway, Redwood City, CA 94065
Telephone: (650) 506-5200 / Facsimile: (650) 506-7114
Attorneys for Plaintiff
ORACLE AMERICA, INC.
19
UNITED STATES DISTRICT COURT
20
NORTHERN DISTRICT OF CALIFORNIA
21
SAN FRANCISCO DIVISION
22
ORACLE AMERICA, INC.
23
Plaintiff,
24
v.
25
GOOGLE, INC.
26
Defendant.
Case No. CV 10-03561 WHA
PLAINTIFF’S PROPOSED FINDINGS
OF FACT AND CONCLUSIONS OF LAW
Dept.: Courtroom 8, 19th Floor
Judge: Honorable William H. Alsup
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
1
This matter was tried to the Court and a jury from April 16, 2012 to April 30, 2012. The
2
Court, having duly considered the evidence in this action, now finds the following with respect to
3
the issues that were tried to the Court:
4
I.
5
PROPOSED FINDINGS OF FACT REGARDING OWNERSHIP
1.
Sun Microsystems, Inc. (“Sun”) obtained copyright registrations on the Java
6
platform and the JDK from the Copyright Office, including copyrights in J2SE 1.2 Beta 2, 1.2,
7
1.3, 1.4, 5.0, and 6.0 Platforms, and the “Java Application Programming Interface, Volume 1
8
Core Packages” book.
9
TX 475, 450, 451, 452, 453, 454, 455, 460, 461, 462, 463, 464, 476, 509, 513,
518, 520, 521, 523, 524, 526, 598, 599, 601, 602, 603, 659 (registration
certificates)
ECF No. 525 (Stipulated Facts 15-16 (J2SE 1.4 and 5.0).)
10
11
12
13
2.
copyright registrations incorporate by reference Sun’s copyright registrations for prior versions.
14
TX 3529 (J2SE 5.0);
TX 3530 (J2SE 1.4)
RT 2233:6-2234:20; 2234:20
15
16
J2SE 1.4 and J2SE 5.0 were both registered as derivative works, and both the
3.
Under the heading “Materials Added to this Work,” the copyright registration for
17
J2SE 1.4 lists “New and revised computer code and accompanying documentation and manuals.”
18
The registration was accompanied by a hard copy partially redacted excerpt of source code for
19
java.nio and included a CD-ROM entitled Java ™ 2 SDK Standard Edition Documentation 1.4.0.
20
TX 3530
Reinhold at RT 2233:6-2234:20.
21
22
4.
Similarly, under the heading “Materials Added to this Work,” the copyright
23
registration for J2SE 5.0 lists “New and revised computer code and accompanying documentation
24
and manuals.” The registration was accompanied by a hard copy excerpt of source code from the
25
J2SE 5.0, and included a CD-ROM containing the binary code and documentation for J2SE 5.0.
26
TX 3529
Reinhold at RT 2234:20-2238:19
Dare at RT 2257:5-2266:25
TX 1076, 1077, 1078, 1081
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
1
1
2
5.
The individual code files from which Google copied are all part of the source code
for J2SE version 5.0.
3
Reinhold at RT 693:1-695:9
TX 623.1-10
4
6.
Sun changed its name to “Oracle America, Inc.” when Oracle Corporation
5
purchased Sun. Oracle America is the plaintiff in this action.
6
ECF No. 525 at 8 (Stipulated Fact 3)
7
7.
Google has submitted no evidence showing that the registrations cover anything
8
other than what they purport to claim.
9
8.
Google has submitted no evidence that the registered code differs from what was
10
identified at trial.
11
II.
PROPOSED FINDINGS OF FACT REGARDING COPYRIGHTABILITY
12
9.
Class libraries in Java are software libraries of prewritten code that can be reused
13
by software developers in a wide variety of different programs. There are over 400 classes
14
containing prewritten code segments, contained in the 37 accused API packages of the class
15
16
17
libraries for J2SE Version 5.0.
Reinhold at RT 584:10-585:15
Mitchell at RT 1248:13
10.
Java Application Programming Interfaces (“APIs”) are documentation, sometimes
18
referred to as specifications, that describe the many elements that make up the class libraries and
19
the relationships among them.
20
Reinhold at RT 585:16-586:6
21
11.
The Java API packages describe the structure of the class libraries, the names of all
22
the elements, and includes English prose that describes how every element is expected to work.
23
The class libraries contain the compiled code.
24
Reinhold at RT 592:18-23
25
12.
The 37 API packages asserted in this lawsuit are java.awt.font, java.beans, java.io,
26
java.lang, java.lang.annotation, java.lang.ref, java.lang.reflect, java.net, java.nio,
27
java.nio.channels, java.nio.channels.spi, java.nio.charset, java.nio.charset.spi, java.security,
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
2
1
java.security.acl. java.security.cert, java.security.interfaces, java.security.spec, java.sql, java.text,
2
java.util, java.util.jar, java.util.logging, java.util.prefs, java.util.regex, java.util.zip, javax.crypto,
3
javax.crypto.interfaces, javax.crypto.spec, javax.net, javax.net.ssl, javax.security.auth,
4
javax.security.auth.callback, javax.security.auth.login, javax.security.auth.x500,
5
javax.security.cert, and javax.sql
6
TX 1072
7
8
13.
The java.net.ssl API package is used for creating secure transactions over the
internet. The package java.sql is used for accessing a wide variety of relational databases.
9
Reinhold at RT at 6:16:2-24
10
14.
11
Android incorporates APIs for the 37 Java packages asserted in this lawsuit.
TX 51
12
15.
The Java APIs for the 37 packages at issue include thousands of individual
13
elements, organized into packages, classes, interfaces, exceptions, constructors, methods, and
14
fields. The designers of the Java APIs for these packages selected the elements and arranged
15
them into a complex structure, sequence and organization.
16
Reinhold at RT 589:2-18, 628:22-629:6, 585:16-586:6, 621:7-622:5, 634:1-25
TX 1028
Mitchell at RT 1238:13-1239:12, 1248:11-1249-1, 2283:9-20
TX 624 at 23-26
17
18
16.
19
There is an intricate relationship of hierarchies and dependencies among Java API
20
elements within and across packages. These are illustrated in part in the Java API package poster
21
used by developers when programming for J2SE version 5.0.
Mitchell at RT 2283:6-20
Reinhold at RT 586:7-603:6
TX 1028
22
23
17.
24
25
26
27
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 extremely small
print.
Reinhold at RT 599:11-600:3
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
3
1
2
18.
There is a hierarchical relationship among classes. Classes can have one or more
subclasses, each of which inherits the characteristics of the classes above it in the hierarchy.
3
Reinhold at RT 588:5-11
Mitchell at RT 1218:15-19, 1225:10-16
4
19.
5
There are many other types of relationships among classes, interfaces, and
6
packages that include connections within and across packages. Interfaces, for example, can be
7
used to relate different classes that share common characteristics that are located in different
8
packages.
Reinhold at RT 589:13-18, 590:5-23, 601:22-25
9
20.
10
Methods can contain parameters that are defined in other classes located within,
11
or outside, the package in which the method is found. Methods can also return members of other
12
classes.
Reinhold at RT 602:4-603:6
13
14
21.
Classes and subclasses can be contained within the hierarchy of one package but
15
defined in another.
Reinhold at RT 601:14-21
Mitchell at RT 1221:24-1222:2
16
17
22.
Interfaces themselves are often arranged hierarchically in a manner similar to
18
classes.
19
Mitchell at RT 1219:14-23, 1236:19-1237:2
20
23.
The structure, sequence and organization (“SSO”) of the 37 Java API packages are
21
expressed in both their specifications and the implementations. The specifications describe the
22
SSO of the Java API implementations, and are used by developers to understand and use the
23
implementation.
24
Reinhold at RT 619:16-620:6
Mitchell at RT 1236:3-1237:8; 1234:9-17
Bornstein at RT 1843:3-1844:1
25
26
27
28
24.
In Java, the SSO is the same for the API specifications and the implementations
because both are derived from the same source code. The English language comments and
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
4
1
declarations are extracted from the source code using a tool called javadoc. The source code is
2
also compiled into executable byte code for the implementation by a compiler.
3
Reinhold at RT 607:2-608:3
Reinhold at RT 613:3-614:10
Mitchell at RT 1228:2-9
Mitchell at RT 1332:14-1333:8
Mitchell at RT 1257:3-13
Mitchell at RT 1236:19-1237:2
4
5
6
7
8
25.
Similarly, in Android, the Android specifications have the same SSO as the
implementations because both are derived from the same source code.
9
Lee at RT 1169:8-15
Bornstein at RT 1841:11-15
10
26.
The source code and documentation for the 37 accused Android API packages
11
have the same selection, structure, sequence and organization described in the documentation and
12
source code for the 37 Java API packages at issue.
13
Astrachan at RT 2214:22-2215:5 (SSO of the method declarations are the same in
Java and Android)
Astrachan at RT 2215:24-2216:2 (method signatures are in the same location
within the SSO in both Java and Android)]
Reinhold at RT 606:14-16 (the structure of the Java APIs is “exactly the same” as
the structure of the Java class libraries)
Reinhold at RT 606:18-608:3 (structure of names is same as structure of source
code because the Java Documentation Extractor pulls names from source code)
Mitchell at RT 2282:17-24
Mitchell at RT 2286:9-16
14
15
16
17
18
19
20
21
27.
span 11,000 pages, filling three and a quarter banker’s boxes.
Reinhold at RT 617:2-15
22
23
The printed copy of the documentation for the 37 Java API packages in suit would
28.
The individual elements included in the Android source code and described in the
24
Android documentation perform the same functions as their corresponding elements in the Java
25
source code that are described in the Java documentation.
Astrachan at RT 2219:7-18 (“I would write source code based on the
specification.”)
Mitchell at RT 1253:16-18 (the “narrative” of the documentation is reflected in the
source code)
26
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
5
1
Mitchell at RT 2282:17-2283:2 (“The declarations on the left are literally copied
into the code, and that represents not just the names, but where they related as far
as the hierarchy”)
Bornstein at RT 1836:19-1837:2 (Android team looked at Java specifications to
derive information from them to write code)
2
3
4
29.
Designing APIs is an activity that requires significantly creativity and skill.
Astrachan at RT 2209:7-8
Mitchell at RT 1238:13-18
Reinhold at 627:21-629:5
Screven at RT 513:14-18; see also 516:24-517:3
Bloch at 751:14-18
TX 624 at 47
9
30.
No witness testified at trial that API design is not creative.
10
31.
“Designing a good API is tough” “[l]ike any work of craftsmanship.”
5
6
7
8
Bloch at RT 751:14-18; see also 830:18-19; 831:7-12
11
12
32.
Bloch at RT 741:23-742:3, 743:1-3, 743:12-18, 746:9-16; 748:17-22
13
14
15
33.
“In anything except the most trivial API design, there are so many choices to be
made” that an engineer “wouldn’t even know how to start counting them.”
16
17
APIs are works of authorship.
Reinhold at RT 627:21-628:23
34. “Original, as the term is used in copyright, means only that the work was independently
18
created by the author (as opposed to copied from other works), and that it possesses at
19
least some minimal degree of creativity.” Feist Publ’ns, Inc. v. Rural Tel. Serv. Co.,
20
499 U.S. 340, 345(1991). The selection, structure, sequence and organization of the 37
21
API packages in suit constitutes original, creative expression. (FOF _-_.)
22
23
35.
experienced and talented software engineers.”
24
25
26
Java API design is a task that is often assigned to a company’s “most senior
Ellison at RT 291:11-16
36.
The selection, structure, sequence and organization of the elements of the APIs for
the 37 packages at issue represent years of original and creative design.
27
Screven at RT 516:24-517:3 (the API for the 37 packages “reflect creative
design”)
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
6
1
Reinhold at RT 687:25-688:13 (Sun has been developing APIs since 1996; APIs
for the 37 packages have “evolved over time”)
Mitchell at 1243:4-1244:16 (evolution of java.util)
2
3
37.
It took almost two years for Chief Java Architect Mark Reinhold, working with
4
other engineers, to develop the APIs for java.nio and its related sub-packages when he was at
5
Sun.
6
7
8
Reinhold at RT 623:17-624:1; 627:21-629:6
38.
a set of APIs that developers said “changed their life.”
9
Bloch at RT 750:5-21
Bloch at RT 772:25-773:6
10
11
12
39.
15
Mitchell at RT 1240:23-1244:16
40.
Reinhold at RT 518:4-519:15; 630:11-631:18
Screven at RT 290:15-291:6
17
19
20
41.
23
24
25
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.
Reinhold at RT 631:19-25
21
22
Third parties have created totally different APIs for Java that accomplish similar
things to Oracle’s Java APIs
16
18
The collections APIs in other development environments such as C++ and
Smalltalk are structured very differently.
13
14
The collections framework, which is in the asserted Java API package java.util, is
42.
The complex structure of the Java APIs for the 37 packages at issue and their
associated implementations is not required in order for the Java APIs or their implementations to
operate with the virtual machine or computer. A primary purpose of the selection structure,
sequence and organization of the APIs is to make them easier for programmers to learn and use.
Reinhold at RT 597:9-17
Reinhold at RT 595:20-596:18
Reinhold at RT 606:14-21
Bloch at RT 741:2-742:3
26
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
7
1
2
3
4
5
6
7
8
9
10
TX 624 at 4
43.
aesthetic considerations, not just function.
Reinhold at RT 627:21-628:1 (“so many choices to be made I wouldn’t know how
to start”)
Reinhold at RT 597:9-13 (java.nio “could have had many alternative structures.
As we worked on this design, many different ideas were suggested and
evaluated.”)
Reinhold at RT 628:22-629:6
Bloch at RT 746:9-16
TX 624
Reinhold at RT 68:21-629:6
44.
The “aesthetics of an API design are part of this noble and rewarding craft” of
designing a Java API.
11
12
Writing Java APIs involves multiple design choices and requires attention to
Bloch RT at 752:5-11
45.
When designing an API, the engineer must consider not only the functionality that
13
is required by the potentially large number of users, but also a “complex web of classes [to] lay
14
out and design” and “the implication[s] for the underlying implementation.”
15
Screven at RT 513:21-514:12; see also 515:14-23 (need to understand what is
required to implement, otherwise the API may be unimplementable, very slow, or
cumbersome to build)
16
17
46.
Oracle and Sun had many choices for what elements to include in the 37 Java API
18
packages and how to structure them. It was not required to structure them in any particular way.
19
Reinhold at RT 630:11-631-18 (different structures for logging packages)
Mitchell at RT 1240:23-1244:16 (different structures for collections and java.util)
20
21
22
47.
commonplace, and was not an indispensable or standard way of expressing any idea.
23
Reinhold at RT 630:11-631:18
Mitchell at RT 1240:23-1242:25, 1243:6-1244:16
24
25
26
The structure, sequence and organization of the Java API packages is not
48.
Functionality did not dictate the organization of the API packages in suit. If
function were the only concern, all of the classes could have been placed in a one large package.
Reinhold at RT 619:13-23
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
8
1
2
49.
selected thousands of names for aesthetic purposes and consistency.
3
Reinhold at RT 628:2-21
TX 624 (Bloch presentation) at 7 (“Code should read like prose.”)
Bloch at RT 746:20-748:13
Mitchell at RT 1248:14-20
4
5
6
The choice of names is significant, and the Java API designers thoughtfully
50.
The Java API packages are distinct from the Java programming language. The
7
programming language is described in the Java Language Specification (“JLS”). Only about 60
8
classes are required by the programming language, and, except Object, none are specified in
9
detail in the JLS.
TX 1062 at 1-2
Reinhold at RT 676:14-678:13
Reinhold at RT 684:16-685:2
Astrachan at RT 2196:1-4
TX 984
10
11
12
13
51.
Google did not need to copy Oracle’s Java APIs for these 37 packages to make
14
use of the Java programming language. Google designed many of its own API packages for
15
Android and could have designed its own APIs for these packages as well.
16
Mitchell at RT 2288:6-12
Astrachan at RT 2212:25-2213:19, 2220:1-7
Reinhold at RT 518:4-519:15; 630:11-631:18
17
18
19
20
21
52.
Android is not compatible with Java. Google “supersetted” and “subsetted” the
Java APIs—adding in its own APIs for other packages that are not included in Java and failing to
include APIs for other packages that are present in Java. As a result, many applications written
for Java will not run on Android, and many applications written for Android will not run on Java.
22
Mitchell at RT 1331:16-1332:2, 2287:23-2288:5
Morrill at RT 1007:6-11
TX 383 at 8
23
24
25
26
27
53.
Oracle and Sun did not dedicate the APIs to the public domain. They consistently
included copyright notices on the Java API specifications. These copyright notices were included
in the books that published early versions of the specifications and are prominently featured on
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
9
1
the website that contains them. Copyright notices are also included in the source code for the
2
class libraries.
3
TX 610.1 at 1 (Specification license)
TX 610.2 (Java API web documentation with copyright notice)
TX 980 at 6 (The Java Programming Interface Volume I)
TX 981 at 6 (The Java Programming Interface Voume II)
TX 18 at 1, 3/24/2006 email from Andy Rubin to Greg Stein
TX 623 at lines 151-152 (Java Source Code)
Reinhold at RT 695:11-697:19
4
5
6
7
54.
Sun, and now Oracle, only make the APIs available through licenses. One type of
8
license is a specification license that allows for independent implementations of the APIs, but
9
only if the specification meets certain requirements.
10
Ellison at RT 293:16-295:6
Kurian at RT 370:6-381:25
TX 610.1
Cizek at RT 1071:4-17
TX 1026
11
12
13
55.
The specification license was included in the books that published the API
14
specifications on the same page as the copyright notice.
15
TX 980 at 6
TX 981 at 6
16
17
18
56.
A link to the specification license is included next to the copyright notices on the
web pages that describe the API specifications.
19
Lee at RT 982:22-983:12
Reinhold at RT 671:9-25
Reinhold at RT 697:2-10
TX 610.2 (Java web documentation)
20
21
57.
Google deliberately chose to base the 37 accused packages in Android on the
22
corresponding design, including the structure, sequence and organization, of the 37 Java API
23
packages set forth in the Java API documentation and source code.
24
TX 30
Bornstein at RT 1827:19-1828:14; 1836:19-1837:7
Lee at RT 981:7-21; 984:25-985:18; 1174:2-16
Astrachan at RT 2214:22-2215:5; 2215:24-2216:2
25
26
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
10
1
III.
2
A.
Google’s Knowledge Of Sun Intellectual Property
58.
3
4
PROPOSED FINDINGS OF FACT REGARDING GOOGLE’S EQUITABLE
DEFENSES
Sun posted a notice of copyright on its Java specifications both online and in
books.
5
TX 984
TX 2564
TX 610.1
TX 610.2
6
7
8
9
10
59.
copyrighted, among other things, the method signatures, the specifications for the APIs, and the
code.
11
Swetland at RT 951:8-953:9 (Sun claimed copyright on method signatures)
TX 149 (5/31/2006: “Whatever happened to their ‘we own copyright on the
method signatures’ bullshit argument?”)
Bloch at RT 756:9-18 (Bloch was aware, while at Sun, that Sun regularly and
routinely attached copyright notices to both code and documentation)
Lee at RT 983:4-15 (Lee copied despite seeing copyright notices on the Java API
specifications when he consulted them)
12
13
14
15
16
Google executives and engineers responsible for Android knew that Sun
60.
The head of Android, Andy Rubin, knew that Sun copyrighted the Java APIs: He
17
wrote that “java.lang apis are copyrighted” and that “[S]un gets to say who they license the
18
[TCK] to.”
TX 18 at 1 (java.lang apis are copyrighted)
Rubin at RT 1356:6-19
19
20
21
61.
Andy Rubin believed that APIs are not copyrightable, and admitted that his belief
was based on “folklore.”
22
Rubin at RT 1746:13-1747:8 (folklore)
23
62.
Andy Rubin and other Android team members knew Sun’s license requirements
24
from their prior work at Danger, Inc. Danger created an implementation of the Java specification,
25
using no Sun source code. Danger complied with Sun’s requirement to take a Java license and
26
conform to the Java standard.
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
11
1
Swetland at RT 948:24-950:15 (Swetland had no contact with Sun source code,
but Danger took a license and achieved compatibility)
Swetland at RT 952:22-953:9 (“I knew that at one time [Sun claimed that the
method signatures were copyrighted] while I was at Danger”)
Swetland at RT 953:19-954:7 (identifying Danger employees at Android)
Rubin at RT 1587:10-1588:2 (Danger took license and had clean room
implementation)
TX 1026 (Sun-Danger license)
Cizek at RT 1054:21-1059:14, 1062:16-1064:14, 1071:4-17 (Rubin had been told
about Sun’s requirements about all Java implementations and that Danger
eventually entered into a license)
TX 610.1 (J2SE 5.0 Specification License)
2
3
4
5
6
7
8
9
63.
Andy Rubin in particular had been informed of Sun’s licensing requirements
multiple times by Sun employees, through his negotiations both at Danger and at Google.
10
TX 565 at 2 (8/2/07: Gupta: “Andy cannot say he was not aware of the licensing
requirements - as he had to go thru this at Danger - and we discussed this during
Project Android Phase, and then during the Sun/Google collaboration attempt as
well.”)
11
12
13
14
64.
permitted Google to use Sun technology, including the APIs in suit.
15
TX 1 at 9 (7/26/2005: “Must take license from Sun”)
TX 3 at 3 (7/29/2005: Google needs “a TCK license”)
TX 7 at 1 (10/11/2005: “My proposal is that we take a license”)
TX 12 at 1 (12/20/2005: “Either a) we’ll partner with Sun as contemplated in our
recent discussions or b) we’ll take a license”)
TX 17 at 1 (2/10/2006: “critical license”)
16
17
18
19
20
65.
TX 1 (7/26/2005: “Developing a clean-room implementation of a JVM . . . Must
take license from Sun.”)
TX 12 (12/20/2005: Rubin: “My reasoning is that either a) we’ll partner with Sun
as contemplated in our recent discussions or b) we’ll take a license.”)
TX 10 (8/6/2010: Long after ‘clean room’ completed, “We conclude that we need
to negotiate a license for Java”)
TX 610.1 (specification license; available on all specifications)
22
23
24
25
27
Google knew that it needed a license even if it did not partner with Sun and
developed a “clean room” implementation instead, i.e. without Sun code.
21
26
In 2005 and 2006, Sun and Google negotiated for a license that would have
66.
The evidence shows that all other companies that developed an independent
implementation of the Java technology took a license.
28
Ellison at RT 293:8-294:21
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
12
1
2
Kurian at RT 385:20-386:8
67.
3
TX 2 at 1 (7/26/2005: “sergey: Application delivery part of APIs? (Yes, but actual
delivery is a negotiation)”)
Page at RT 500:23-501:2 (“And in that conversation that you participated in and is
memorialized in this e-mail that you got a copy of in 2005, what Sergey was
talking about was a negotiation with Sun about APIs. That’s clear; isn’t it, sir? A.
Yeah.”)
4
5
6
7
8
68.
TX 9 (10/13/2005: “Alan presumably wants this both for tactical reasons (preserve
TCK and implementation revenue, defend franchise against fragmentation which
is his main threat for long-term erosion” “He just needs to be compensated for
collateral short-term revenue loss and get comfortable that this won’t allow Google
or anyone else to run away with the platform”)
TX 125 at 1 (10/26/05 Lindholm: “If we don’t show strong efforts toward avoiding
fragmentation we are also going to have much more trouble from Sun”)
TX 612 at 2 (11/21/2005: “Had a quick call with Andy Rubin . . . there are three
key pillars we care about: 1) Compatibility – we want to be sure we are
minimizing fragmentation)
TX 7 at 1 (10/11/2005: “My proposal is that we take a license . . . We’ll pay Sun
for the license and the TCK. Before we release our product to the open source
community we’ll make sure the JVM passes all TCK certification tests so that we
don’t create fragmentation.”)
TX 213 (4/5/2006: Lindholm comments on draft license agreement, and states,
“The fact that the definition of Commercial Stack includes the words ‘subsetted
and/or supersetted’ is significant in that these are special words for Sun, some of
the key things that they have historically resisted going open to prevent.’”)
10
11
12
13
14
15
16
17
18
19
21
69.
Google knew that compatibility was a core proposition of Java and that Sun
worked actively to prevent fragmentation.
22
TX 7
TX 9
TX 125
TX 612
TX 1048
Page at RT 471:6-18
Ellison at RT 296:2-4
Kurian at RT 381:15-25
23
24
25
26
27
In 2005 and 2006, Sun expressed concern about the potential for fragmentation
and informed Google of the requirement of platform and API compatibility in its licenses.
9
20
In 2005, Google and Sun specifically negotiated for a license to Sun’s APIs.
70.
Google knew that “Java had very little fragmentation.”
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
13
1
2
TX 21
71.
Google hired numerous former Sun engineers, including Tim Lindholm, who
3
represented to Andy Rubin in 2005 that he should be a “project advisor” for Android because he
4
was familiar with the “legal ecosystem.”
5
TX 321 (8/9/2005: Lindholm to Rubin: “I think my main value would be as J2ME
runtime generalist and interpreter of the engineering/business/legal ecosystem.”)
TX 1 (7/26/2005: “Google/Android, with support from Tim Lindholm, negotiates
the first OSS J2ME JVM license with Sun”)
6
7
8
72.
Additionally, Google executives and engineers responsible for Android knew
9
about the requirements of Sun’s specification license, because Google was a member of the JCP,
10
and participated directly in Sun’s dispute with Apache.
11
Lee at RT 1186:2-16 (Apache never got license, never accepted FOU restriction)
Rubin at RT 1689:19-25 (knew Apache didn’t have a license from Sun)
Schmidt at RT 1541:3-7 (no right to use Sun IP as result of Apache license)
TX 273 at 1 (Rubin to Bornstein: Apache forbidden from ME versions)
TX 405 at 1 (Lee to Schmidt: Harmony “water under the bridge” for Android)
TX 1051 at 1 (Rubin agreeing to sign letter to Sun regarding Harmony)
TX 2347 (Letter to Schwartz regarding Harmony signed by Google representative)
Deemed Admission at RT 978:16-979:1 (FOU prevents TCK from being run on
mobile devices)
12
13
14
15
16
17
18
19
20
73.
Android’s Core Library Lead, Mr. Lee, told Mr. Schmidt that Sun prevented
“Apache Harmony from independently implementing Java SE (Harmony can’t put
those restrictions on their own users and still Apache license the code) not to
mention Android (though that’s water under the bridge at this point).”
21
TX 405
Lee at RT 986:5-987:19 (describing TX 405)
22
23
24
74.
27
Google also knew that Sun permitted open source projects only for “non-mobile
areas – areas where they don’t have a well defined revenue stream. Apache is an example.”
TX 7
25
26
Google knew that Apache Harmony could not be used in mobile devices because
75.
Apache had no license from Sun that would it allow it to distribute the Java APIs
commercially under the Apache license.
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
14
1
Kurian at RT 393:23-394:18; 396:3-9; 399:10-33
Screven at RT 523:25-525:3; 527:18-20
2
3
4
5
76.
on its website that Apache needed a TCK “to demonstrate compatibility with the Java SE
5specification, as required by Sun specification license for Java SE 5.”
TX 917 at 1
6
7
8
9
10
77.
contributors.” On December 9, 2010, Apache again publicly stated “that Java specifications are
proprietary technology that must be licensed directly from the spec lead.”
TX 1045 at 2 (Apache statement resigning from JCP)
TX 1047 at 6 (Apache open letter FAQ)
Lee at RT 1207:9-1209:20 (admitting he saw Apache resignation at the time)
12
13
Apache therefore itself recognized that the code it developed was not authorized to
be used commercially without a license from Sun.
14
16
In a “FAQ” accompanying the letter to Sun, Apache publicly stated that users of
Apache Harmony “wouldn’t be assured that they had all necessary IP rights from the spec’s
11
15
On April 10, 2007, Apache posted on its website a letter to Sun and acknowledged
78.
The evidence shows that no other companies use Apache Harmony in commercial
devices other than Google.
17
Kurian at RT 401:25-403:11
Screven at RT 530:11-24
Rubin at RT 1761:25-1762:6
18
19
20
79.
Bornstein 1837:21-1838 (“an awful lot of stuff came from Apache Harmony”)
21
22
23
80.
26
According to Google’s Executive Chairman Eric Schmidt, Google does not assert
that it has any rights to use any Sun intellectual property as the result of the Apache license.
Schmidt at RT 1541:3-25
24
25
Google nonetheless used Harmony code in Android.
81.
Eric Schmidt, then CEO of Google, “would have assumed” the TCK “was one of
the licensing requirements” of a Sun specification license for Java APIs.
27
Schmidt at RT 1559:5-11
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
15
1
2
3
4
5
6
7
82.
Google conducted no dependable investigation into whether it was infringing
Sun’s and then Oracle’s copyrights.
Swetland at RT 952:22-953:18 (did no investigation if method signatures still
copyrighted)
Schmidt at RT 1463:9-13 (no investigation about using Harmony for mobile)
Page at RT 466:3-6 (Page never asked anyone to investigate whether Google’s
engineers had copied)
Lee at RT 1209:21-1210:14 (Lee did not rely on the advice of legal counsel in
determining the legal permissibility of reimplimenting APIs)
B.
Sun’s Actions
83.
It was not Sun’s practice to permit incompatible implementations of the Java
8
9
10
specification, even if those implementations did not bear the Java brand.
TX 610.1 (J2SE 5.0 Specification License)
McNealy at RT 2055:22–2056:4 (“Was there ever a time, when you were
chairman of Sun, when it was Sun’s policy or practice to permit someone to
incompatibly implement API specifications, so long as they did not call it Java?
A. Uhm, our API licenses were all about compatibility for Java. So in the Java
space I – I don’t recall that that was ever a – a strategy that we pursued nor
allowed in the marketplace.”)
Cizek at RT 1071:4-7 (Sun’s practice was to require compatibility and commercial
use licenses)
Gupta at RT 2306:6-2307:14 (“QUESTION: A licensee was required to pass the
TCK, even if they didn’t want to use the Java brand; is that right? ANSWER:
Yes.”)
11
12
13
14
15
16
17
18
19
84.
commercial products and require them to take a license and make the implementation compatible.
20
Cizek at RT 1054:21-1059:14
Cizek at RT 1071:4-17
TX 1026 (Sun-Danger license)
21
22
23
Sun would contact companies that had released incompatible implementations in
85.
From 2005 up through the time of trial, Sun and now Oracle had ongoing
discussions with Google regarding Java licensing for Android.
24
TX 565
TX 1002
Cizek at RT 1071:23-1073:18
TX 1029 (Buchholz email reporting conversation with Cizek, Lindholm responds)
McNealy at RT 2065:14-2066:14 (ongoing discussions with Google)
TX 1074 (2010 Eustace email to Catz)
Catz at RT 2313:23-2314:7 (6/2010: Oracle told Android they needed a license)
25
26
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
16
1
2
Rizvi at RT 1941:20-1942:12 (3 mtgs with Rubin re: license for Java in Android)
86.
3
Page at RT 492:18-22 (“But I also say I’m not sure they’ve ever broken off.
Continue to have discussions to this day.”)
4
5
6
87.
9
10
TX 538 (emails from Gupta to Rubin)
TX 565 at 3
88.
open source certain portions of their own code if they used the GPL-licensed code.
Schwartz at RT 2021:16-23 (GPL is a “give and force back” license)
Ellison at RT 292:2-293:4
12
14
89.
Kurian at RT 387:13-388:3
Screven at RT 531:3-20
16
18
90.
The GPL did not suit Google’s business needs for Android, and Android did not
use GPL-licensed open source code.
TX 230
TX 154
Rubin at RT 1754:9-21
19
20
21
The GPL is not a business-friendly license, and most companies accordingly will
not take the GPL license to use the open-sourced version of the Java APIs, called OpenJDK.
15
17
By 2007, Sun had released its technology under a particular open source license,
the GNU General Public License (GPL), a “give and force back” license that requires users to
11
13
In 2007, before Google announced Android, Sun repeatedly tried to engage
Google in discussions on Java licensing for Android.
7
8
In fact, the Sun-Google negotiations never broke off.
91.
Before Google announced Android, Sun did not know what Google would do with
22
Android, or whether Google would require a commercial Java license for Android, or whether it
23
would use GPL code.
TX 565 at 3 (describing Google’s options and Sun’s strategy around each)
Schwartz at RT 2023:2-9 (“prior to the release of Android, we were presuming
they were going to be using GPL code”)
24
25
26
92.
On November 5, 2007, when Sun’s CEO responded to the announcement of
27
Android in a blog post, Google had not yet released the Android Software Development Kit
28
(“SDK”), and Sun therefore did not know the facts regarding Google’s infringement.
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
17
1
Morrill at RT 1041:14-16 (“ Q. But on November 5, 2007 Google had not released
the Android SDK, had it? A. That’s correct. The SDK was released a week
later.”)
2
3
4
5
93.
Google identified the APIs to be used in Android publicly.
Morrill at RT 1041:14-16 (“a week later” after November 5)
Schmidt at RT 1546:14-16 (“roughly correct” that you’d have to have the SDK to
know the APIs were in Android)
Rubin at RT 1702:22-1704:9 (eight days after Android announced, SDK released;
APIs were in the SDK)
6
7
8
9
10
94.
As of November 12, 2007, Sun’s CEO understood that Google might still agree to
certify Android as compliant with the Java specification.
11
12
Google released the SDK on November 12, 2007. This was the first time that
TX 1055
95.
On November 15, 2007, three days after Google released the Android SDK, Rich
13
Green, Executive Vice President of Software at Sun, publicly expressed concern regarding
14
Android and the incompatible set of APIs. He is quoted as stating:
15
16
“Anything that creates a more diverse or fractured platform is not
in (developers’) best interests.”
17
“The feedback from developers is, ‘Help us fix this.’”
18
“We’re really interested in working with Google to make sure
developers don’t end up with a fractured environment. We’re
reaching out to Google and assuming they’ll be reaching out to us
to ensure these platforms and APIs will be compatible so
deployment on a wide variety of platforms will be possible.”
19
20
21
TX 1048 (“Sun concerned Google’s Android will fracture Java”)
Rubin at RT 1725:23-1726:10 (acknowledging article; acknowledging that he saw
it at the time of Android’s release)
22
23
24
25
96.
When asked to comment on Mr. Green’s comments, Rubin responded to Google
internally that “[t]his is a very touchy subject.”
TX 180
Rubin at RT 1725:23-1726:10
26
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
18
1
2
97.
On May 23, 2008, Google Android employees received, circulated, and
commented on an article that reported on Sun’s continuing concern regarding Android:
4
“Sun Microsystems has expressed concern that Google’s development of Dalvik
could fragment the Java world so that Java software for running Android
applications wouldn’t work on other Java phones and vice-versa.”
5
TX 245
3
6
7
98.
In September and October 2008, prior to Google’s release of the Android platform,
Sun engaged in another round of discussions with Google.
8
TX 1002 (November 24, 2008 email from Rubin in which he wrote that Sun had
asked Google “to certify Android through the Java process and become licensees
of Java”)
9
10
11
12
99.
Android, and that Google needed to make Android compatible.
Cizek at RT 1071:23-1073:18 (conversation with Martin Buchholz at Google)
TX 1029
13
14
15
In April 2009, Sun communicated to Google that Google needed a license for
100.
Oracle has continued to express concern regarding Google’s use of Oracle’s
intellectual property in Android.
16
Kurian at RT 391:15-395:1
Rizvi at RT 1942:20-1943:1
Ellison at RT 304:23-305:8
Catz at RT 2309:15-2310:11
TX 2237 (Form CO, submitted to the EU, that notes that “Harmony project
(financed by IBM, Intel, Microsoft, Google, and others) and Google’s Android OS
are examples of Java’s fracturing.”)
17
18
19
20
21
101.
Sun’s words and actions in response to the Android announcement in November
22
2007 were neither intended to be, nor reasonably could be understood to be, an endorsement of an
23
Android that used only some of the Java SE APIs and that failed to comply with Sun’s licenses.
24
Schwartz at RT 1991:9-14
McNealy at RT 2059:2-2060:13 (Sun practice to require compatibility)
25
26
27
102.
From 2006 to the present, Sun’s actions in continuing a strategy of negotiation,
rather than litigation, were reasonable and consistent with its historical interactions with Google.
See cites for 63, 66, and 84 above.
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
19
1
2
103.
Sun did not intend to relinquish any rights with regard to its copyrights or
Android.
TX 563 (3/8/2007: “The Google thing is really a pain. They are immune to
copyright laws, good citizenship, they don’t share.”)
TX 565 (9/19/2007: “It will end up in a discussion around compatibility and
licensing around Java”)
TX 2371 (11/6/2007: “As for how they avoid these licenses, I don’t know”)
TX 1056 (3/26/2008: “take Java for Android, without attribution or contribution…
scroogle”)
TX 2070 (10/23/2008: “IP/patents hammer”)
TX 2362 (4/20/2009 “battles” with Android)
McNealy at RT 2065:14-2066:14 (ongoing discussions with Google)
3
4
5
6
7
8
104.
9
No credible evidence shows that Sun ever communicated to Google, expressly or
10
implicitly, that Sun was giving up any rights to assert legal claims against Google based on
11
Google’s use of the asserted Java APIs for Android.
105.
12
No credible evidence shows that Sun intended or expected that Google would
13
interpret Sun’s statements or conduct – including Sun’s repeated efforts to negotiate with Google
14
to take a Java license for Android – to mean that Google did not need such a license.
106.
15
16
copyrights in the Java APIs against Google.
107.
17
18
108.
Schwartz at RT 2033:12-24 (Sun was struggling due to the financial crisis before
Schwartz resigned)
McNealy at RT 2048:9-14 (Sun was struggling during the last years that McNealy
was chairman of the company)
22
23
25
The credible evidence cited above, as well as Sun’s financial difficulties in 2007 to
2009 explain any period of Sun’s delay in filing suit against Google.
21
24
Sun’s words and conduct were consistent with intent to enforce its rights to the
intellectual property at issue.
19
20
Sun never unequivocally or intentionally relinquished any known right to assert its
C.
Reliance
109.
Android was a “critical asset” for Google that is “hugely profitable.”
TX 431
TX 1091 (RT 2226:20-23 (Agarwal Dep.)
26
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
20
1
110.
In 2005, Google was concerned about the growing number of individuals using
2
mobile phones to search the internet and its ability to attract and retain those users. Android
3
would give Google more control of the user experience and built-in Google applications on
4
mobile phones.
5
TX 3215
TX 1
TX 10
6
7
111.
The vast majority of Google’s revenue at that time and today comes from search
8
revenue. A primary reason to have Android is that people will do more searches and Google
9
would get more money as a result.
10
11
12
Schmidt at RT 1458:12-16
112.
In 2005, 2006, and 2007 Google was under tremendous time pressure to beat
others, such as Microsoft, Symbian and Apple, into the smartphone market.
13
TX 6
Schmidt at RT 1-11
Bornstein at RT 1844:15 -1847:1
14
15
113.
Google knew that the time to market was crucial and using Java dramatically
16
accelerated their schedule, with other alternatives being suboptimal.
17
TX 15
TX 7
Page at RT 490:1-7
Schmidt at RT 1462:2-13
18
19
20
21
114.
In 2005 and 2006, Google stated in internal emails and presentations that Google
needed a license from Sun for Android.
22
TX 1 (7/26/2005: “Must take license from Sun”)
TX 3 (7/29/2005: “Google needs a TCK license”)
TX 7 (7/15/2005: “My proposal is that we take a license.”; License would require
passing TCK to go commercial”)
23
24
25
115.
However, Google did not want the obligations that the GPL and specifications
26
license imposed. The GPL terms required Google’s licensees to contribute back any additions to
27
Google’s code. The specification license required Google to create a compatible version of Java.
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
21
1
Schmidt at RT 2021:16-23
TX 610.1
See also cites in 89 above.
2
3
116.
4
5
Google announced Android on November 5, 2007.
Schmidt at RT 1546:5-7.
117.
Prior to Google’s public announcement of Android in November 2007, Android
6
executives and engineers acknowledged internally that launching Android without a license, as an
7
incompatible implementation, would place Google in an adversarial stance against Sun.
8
TX 7 at 2 (10/11/2005: “Do Java anyway and defend our decision, perhaps making
enemies along the way”)
TX 125 at 1 (10/26/05: Lindholm: “If we don’t show strong efforts toward
avoiding fragmentation we are also going to have much more trouble from Sun”)
TX 12 (12/20/2005: Rubin: “My reasoning is that either a) we’ll partner with Sun
as contemplated in our recent discussions or b) we’ll take a license. I think a
clean-room implementation is unlikely because of the teams prior knowledge, and
it would be uncharacteristically aggressive of us to position ourselves against the
industry.”)
TX 22 at 12 (4/21/2006: “What if we don’t do this deal?” … “Adversarial
Approach” or “Take a lesser license”)
TX 207 (5/11/2007: “They won’t be happy when we release our stuff”)
TX 565 at 3. (8/2/2007: Gupta: have sent emails to Andy re: need for Java
licensing)
9
10
11
12
13
14
15
16
17
118.
18
Mitchell at RT 1331:16-20 (Google’s Android is not really compatible with Java
because they supersetted and subsetted APIs)
TX 383 at 8 (11/6/2007: “Is Android Java compatible? No.”)
Morrill at RT 1010:4-7 (“Now, [A]ndroid does not support Java applications,
correct? A. That is correct. Q. And so Android is not Java compatible, correct? A.
That’s correct.”)
19
20
21
22
23
119.
26
Google decided to use the APIs \in mid-2006 to early 2007—before Jonathan
Schwartz’s blog post on November 5, 2007.
24
25
Android was not and is not compatible with Java.
Bornstein at RT 1850:4-1851:2
120.
Android head Andy Rubin only “vaguely” remembers any comments by Sun after
the announcement of Android.
27
Rubin at RT 1446:23-1447:8
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
22
1
2
3
4
121.
statement by Sun in making any decision regarding the technology to include in Android.
122.
Rubin at RT 1725:21-1726:10 (discussing press article on November 15, 2007,
after the SDK was announced: “Sun concerned Android will fracture Java”)
TX 180 (11/15/2007: re: article, Sun’s concerns are a “touchy subject”)
6
8
After November 2007, Google knew Sun had expressed concern regarding
Android, and in particular Google’s use of a subset of the Java APIs for Android.
5
7
No credible testimony shows that before November 5, 2007, Google relied on any
123.
Shortly before releasing the Android SDK and afterwards, Google attempted to
hide its infringement by removing the word “Java,” which it called the “j word,” from Android.
9
TX 26 at 1 (11/17/2007 “Scrub out a few more J’s)
TX 104 (5/12/08 Remove j word from everywhere)
TX 233 at 1 (8/5/2009 “How aggressive do we scrub the J word?”)
10
11
12
13
124.
Android to certain authorized individuals and avoid references to Java.
14
TX 382
TX 165
TX 217
15
16
In November 2007, Google took steps to limit public discussions regarding
125.
In January 2008, Google made public presentations that included a graphic that
17
described the Android core libraries as “Core Java libraries.” Google later changed this graphic
18
to delete the word “Java.”
19
TX 34
TX 43.1
20
21
22
126.
Android to any Sun employees or lawyers.
23
24
In March 2008, Google took steps to prevent its employees from demonstrating
TX 29 at 1 (3/24/08: don’t demonstrate to any sun employees or lawyers)
127.
On May 23, 2008, Google Android employees received, circulated, and
25
commented on an article that reported on Sun’s continuing concern regarding Android. That
26
article stated:
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
23
1
“Sun Microsystems has expressed concern that Google’s development of Dalvik
could fragment the Java world so that Java software for running Android
applications wouldn’t work on other Java phones and vice-versa.”
2
3
TX 245
Morrill at RT 1043:1-10 (saw that others had reported that Sun had concerns; had
no conversations with Sun at all)
4
5
128.
In May 2008, Google employee Bob Lee informed Google CEO Eric Schmidt
6
about the dispute regarding Sun licensing for Apache’s Harmony project, but wrote that was
7
“water under the bridge” for Android.
8
TX 405
9
10
11
129.
In September through November 2008, Google engaged in additional negotiation
with Sun regarding Android, and that discussion included the possibility of buying Java from
Sun.
12
TX 203
TX 183
TX 1002
13
14
15
130.
In January and February 2009, Google considered the possibility of buying Java
from Sun, including Sun’s Java copyrights, in part because it would prevent lawsuits.
16
Schmidt at RT 1559:20-23; 1560:10-12
TX 406 (1/29/09 buying full rights – solve all of these lawsuits we’re facing)
TX 326 (2/20/2009: Lindholm has a good basis to answer questions about buying
Java, but “would rather do it in person than in email”)
17
18
19
20
21
131.
In April 2009, Google sought to avoid discussions with Sun and to instead see if
Sun would sue Google before engaging in further discussions.
22
TX 1029 (4/29/2009: “we really don’t want to inadvertently stir anything up for
Android”. . . “we should step away, and only respond further if Sun chases after
us”)
23
24
25
26
132.
As late as August 2010, despite its claims that it had used only Sun’s API
specifications, Google internally acknowledged that it needed a Java license for Android.
TX 10 at 1 (8/6/10 “we need to negotiate a license for Java”)
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
24
1
2
133.
negotiations continued up to and beyond the date this lawsuit was filed.
3
Page at RT 492:18-22 (continue to have discussions to this day)
Catz at RT 2313:23-2314:7 (6/2010 told Google it needed a license for
Android)
Rizvi at RT 1941:20-1942:12 (3 mtgs with Rubin re: license for Java in
Android)
TX 1002 at 1. (11/24/08 certify Android through Java process & become
licensee)
See also cites for 84 above.
4
5
6
7
8
9
10
134.
any such belief.
Catz at RT 2315:22-2316:14
Rizvi at RT 1941:20-1943:1
12
135.
137.
138.
139.
140.
26
No documents and no testimony in the record suggest that anyone at Google relied
on Sun’s actions toward Apache in creating or distributing Android.
23
25
No documents and no testimony in the record suggest that anyone at Google relied
on Sun’s actions toward GNU Classpath in creating or distributing Android.
21
24
No credible evidence shows that, but for any statement or conduct by Sun or
Oracle, Google would have done anything differently in connection with Android.
19
22
No credible testimony shows that Google believed that Sun or Oracle did not
intend to enforce any intellectual property rights in connection with Android.
17
20
No credible evidence shows that Google relied on any statements by Sun in
continuing to use Java in Android.
15
18
It is unreasonable to treat a blog post as if it is a license.
136.
13
16
In all of its licensing discussions with Sun and with Oracle, Google never asserted
that it had believed that Sun had approved of its use of Java in Android, or that it had relied on
11
14
After November 2007, Google continued to discuss a license with Sun, and
141.
Google did not change its position with respect to Android as a result of any act
or statement by Sun or Oracle; rather, Google at all times continued with the same strategy.
IV.
PROPOSED CONCLUSIONS OF LAW
A.
OWNERSHIP
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
25
1
2
3
142.
The Certificate of registration constitutes “prima facie evidence of the validity of
the copyrights and of the facts stated in the certificate.” 17 U.S.C. § 410(c).
143.
Google “has the burden of rebutting the facts set forth in the copyright certificate.”
4
United Fabrics Int’l, Inc. v. C&J Wear, Inc., 630 F.3d 1255, 1257 (9th Cir. 2011). Google failed
5
to meet that burden.
6
144.
Under 37 C.F.R. 202.3(b)(4)(i)(A), “when a single published unit contains
7
multiple elements ‘that are otherwise recognizable as self-contained works,’ the unit is considered
8
a single work for the limited purpose of registration, while its elements may be recognized as
9
separate works for other purposes.” (ECF No. 433 at 6.) See Tattoo Art, Inc. v. TAT Int’l, LLC,
10
11
794 F. Supp. 2d 634, 651 (E.D. Va. 2011) (interpreting 202.3(b)(4)(i)(A).).
145.
Oracle owns the copyrights to the documentation, source code and compiled code
12
of the 37 API packages and the 11 source code files at issue, including to the structure, sequence
13
and organization of the 37 API packages. (FOF 1-8.)
14
B.
15
COPYRIGHTABILITY
146.
Copyright protection subsists in literary works. 17 U.S.C. § 102(a)(1).
16
The English language Java API documentation is an original, literary work and is thus
17
copyrightable under section 102(a).
18
147.
“Original, as the term is used in copyright, means only that the work was
19
independently created by the author (as opposed to copied from other works), and that it
20
possesses at least some minimal degree of creativity.” Feist Publ’ns, Inc. v. Rural Tel. Serv. Co.,
21
499 U.S. 340, 345(1991). The selection, structure, sequence and organization of the 37 API
22
packages in suit constitutes original, creative expression. (FOF 29-39, 42-43, 48.)
23
24
148.
Google has admitted that The Java APIs as a whole meet the low threshold
for originality required by the Constitution.” (See ECF No. 938 at 1.)
25
149.
“[C]opyright protection extends not only to the ‘literal’ elements of
26
computer software – the source and object code – but also to a program’s nonliteral elements,
27
including its structure, sequence, organization, user interface, screen displays and menu
28
structures.” Merch. Transaction Sys., Inc. v. Nelcela, Inc., 2009 U.S. Dist. LEXIS 25663, at *29
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
26
1
(D. Ariz. Mar. 17, 2009) (citation omitted). The structure, sequence, and organization of the 37
2
API packages in suit is copyrightable subject matter.
3
150.
“Whether the nonliteral components of a program, including the structure,
4
sequence and organization and user interface, are protected depends on whether, on the particular
5
facts of each case, the component in question qualifies as the expression of an idea, or an idea
6
itself.” Johnson Controls, Inc. v. Phoenix Control Sys., Inc., 886 F.2d 1173, 1175 (9th Cir. 1989).
7
151.
The structure, sequence, and organization of the 37 API packages in suit is
8
the detailed expression of an idea, not an idea itself. (FOF 29-39, 42-43, 46, 48.) The idea for an
9
API package may be to have a library of pre-written computer code relevant to the area of
10
programming to which the package relates. For example, the idea for java.net.ssl is to have a
11
library of pre-written code relating to secure network transactions. (FOF 13.) The selection,
12
structure, sequence and organization of the methods, fields, classes and other elements in the
13
java.net.ssl package, and the relationships among those elements is the expression of that idea.
14
152.
The detailed, creative expression of the API packages is not a method of
15
operation or system or otherwise barred by section 102(b). Johnson Controls, 886 F.2d at 1175.
16
See also Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366, 1370 (“We conclude that although an element of
17
a work may be characterized as a method of operation, that element may nevertheless contain
18
expression that is eligible for copyright protection.”); Toro Co. v. R&R Prods. Co., 787 F.2d
19
1208, 1211-12 (8th Cir. 1986) (section 102(b) did not bar copyright protection for parts number
20
system: question is whether particular expression is copyrightable); 1-2 Nimmer on Copyright
21
§ 2.03[D].
22
153.
“Under the merger doctrine, courts will not protect a copyrighted work
23
from infringement if the idea underlying the copyrighted work can be expressed in only one way,
24
lest there be a monopoly on the underlying idea.” Satava v. Lowry, 323 F.3d 805, 812 n.5 (9th
25
Cir. 2003). The structure, sequence, and organization of the 37 Java API packages in suit have
26
not merged with the underlying ideas because there are multiple ways to express an API with the
27
same or similar functionality. (FOF 33, 38, 39, 45-47.)
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
27
1
154.
“Under the scenes a faire doctrine, when certain commonplace expressions
2
are indispensable and naturally associated with the treatment of a given idea, those expressions
3
are treated like ideas and therefore not protected by copyright.” Swirsky v. Carey, 376 F.3d 841,
4
850 (9th Cir. 2004). The SSO of the 37 Java API packages in suit are not scenes a faire because
5
these elements are not commonplace, nor are they indispensable or standard to expressing any
6
idea. (FOF 46.)
7
155.
The SSO of the 37 API packages is not dictated by function since very
8
little structure is required for the code to operate with the virtual machine and computer. (FOF
9
47.)
10
156.
Google was not required to copy the 37 API packages for compatibility
11
with the Java programming language. (FOF 41, 50-51.) Google could have designed its own
12
APIs, and did in other areas for Android. (FOF 50.)
13
157.
“Words and short phrases such as names, titles, and slogans” are “not
14
subject to copyright.” 37 C.F.R. § 202.1(a). “[A] combination of unprotectable elements is
15
eligible for copyright protection only if those elements are numerous enough and their selection
16
and arrangement original enough that their combination constitutes an original work of
17
authorship.” Satava v. Lowry, 323 F.3d 805, 811 (9th Cir. 2003). In this case, the original
18
combination of the thousands names of the elements in the 37 Java API packages in suit is
19
copyrightable. (FOF 15, 16, 29-39, 41-43, 46, 48.)
20
158.
The structure described in written documentation is copyrightable when it
21
reflects creative expression. See, e.g., Situation Mgmt. Sys., Inc. v. ASP Consulting Group, 560
22
F.3d 53, 61 (1st Cir. 2009) (overall arrangement and structure of training manuals found to be
23
subject to copyright protection even though they described uncopyrightable system); Jacobsen v.
24
Katzer, 2009 U.S. Dist. LEXIS 115204, at *9-10 (N.D. Cal. Dec. 10, 2009) (selection and
25
arrangement of data reflecting information obtained from model railroad manufacturers entitled to
26
copyright protection).
27
28
159.
The structure, sequence, and organization of the documentation for the 37
Java API packages is the same as the structure, sequence, and organization of the class libraries
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
28
1
to which they relate since both are generated from the same source code. (FOF 24-25.) These
2
aspects of the documentation are copyrightable for the same reasons that the structure, sequence,
3
and organization of the code are copyrightable.
4
5
160.
Google copied the structure, sequence and organization for the 37 Java API
packages into the Android documentation. (FOF 14, 26, 28.)
6
C. DERIVATIVE WORKS
7
161.
A copyright owner has the exclusive right “to prepare derivative works
8
based upon the copyrighted work.” 17 U.S.C. § 106(2). “A ‘derivative work’ is a work based
9
upon one or more preexisting works, such as a translation.” 17 U.S.C. § 101.
10
162.
Because Google based the code for the Android core libraries on the Java
11
API specifications’ SSO, as well as the English prose descriptions contained therein, Google
12
infringed Oracle’s copyright by creating a derivative work. (FOF 24-26.)
13
163.
In the Sheldon v. Metro-Goldwyn Pictures Corp., Judge Learned Hand
14
found copyright infringement when the defendant created a movie that copied much of the
15
detailed plot outline of the plaintiff’s play, although it included none of the dialogue and changed
16
many of the specifics: “The play is the sequence of the confluents of all these means, bound
17
together in an inseparable unity; it may often be most effectively pirated by leaving out the
18
speech, for which a substitute can be found, which keeps the whole dramatic meaning. That as
19
it appears to us is exactly what the defendants have done here, the dramatic significance of the
20
scenes we have recited is the same, almost to the letter.” 81 F.2d 49, 50-56 (2nd Cir. 1936)
21
(emphasis added). See also eScholar LLC v. Otis Educational Sys., Inc., 2005 U.S. Dist. LEXIS
22
40727, at *25 (S.D.N.Y. Nov. 3, 2005) (citing Sheldon and stating “[c]opyright protection of the
23
non-literal elements of a computer program is analogous to protection that has been extended in
24
other areas in this circuit”); Twin Peaks Prods. V. Pul’n Int’l Ltd., 996 F.2d 1366, 1373-74 (2nd
25
Cir. 1993) (detailed recounting of plot outline of TV series held to be infringement).
26
164.
While the ideas behind particular individual elements described in the
27
documentation for the 37 API packages that Google copied may not be copyrightable, Google
28
chose to copy the protectable selection, structure, sequence and organization for the thousands of
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
29
1
elements expressed in that documentation, almost in its entirety, and to effectively give all of
2
these elements the same “dramatic meaning” within that copied structure. Sheldon, 81 F.2d at 56.
3
165.
In SAS Institute, Inc. v. S&H Computer Sys. Inc., 605 F. Supp. 816, 830
4
(M.D. TN. 1985), the court held defendant created an infringing derivative work that was “based
5
on” the SAS statistical analysis software by copying its structure. The court rejected the
6
defendant’s attempt to downplay the 44 examples of copying specific lines of code: “In addition,
7
the copying proven at trial does not affect only the specific lines of code cited by Dr. Peterson in
8
his testimony. Rather, to the extent that it represents copying of the organizational and
9
structural details of SAS, such copying pervades the entire S&H product.” Id. (emphasis
10
added). Similarly, in Meredith v. Harper & Row, Publishers, Inc., the court found copyright
11
infringement based on the defendants copying of 11% of a book along with its structure: “Thus I
12
conclude while the Meredith text contains some independent ideas of the author, some
13
independent research, some additional topics and some differing structure, the topic selection and
14
arrangement of the Meredith book are in substantial part the result of copying of the Mussen book
15
not attributable to independent effort by Meredith or the necessary result of limited possibilities
16
for organizing and presenting the material to be covered.” 413 F. Supp. 385, 387 (S.D.N.Y.
17
1975) (emphasis in original). Google’s deliberate copying of the structure, sequence and
18
organization of the 37 Java APIs pervades all of the 37 accused Android API packages,
19
notwithstanding Google’s claim that it wrote the implementing source code itself.
20
D.
21
WAIVER
166.
To show waiver, Google must prove Sun/Oracle had an intent to relinquish
22
its known rights to its copyrights in the 37 API packages and code and that Sun/Oracle
23
manifested that intent in an unequivocal manner. United States v. King Features Entm’t, Inc.,
24
843 F.2d 394, 399 (9th Cir. 1988); Adidas Am., Inc. v. Payless Shoesource, Inc., 546 F. Supp. 2d
25
1029, 1074 (D. Or. 2008) (“waiver must be manifested in an unequivocal manner” (internal
26
citations omitted)); see Novell, Inc. v. Weird Stuff, Inc., 1993 U.S. Dist. LEXIS 6674, at *54
27
(N.D. Cal. May 14, 1993).
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
30
1
167.
“An implied waiver of rights will be found where there is ‘clear, decisive
2
and unequivocal’ conduct which indicates a purpose to waive the legal rights involved.” Adidas,
3
546 F. Supp. 2d at 1074 (quoting Groves v. Prickett, 420 F.2d 1119, 1126 (9th Cir. 1970)).
4
5
168.
In light of all the credible evidence, Sun/Oracle did not unequivocally
intend to relinquish its intellectual property rights. (FOF 82-87, 94-100, 102-103, 105.)
6
169.
The fact that Sun and Oracle expressed continued concern and engaged in
7
repeated negotiations with Google to persuade it to take a license negates any inference from blog
8
posts or otherwise that Oracle had an unequivocal intent to relinquish its rights to the 37 Java API
9
packages. King, 843 F.2d at 399; Adidas, 546 F. Supp. 2d at 1074. (FOF 84-86, 97-98, 101.)
10
170.
Whether Sun/Oracle failed to prevent third parties, such as Apache or GNU
11
Classpath, from infringing is not sufficient to prove Sun/Oracle’s express and affirmative intent to
12
relinquish its copyrights against Google. Adidas, 546 F. Supp. 2d at 1074-75 (citing Novell, 0094
13
WL 16458729, at *13 ([E]ven if [plaintiff] failed to take preventative measures to stop
14
[defendant’s infringement-related activities, failure to act, without more is insufficient evidence
15
of the trademark owner’s intent to waive its right to claim infringement.”)). (FOF 34, 38.)
16
17
171.
Because Google has not proved that Sun/Oracle manifested an unequivocal intent
to relinquish its rights, Google’s defense of waiver fails.
18
E.
ESTOPPEL
19
172.
“Estoppel arises only when a party’s conduct misleads another to believe that a
20
right will not be enforced and causes him to act to his detriment in reliance upon this belief.”
21
Novell, 1993 U.S. Dist. LEXIS 6674, at *41; Adidas, 564 F. Supp. 2d at 1075.
22
173.
Four elements must be present to establish the defense of estoppel: (1) The party to
23
be estopped must know the facts; (2) he must intend that his conduct shall be acted on or must so
24
act that the party asserting the estoppel has a right to believe it is so intended; (3) the latter must
25
be ignorant of the true facts; and (4) he must rely on the former’s conduct to his injury.
26
Hampton v. Paramount Pictures Corp., 279 F.2d 100, 104 (9th Cir. 1960); Novell, 1993 U.S.
27
Dist. LEXIS 6674, at *42, 54-55 (N.D. Cal. May 14, 1993).
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
31
1
174.
Google had the burden of establishing each of the four elements of estoppel. .
2
Adidas, 546 F. Supp. 2d at 1075 (“Because Payless cannot prove each element of equitable
3
estoppel, the defense must fail.”).
4
175.
Google’s defense relied heavily upon a November 5, 2007 blog post by Jonathan
5
Schwartz and a statement made by Larry Ellison in April 2009, but Google failed to prove that
6
Sun or Oracle knew of Google’s infringement when it made those two public statements, or any
7
other statements or conduct by Sun or Oracle. (FOF 90-93.) As such, Google failed to establish
8
the facts necessary for the first element of this defense.
9
176.
Google also failed to prove that Sun or Oracle intended its conduct to give Google
10
a reason to believe that Sun or Oracle would not seek to enforce any intellectual property rights
11
against Google in connection with Android. (FOF 93-94, 96, 98, 102.) Sun continued to pursue
12
discussions with Google regarding Android, and Sun and then Oracle told Google that it needed a
13
license for Android. These facts undermine Google’s defense. (FOF 84-85.)
14
177.
Google also failed to prove that it was ignorant of any facts, including Sun’s
15
assertions of its copyrights in connection with the Java API or Google’s use of Sun’s intellectual
16
property for Android. (FOF 57-59, 61-64, 66-67, 70-71, 73, 80.) This element cannot be
17
established given Google’s knowing use of Sun’s copyrighted APIs without any license and
18
Google’s recognition, in its internal documents, that Google faced potential legal action by Sun in
19
connection with Android.
20
178.
Google also failed to prove reliance on any conduct by Sun or Oracle in
21
connection with Android. Google’s documents demonstrated that Google was acutely aware of
22
Sun’s concerns in connection with Android, and Sun sought to have Google take a license and
23
make Android compatible. (FOF 59, 61-63, 66-72, 86, 95-96, 98, 113, 116, 119-121, 130.) In
24
response, Google took steps to conceal its conduct from Sun and to avoid further discussions with
25
Sun. Such evidence bars application of this defense. (FOF 122-125.)
26
179.
Google was never “lulled into a sense of security” by Sun or Oracle. A.C.
27
Aukerman Co. v. R.L. Chaides Constr. Co., 960 F.2d 1020, 1043 (9th Cir. 1992) (“to show
28
reliance, the infringer must have had a relationship or communication with the plaintiff which
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
32
1
lulls the infringer into a sense of security in going ahead”). To the contrary, Google was acutely
2
aware of Sun’s concerns over Android, and at one point considered approaching Sun with a
3
proposal to buy Java for hundreds of millions of dollars, including the Java copyrights and
4
patents, and in doing so make Google’s “Java lawsuits go away.” (FOF 128-129.)
5
180.
Google’s defense also fails because Google did not change its position in reliance
6
on any conduct of Sun or Oracle to its detriment. (FOF 135-140.) It had chosen to use Sun’s
7
copyrighted Java APIs long before it announced Android, and before the statements by
8
Mr. Schwartz and Mr. Ellison. See Hampton, 279 F.2d at 105 (finding no estoppel where “any
9
change of position by [infringer] was in reliance upon the representations of the third parties and
10
despite the notice conveyed to him by [copyright holder’s] assertion of right printed on each
11
film.”); Novell, 1993 U.S. Dist. LEXIS 6674, at *54-55; Adidas, 546 F. Supp. 2d at 1075
12
(“[T]here is no evidence that Payless actually relied on Adidas’ alleged inaction. Because Payless
13
cannot prove each element of equitable estoppel, the defense must fail.”). (FOF 109-115, 118,
14
122.)
15
181.
Because Google has not proven each element of estoppel, the defense fails.
16
F.
IMPLIED LICENSE
17
182.
For the equitable defense of implied license, Google must prove that Oracle/Sun
18
affirmatively granted permission to Google to use the 37 API packages at issue and that the entire
19
course of conduct between the parties over the relevant time period led Google to reasonably infer
20
Oracle/Sun’s consent. Effects Assocs. v. Cohen, 908 F.2d 555, 558-559 (9th Cir. 1990) Implied
21
licenses exist “only in ‘narrow’ circumstances where one party ‘created a work at [the other’s]
22
request and handed it over, intending that [the other] copy and distribute it.” A&M Records,
23
Inc. v. Napster, Inc., 239 F.3d 1004, 1026 (9th Cir. 2001) (citing Effects Assocs., 908 F.2d at 558)
24
(alterations in original); Oddo v. Ries, 743 F.2d 630, 634 (9th Cir. 1984) (in a partnership to
25
create and publish a book, plaintiff handed copyrighted manuscript to defendant for publication,
26
thus court found plaintiff “impliedly gave the partnership a license to use the articles insofar as
27
they were incorporated in the manuscript”); Metro-Goldwyn-Mayer Studios, Inc. v. Grokster,
28
Ltd., 518 F. Supp. 2d 1197, 1226 (C.D. Cal. 2007) (rejecting implied license defense where
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
33
1
“[o]bviously, Plaintiffs did not create their copyrighted works at StreamCast’s request or for
2
StreamCast’s benefit”).
3
183.
Sun/Oracle did not affirmatively grant permission to Google to use the 37 API
4
packages or code at issue here without a license; in fact the record shows the contrary. (FOF 66,
5
83-84, 98, 106, 131, 133.)
6
184.
It was not reasonable for Google to infer consent to use the 37 Java APIs without a
7
license because the entire course of conduct between the parties demonstrated Sun/Oracle’s
8
assertion of its IP rights. (FOF 82-107.)
9
10
G.
LACHES
185.
For the equitable defense of laches, Google must prove that (1) Oracle/Sun
11
unreasonably delayed filing the lawsuit; (2) the delay was inexcusable, and (3) that Google has
12
suffered material prejudice due to Oracle/Sun’s delay. Danjaq LLC v. Sony Corp., 263 F.3d 942
13
(9th Cir. 2001) (three-part analysis of “delay,” “reasonableness of the delay,” and “prejudice”).
14
186.
First, “the relevant delay is the period from when the plaintiff knew (or should
15
have known) of the allegedly infringing conduct, until the initiation of the lawsuit in which the
16
defendant seeks to counterpose the laches defense.” Danjaq, 263 F.3d at 952.
17
18
19
187.
Oracle filed suit in August 2010, within three years of the first time that the APIs
and the code in Android were made available to the public (in November 2007). (FOF 92.)
188.
Courts recognize negotiations with the accused as an excuse for delay. In re Katz
20
Interactive Call Processing Patent Litig., 712 F. Supp. 2d 1080, 1110 (C.D. Cal. 2010) (“the
21
negotiation must ‘ordinarily be continuous and bilaterally progressing, with a fair chance of
22
success, so as to justify significant delays’”); Lucent Techs., Inc. v. Gateway, Inc., 580 F. Supp.
23
2d 1016, 1053 (S.D. Cal. 2008); A.C. Aukerman Co., 960 F.2d at 1033.
24
189.
Courts have found delay reasonable or excusable where evidence shows that for
25
several years leading up to the start of litigation, plaintiff engaged in efforts to sell a license to
26
defendant or engaged in bilateral negotiations with a fair chance of success. Lucent, 580 F. Supp.
27
2d at 105; In re Katz, 712 F. Supp. 2d at, 1110-11.
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
34
1
190.
Since Sun/Oracle’s continued discussions and negotiations with Google regarding
2
licensing options were bilateral and had a fair chance of success, including through the time of
3
Google’s CEO Larry Page’s testimony at trial, Sun/Oracle’s delay in bringing suit is excusable.
4
In re Katz, 712 F. Supp. 2d at 1110-11 (rejecting argument that correspondence between parties
5
were “sporadic” and futile and holding that their 6 year correspondence, up until defendant
6
conclusively communicated that it does not need a license, constituted rebuttal of presumption of
7
laches and raised genuine issue of excuse); Lucent Techs., 580 F. Supp. 2d at 1053 (“Court
8
concludes that any delay was reasonable or excusable since Lucent attempted to seek
9
compensation for its patent through the computer manufacturers”). (FOF 84, 85, 97-99, 101,
10
11
132.)
191.
Third, Google has failed to demonstrate prejudice by showing that it took actions
12
or suffered consequences that it would not have, had Sun/Oracle brought suit promptly. Danjaq,
13
263 F.3d at 955. (FOF 140.)
14
192.
Indeed, “[t]he very purpose of laches as an equitable doctrine – and the reason that
15
it differs from a statute of limitations – is that the claim is barred because the plaintiff’s delay
16
occasioned the defendant’s prejudice. Danjaq, 263 F.3d at 955 (quoting Telink Inc. v. U.S., 24
17
F.3d 42, 45 (9th Cir. 1994)); A.C. Aukerman Co., 960 F.2d 1020, 1033 (9th Cir. 1992) (“Material
18
prejudice to adverse parties resulting from the plaintiff’s delay is essential to the laches
19
defense.”).
20
193.
Google’s policy was to push forward and develop Android with the infringing Java
21
APIs, “making enemies along the way,” and thus did not change its position in reliance on
22
Oracle’s inaction. (FOF 57-64, 71-73, 108-118.)
23
194.
Moreover, “laches is not available in a case of willful infringement, when the
24
infringing conduct occurs ‘with knowledge that the defendant’s conduct constitutes copyright
25
infringement.” Winn v. Opryland Music Group, Inc., 22 Fed. Appx. 728, 729 (9th Cir. 2001)
26
(internal citations omitted).
27
28
195.
As the evidence indicates that Google’s infringement was willful, Google is
ineligible to assert the defense of laches. (FOF 57-64, 71-73, 108-118.)
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
35
1
Dated: May 1, 2012
2
BOIES, SCHILLER & FLEXNER LLP
By: Steven C. Holtzman
Steven C. Holtzman
3
Attorneys for Plaintiff
ORACLE AMERICA, INC.
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
36
Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.
Why Is My Information Online?