Oracle America, Inc. v. Google Inc.
Filing
1049
Corrected 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
Case No. CV 10-03561 WHA
Plaintiff,
Defendant.
24
Dept.: Courtroom 8, 19th Floor
Judge: Honorable William H. Alsup
v.
25
PLAINTIFF’S CORRECTED PROPOSED
FINDINGS OF FACT AND
CONCLUSIONS OF LAW
GOOGLE, INC.
26
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
2.
J2SE 1.4 and J2SE 5.0 were both registered as derivative works, and both the
12
copyright registrations incorporate by reference Sun’s copyright registrations for prior versions.
13
TX 3529 (J2SE 5.0)
TX 3530 (J2SE 1.4)
Reinhold at RT 2233:6-2234:20
Reinhold at RT 2234:20
14
15
16
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
4.
Similarly, under the heading “Materials Added to this Work,” the copyright
22
registration for J2SE 5.0 lists “New and revised computer code and accompanying documentation
23
and manuals.” The registration was accompanied by a hard copy excerpt of source code from the
24
J2SE 5.0, and included a CD-ROM containing the binary code and documentation for J2SE 5.0.
25
TX 3529
Reinhold at RT 2234:20-2238:19
Dare at RT 2257:5-2266:25
TX 1076, 1077, 1078, 1081
26
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
libraries for J2SE Version 5.0.
16
Reinhold at RT 584:10-585:15
Mitchell at RT 1248:13
17
18
10.
Java Application Programming Interfaces (“APIs”) are documentation, sometimes
19
referred to as specifications, that describe the many elements that make up the class libraries and
20
the relationships among them.
21
22
Reinhold at RT 585:16-586:6
11.
The Java API packages describe the structure of the class libraries, the names of all
23
the elements, and include English prose that describes how every element is expected to work.
24
The class libraries contain the compiled code.
25
Reinhold at RT 592:18-593:13
26
12.
The 37 API packages asserted in this lawsuit are java.awt.font, java.beans, java.io,
27
java.lang, java.lang.annotation, java.lang.ref, java.lang.reflect, java.net, java.nio,
28
java.nio.channels, java.nio.channels.spi, java.nio.charset, java.nio.charset.spi, java.security,
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.
There is an intricate relationship of hierarchies and dependencies among Java API
19
elements within and across packages. These are illustrated in part in the Java API package poster
20
used by developers when programming for J2SE version 5.0.
21
Mitchell at RT 2283:6-20
Reinhold at RT 586:7-603:6
TX 1028
22
23
17.
The intricate structure of the API packages poster reflects only the high level class
24
and interface relationships for some of the API packages in version 5.0, because it would be
25
impossible to fit a description of all the relationships even on a large poster with extremely small
26
print.
27
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
5
19.
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.
9
Reinhold at RT 589:13-18
Reinhold at RT 590:5-23
Reinhold at RT 601:22-25
10
11
20.
Methods can contain parameters that are defined in other classes located within, or
12
outside, the package in which the method is found. Methods can also return members of other
13
classes.
14
Reinhold at RT 602:4-603:6
15
21.
16
defined in another.
17
Classes and subclasses can be contained within the hierarchy of one package but
Reinhold at RT 601:14-21
Mitchell at RT 1221:24-1222:2
18
22.
Interfaces themselves are often arranged hierarchically in a manner similar to
19
classes.
20
Mitchell at RT 1219:14-23, 1236:19-1237:2
21
23.
The structure, sequence and organization (“SSO”) of the 37 Java API packages are
22
expressed in both their specifications and the implementations. The specifications describe the
23
SSO of the Java API implementations, and are used by developers to understand and use the
24
implementation.
25
Reinhold at RT 619:16-620:6
Mitchell at RT 1236:3-1237:8; 1234:9-17
Bornstein at RT 1843:3-1844:1
26
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
4
1
24.
In Java, the SSO is the same for the API specifications and the implementations
2
because both are derived from the same source code. The English language comments and
3
declarations are extracted from the source code using a tool called javadoc. The source code is
4
also compiled into executable byte code for the implementation by a compiler.
5
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
6
7
8
25.
Similarly, in Android, the Android specifications have the same SSO as the
9
implementations because both are derived from the same source code.
10
Lee at RT 1169:8-15
Bornstein at RT 1841:11-15
11
12
26.
The source code and documentation for the 37 accused Android API packages
13
have the same SSO described in the documentation and source code for the 37 Java API packages
14
at issue.
15
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
16
17
18
19
20
27.
The printed copy of the documentation for the 37 Java API packages in suit would
21
span 11,000 pages, filling three and a quarter banker’s boxes.
22
Reinhold at RT 617:2-15
23
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.
26
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)
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
29.
4
5
Designing APIs is an activity that requires significant 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
6
7
8
30.
No witness testified at trial that API design is not creative.
31.
9
“Designing a good API is tough” “[l]ike any work of craftsmanship.”
10
Bloch at RT 751:14-18; see also 830:18-19; 831:7-12
11
32.
APIs are works of authorship.
12
Bloch at RT 741:23-742:3, 743:1-3, 743:12-18, 746:9-16; 748:17-22
13
14
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.”
15
Reinhold at RT 627:21-628:23
16
34.
18
[Omitted.]
35.
17
Java API design is a task that is often assigned to a company’s “most senior
experienced and talented software engineers.”
19
Ellison at RT 291:11-16
20
21
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.
22
Screven at RT 516:24-517:3 (the API for the 37 packages “reflect creative
design”)
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)
23
24
25
26
27
37.
It took almost two years for Chief Java Architect Mark Reinhold, working with
other engineers, to develop the APIs for java.nio and its related sub-packages when he was at
Sun.
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
6
1
2
3
Reinhold at RT 623:17-624:1; 627:21-629:6
38.
a set of APIs that developers said “changed their life.”
4
5
6
The collections framework, which is in the asserted Java API package java.util, is
Bloch at RT 750:5-21
Bloch at RT 772:25-773:6
39.
The collections APIs in other development environments such as C++ and
Smalltalk are structured very differently.
7
Mitchell at RT 1240:23-1244:16
8
9
40.
Third parties have created totally different APIs for Java that accomplish similar
things to Oracle’s Java APIs.
10
Reinhold at RT 518:4-519:15; 630:11-631:18
Screven at RT 290:15-291:6
11
12
41.
The Java API packages have grown dramatically, from the seven API packages
13
that were included in the first release, to the 166 packages included with version 5.0, to 209
14
packages included with version 7.0.
15
16
Reinhold at RT 631:19-25
42.
The complex structure of the Java APIs for the 37 packages at issue and their
17
associated implementations is not required in order for the Java APIs or their implementations to
18
operate with the virtual machine or computer. A primary purpose of the SSO of the APIs is to
19
make them easier for programmers to learn and use.
20
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
TX 624 at 4
21
22
23
24
43.
Writing Java APIs involves multiple design choices and requires attention to
aesthetic considerations, not just function.
25
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
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
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.
4
Bloch at RT 752:5-11
5
6
7
45.
When designing an API, the engineer must consider not only the functionality that
is required by the potentially large number of users, but also a “complex web of classes [to] lay
out and design” and “the implication[s] for the underlying implementation.”
8
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)
9
10
11
46.
Oracle and Sun had many choices for what elements to include in the 37 Java API
packages and how to structure them. It was not required to structure them in any particular way.
12
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)
13
14
15
47.
indispensable or standard way of expressing any idea.
16
17
18
The SSO of the Java API packages is not commonplace, and was not an
Reinhold at RT 630:11-631:18
Mitchell at RT 1240:23-1242:25, 1243:6-1244:16
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.
19
Reinhold at RT 619:13-23
20
21
49.
The choice of names is significant, and the Java API designers thoughtfully
selected thousands of names for aesthetic purposes and consistency.
22
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
23
24
25
50.
The Java API packages are distinct from the Java programming language. The
26
programming language is described in the Java Language Specification (“JLS”). Only about 60
27
classes are required by the programming language, and, except Object, none are specified in
28
detail in the JLS.
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
8
1
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
2
3
4
51.
Google did not need to copy Oracle’s Java APIs for these 37 packages to make
5
use of the Java programming language. Google designed many of its own API packages for
6
Android and could have designed its own APIs for these packages as well.
7
Mitchell at RT 2288:6-12
Astrachan at RT 2212:25-2213:19
Astrachan at RT 2220:1-7
Reinhold at RT 518:4-519:15
Reinhold at RT 630:11-631:18
8
9
10
52.
Android is not compatible with Java. Google “supersetted” and “subsetted” the
11
Java APIs—adding in its own APIs for other packages that are not included in Java and failing to
12
include APIs for other packages that are present in Java. As a result, many applications written
13
for Java will not run on Android, and many applications written for Android will not run on Java.
14
Mitchell at RT 1331:16-1332:2, 2287:23-2288:5
Morrill at RT 1007:6-11
TX 383 at 8
15
16
53.
Oracle and Sun did not dedicate the APIs to the public domain. They consistently
17
included copyright notices on the Java API specifications. These copyright notices were included
18
in the books that published early versions of the specifications and are prominently featured on
19
the website that contains them. Copyright notices are also included in the source code for the
20
class libraries.
21
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
22
23
24
25
54.
Sun, and now Oracle, only make the APIs available through licenses. One type of
26
license is a specification license that allows for independent implementations of the APIs, but
27
only if the specification meets certain requirements.
28
Ellison at RT 293:16-295:6
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
9
1
Kurian at RT 370:6-381:25
TX 610.1
Cizek at RT 1071:4-17
TX 1026
2
3
4
55.
The specification license was included in the books that published the API
specifications on the same page as the copyright notice.
5
TX 980 at 6
TX 981 at 6
6
56.
7
8
web pages that describe the API specifications.
9
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)
10
11
12
13
A link to the specification license is included next to the copyright notices on the
57.
Google deliberately chose to base the 37 accused packages in Android on the
corresponding design, including the SSO, of the 37 Java API packages set forth in the Java API
documentation and source code.
14
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
15
16
17
III.
PROPOSED FINDINGS OF FACT REGARDING GOOGLE’S EQUITABLE
DEFENSES
18
A.
20
Google’s Knowledge Of Sun Intellectual Property
58.
19
Sun posted a notice of copyright on its Java specifications both online and in
books.
21
TX 984
TX 2564
TX 610.1
TX 610.2
22
23
59.
24
Google executives and engineers responsible for Android knew that Sun
25
copyrighted, among other things, the method signatures, the specifications for the APIs, and the
26
code.
27
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?”)
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
10
1
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)
2
3
4
5
60.
The head of Android, Andy Rubin, knew that Sun copyrighted the Java APIs: He
wrote that “java.lang apis are copyrighted” and that “[S]un gets to say who they license the
[TCK] to.”
6
TX 18 at 1 (java.lang apis are copyrighted)
Rubin at RT 1356:6-19
7
8
9
61.
was based on “folklore.”
10
11
Andy Rubin believed that APIs are not copyrightable, and admitted that his belief
Rubin at RT 1746:13-1747:8 (folklore)
62.
Andy Rubin and other Android team members knew Sun’s license requirements
12
from their prior work at Danger, Inc. Danger created an implementation of the Java specification,
13
using no Sun source code. Danger complied with Sun’s requirement to take a Java license and
14
conform to the Java standard.
15
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)
16
17
18
19
20
21
22
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.
23
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.”)
24
25
26
64.
In 2005 and 2006, Sun and Google negotiated for a license that would have
27
permitted Google to use Sun technology, including the APIs in suit.
28
TX 1 at 9 (7/26/2005: “Must take license from Sun”)
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
11
1
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”)
2
3
4
5
65.
developed a “clean room” implementation instead, i.e. without Sun code.
6
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)
7
8
9
10
11
66.
The evidence shows that all other companies that developed an independent
implementation of the Java technology took a license.
12
13
Google knew that it needed a license even if it did not partner with Sun and
Ellison at RT 293:8-294:21
Kurian at RT 385:20-386:8
67.
In 2005, Google and Sun specifically negotiated for a license to Sun’s APIs.
14
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.”)
15
16
17
18
19
20
21
22
23
24
25
26
27
28
68.
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.
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.’”)
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
12
1
2
69.
Google knew that compatibility was a core proposition of Java and that Sun
worked actively to prevent fragmentation.
3
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
4
5
6
7
70.
Google knew that “Java had very little fragmentation.”
8
TX 21
9
71.
Google hired numerous former Sun engineers, including Tim Lindholm, who
10
represented to Andy Rubin in 2005 that he should be a “project advisor” for Android because he
11
was familiar with the “legal ecosystem.”
12
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”)
13
14
15
72.
Additionally, Google executives and engineers responsible for Android knew
16
about the requirements of Sun’s specification license, because Google was a member of the JCP,
17
and participated directly in Sun’s dispute with Apache.
18
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)
19
20
21
22
23
24
73.
Google knew that Apache Harmony could not be used in mobile devices because
Android’s Core Library Lead, Mr. Lee, told Mr. Schmidt that Sun prevented
25
“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).”
26
27
TX 405
Lee at RT 986:5-987:19 (describing TX 405)
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
13
1
2
74.
areas – areas where they don’t have a well defined revenue stream. Apache is an example.”
3
4
5
Google also knew that Sun permitted open source projects only for “non-mobile
TX 7
75.
Apache had no license from Sun that would it allow it to distribute the Java APIs
commercially under the Apache license.
6
Kurian at RT 393:23-394:18; 396:3-9; 399:10-33
Screven at RT 523:25-525:3; 527:18-20
7
76.
On April 10, 2007, Apache posted on its website a letter to Sun and acknowledged
8
on its website that Apache needed a TCK “to demonstrate compatibility with the Java SE
9
5specification, as required by Sun specification license for Java SE 5.”
10
TX 917 at 1
11
77.
In a “FAQ” accompanying the letter to Sun, Apache publicly stated that users of
12
Apache Harmony “wouldn’t be assured that they had all necessary IP rights from the spec’s
13
contributors.” On December 9, 2010, Apache again publicly stated “that Java specifications are
14
proprietary technology that must be licensed directly from the spec lead.”
15
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)
16
17
78.
The evidence shows that no other companies use Apache Harmony in commercial
18
devices other than Google.
19
Kurian at RT 401:25-403:11
Screven at RT 530:11-24
Rubin at RT 1761:25-1762:6
20
21
79.
Google nonetheless used Harmony code in Android.
22
Bornstein 1837:21-1838 (“an awful lot of stuff came from Apache Harmony”)
23
80.
According to Google’s Executive Chairman Eric Schmidt, Google does not assert
24
that it has any rights to use any Sun intellectual property as the result of the Apache license.
25
Schmidt at RT 1541:3-25
26
81.
Eric Schmidt, then CEO of Google, “would have assumed” the TCK “was one of
27
the licensing requirements” of a Sun specification license for Java APIs.
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
14
1
2
3
Schmidt at RT 1559:5-11
82.
Google conducted no dependable investigation into whether it was infringing
Sun’s and then Oracle’s copyrights.
4
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)
5
6
7
8
B.
Sun’s Actions
9
83.
It was not Sun’s practice to permit incompatible implementations of the Java
10
specification, even if those implementations did not bear the Java brand.
11
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.”)
12
13
14
15
16
17
18
84.
Sun would contact companies that had released incompatible implementations in
commercial products and require them to take a license and make the implementation compatible.
19
Cizek at RT 1054:21-1059:14
Cizek at RT 1071:4-17
TX 1026 (Sun-Danger license)
20
21
22
85.
From 2005 up through the time of trial, Sun and now Oracle had ongoing
discussions with Google regarding Java licensing for Android.
23
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)
Rizvi at RT 1941:20-1942:12 (3 mtgs with Rubin re: license for Java in Android)
24
25
26
27
28
86.
In fact, the Sun-Google negotiations never broke off.
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
15
1
2
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.”)
87.
In 2007, before Google announced Android, Sun repeatedly tried to engage
Google in discussions on Java licensing for Android.
4
TX 538 (emails from Gupta to Rubin)
TX 565 at 3
5
6
88.
By 2007, Sun had released its technology under a particular open source license,
7
the GNU General Public License (GPL), a “give and force back” license that requires users to
8
open source certain portions of their own code if they used the GPL-licensed code.
9
10
11
Schwartz at RT 2021:16-23 (GPL is a “give and force back” license)
Ellison at RT 292:2-293:4
89.
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.
12
Kurian at RT 387:13-388:3
Screven at RT 531:3-20
13
14
15
90.
use GPL-licensed open source code.
16
TX 230
TX 154
Rubin at RT 1754:9-21
17
18
The GPL did not suit Google’s business needs for Android and Android did not
91.
Before Google announced Android, Sun did not know what Google would do with
19
Android, or whether Google would require a commercial Java license for Android, or whether it
20
would use GPL code.
21
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”)
22
23
92.
On November 5, 2007, when Sun’s CEO responded to the announcement of
24
Android in a blog post, Google had not yet released the Android Software Development Kit
25
(“SDK”), and Sun therefore did not know the facts regarding Google’s infringement.
26
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.”)
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
16
1
2
93.
Google identified the APIs to be used in Android publicly.
3
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)
4
5
6
7
94.
As of November 12, 2007, Sun’s CEO understood that Google might still agree to
certify Android as compliant with the Java specification.
8
9
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
10
Green, Executive Vice President of Software at Sun, publicly expressed concern regarding
11
Android and the incompatible set of APIs. He is quoted as stating:
12
“Anything that creates a more diverse or fractured platform is not in (developers’)
best interests.”
13
“The feedback from developers is, ‘Help us fix this.’”
14
“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.”
15
16
17
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)
18
19
20
96.
internally that “[t]his is a very touchy subject.”
21
TX 180
Rubin at RT 1725:23-1726:10
22
23
24
When asked to comment on Mr. Green’s comments, Rubin responded to Google
97.
On May 23, 2008, Google Android employees received, circulated, and
commented on an article that reported on Sun’s continuing concern regarding Android:
“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.”
25
26
TX 245
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
17
1
2
98.
platform, Sun engaged in another round of discussions with Google.
3
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”)
4
5
6
In September through November 2008, prior to Google’s release of the Android
99.
In April 2009, Sun communicated to Google that Google needed a license for
Android, and that Google needed to make Android compatible.
7
Cizek at RT 1071:23-1073:18 (conversation with Martin Buchholz at Google)
TX 1029
8
100.
Oracle has continued to express concern regarding Google’s use of Oracle’s
9
intellectual property in Android.
10
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.”)
11
12
13
14
101.
Sun’s words and actions in response to the Android announcement in November
15
2007 were neither intended to be, nor reasonably could be understood to be, an endorsement of an
16
Android that used only some of the Java SE APIs and that failed to comply with Sun’s licenses.
17
Schwartz at RT 1991:9-14
McNealy at RT 2059:2-2060:13 (Sun practice to require compatibility)
18
19
20
102.
rather than litigation, were reasonable and consistent with its historical interactions with Google.
21
22
23
From 2006 to the present, Sun’s actions in continuing a strategy of negotiation,
See cites for 63, 64, and 85-87 above.
103.
Sun did not intend to relinquish any rights with regard to its copyrights or
Android.
24
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)
25
26
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
18
1
2
McNealy at RT 2065:14-2066:14 (ongoing discussions with Google)
104.
No credible evidence shows that Sun ever communicated to Google, expressly or
3
implicitly, that Sun was giving up any rights to assert legal claims against Google based on
4
Google’s use of the asserted Java APIs for Android.
5
105.
No credible evidence shows that Sun intended or expected that Google would
6
interpret Sun’s statements or conduct – including Sun’s repeated efforts to negotiate with Google
7
to take a Java license for Android – to mean that Google did not need such a license.
8
9
10
11
12
13
106.
Sun never unequivocally or intentionally relinquished any known right to assert its
copyrights in the Java APIs against Google.
107.
Sun’s words and conduct were consistent with intent to enforce its rights to the
intellectual property at issue.
108.
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.
14
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)
15
16
C.
17
Reliance
109.
Android was a “critical asset” for Google that is “hugely profitable.”
18
TX 431
TX 1091 (RT 2226:20-23 (Agarwal Dep.)
19
20
110.
In 2005, Google was concerned about the growing number of individuals using
21
mobile phones to search the internet and its ability to attract and retain those users. Android
22
would give Google more control of the user experience and built-in Google applications on
23
mobile phones.
24
TX 3215
TX 1
TX 10
25
26
111.
The vast majority of Google’s revenue at that time and today comes from search
27
revenue. A primary reason to have Android is that people will do more searches and Google
28
would get more money as a result.
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
19
1
2
3
Schmidt at RT 1458:12-16
112.
others, such as Microsoft, Symbian and Apple, into the smartphone market.
4
TX 6
Schmidt at RT 1-11
Bornstein at RT 1844:15 -1847:1
5
6
7
113.
TX 15
TX 7
Page at RT 490:1-7
Schmidt at RT 1462:2-13
9
11
Google knew that the time to market was crucial and using Java dramatically
accelerated their schedule, with other alternatives being suboptimal.
8
10
In 2005, 2006, and 2007 Google was under tremendous time pressure to beat
114.
In 2005 and 2006, Google stated in internal emails and presentations that Google
needed a license from Sun for Android.
12
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”)
13
14
15
115.
However, Google did not want the obligations that the GPL and specifications
16
license imposed. The GPL terms required Google’s licensees to contribute back any additions to
17
Google’s code. The specification license required Google to create a compatible version of Java.
18
Schmidt at RT 2021:16-23
TX 610.1
See also cites in 88-90 above.
19
20
116.
21
22
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
23
executives and engineers acknowledged internally that launching Android without a license, as an
24
incompatible implementation, would place Google in an adversarial stance against Sun.
25
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
26
27
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
20
1
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)
2
3
4
5
118.
6
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.”)
7
8
9
10
Android was not and is not compatible with Java.
119.
Google decided to use the APIs in mid-2006 to early 2007—before Jonathan
Schwartz’s blog post on November 5, 2007.
11
Bornstein at RT 1850:4-1851:2
12
13
120.
Android head Andy Rubin only “vaguely” remembers any comments by Sun after
the announcement of Android.
14
Rubin at RT 1446:23-1447:8
15
16
17
18
121.
No credible testimony shows that before November 5, 2007, Google relied on any
statement by Sun in making any decision regarding the technology to include in Android.
122.
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.
19
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”)
20
21
22
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.
23
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?”)
24
25
26
124.
In November 2007, Google took steps to limit public discussions regarding
Android to certain authorized individuals and avoid references to Java.
27
TX 382
TX 165
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
21
1
TX 217
125.
2
In January 2008, Google made public presentations that included a graphic that
3
described the Android core libraries as “Core Java libraries.” Google later changed this graphic
4
to delete the word “java.”
5
TX 34
TX 43.1
6
7
126.
In March 2008, Google took steps to prevent its employees from demonstrating
Android to any Sun employees or lawyers.
8
TX 29 at 1 (3/24/08: don’t demonstrate to any sun employees or lawyers)
9
10
11
127.
On May 23, 2008, Google Android employees received, circulated, and
commented on an article that reported on Sun’s continuing concern regarding Android. That
article stated:
12
“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.”
13
14
TX 245
Morrill at RT 1043:1-10 (saw that others had reported that Sun had concerns; had
no conversations with Sun at all)
15
16
128.
17
18
19
about the dispute regarding Sun licensing for Apache’s Harmony project, but wrote that was
“water under the bridge” for Android.
TX 405
20
129.
21
22
23
Sun.
TX 203
TX 183
TX 1002
25
27
In September through November 2008, Google engaged in additional negotiation
with Sun regarding Android, and that discussion included the possibility of buying Java from
24
26
In May 2008, Google employee Bob Lee informed Google CEO Eric Schmidt
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.
Schmidt at RT 1559:20-23; 1560:10-12
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
22
1
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”)
2
3
4
131.
Sun would sue Google before engaging in further discussions.
5
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”)
6
7
In April 2009, Google sought to avoid discussions with Sun and to instead see if
132.
As late as August 2010, despite its claims that it had used only Sun’s API
8
specifications, Google internally acknowledged that it needed a Java license for Android.
9
TX 10 at 1 (8/6/10 “we need to negotiate a license for Java”)
10
11
133.
negotiations continued up to and beyond the date this lawsuit was filed.
12
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 85 above.
13
14
15
After November 2007, Google continued to discuss a license with Sun, and
134.
In all of its licensing discussions with Sun and with Oracle, Google never asserted
16
that it had believed that Sun had approved of its use of Java in Android, or that it had relied on
17
any such belief.
18
19
20
21
22
23
24
25
26
27
Catz at RT 2315:22-2316:14
Rizvi at RT 1941:20-1943:1
135.
It is unreasonable to treat a blog post as if it is a license.
136.
No credible evidence shows that Google relied on any statements by Sun in
continuing to use Java in Android.
137.
No credible testimony shows that Google believed that Sun or Oracle did not
intend to enforce any intellectual property rights in connection with Android.
138.
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.
139.
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.
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
23
1
2
140.
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.
3
141.
Google did not change its position with respect to Android as a result of any act or
4
statement by Sun or Oracle; rather, Google at all times continued with the same strategy.
5
IV.
PROPOSED CONCLUSIONS OF LAW
6
A.
Ownership
7
142.
The Certificate of registration constitutes “prima facie evidence of the validity of
8
9
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.”
10
United Fabrics Int’l, Inc. v. C&J Wear, Inc., 630 F.3d 1255, 1257 (9th Cir. 2011). Google failed
11
to meet that burden.
12
144.
Under 37 C.F.R. 202.3(b)(4)(i)(A), “when a single published unit contains
13
multiple elements ‘that are otherwise recognizable as self-contained works,’ the unit is considered
14
a single work for the limited purpose of registration, while its elements may be recognized as
15
separate works for other purposes.” (ECF No. 433 at 6 (emphasis in original).) See Tattoo Art,
16
Inc. v. TAT Int’l, LLC, 794 F. Supp. 2d 634, 651 (E.D. Va. 2011) (interpreting 202.3(b)(4)(i)(A).).
17
145.
Oracle owns the copyrights to the documentation, source code and compiled code
18
of the 37 API packages and the 11 source code files at issue, including to the structure, sequence
19
and organization of the 37 API packages. (FOF 1-8.)
20
B.
Copyrightability
21
146.
Copyright protection subsists in literary works. 17 U.S.C. § 102(a)(1). The
22
English language Java API documentation is an original, literary work and is thus copyrightable
23
under section 102(a).
24
147.
“Original, as the term is used in copyright, means only that the work was
25
independently created by the author (as opposed to copied from other works), and that it
26
possesses at least some minimal degree of creativity.” Feist Publ’ns, Inc. v. Rural Tel. Serv. Co.,
27
499 U.S. 340, 345(1991). The selection, structure, sequence and organization of the 37 API
28
packages in suit constitute original, creative expression. (FOF 29-40, 42-44, 47-48.)
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
24
1
2
3
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.)
149.
“[C]opyright protection extends not only to the ‘literal’ elements of computer
4
software – the source and object code – but also to a program’s nonliteral elements, including its
5
structure, sequence, organization, user interface, screen displays and menu structures.” Merch.
6
Transaction Sys., Inc. v. Nelcela, Inc., 2009 U.S. Dist. LEXIS 25663, at *29 (D. Ariz. Mar. 17,
7
2009) (citation omitted). The structure, sequence, and organization of the 37 API packages in suit
8
is copyrightable subject matter.
9
150.
“Whether the nonliteral components of a program, including the structure,
10
sequence and organization and user interface, are protected depends on whether, on the particular
11
facts of each case, the component in question qualifies as the expression of an idea, or an idea
12
itself.” Johnson Controls, Inc. v. Phoenix Control Sys., Inc., 886 F.2d 1173, 1175 (9th Cir. 1989).
13
151.
The structure, sequence, and organization of the 37 API packages in suit is the
14
detailed expression of an idea, not an idea itself. (FOF 29-40, 42-44, 46-48.) The idea for an API
15
package may be to have a library of pre-written computer code relevant to the area of
16
programming to which the package relates. For example, the idea for java.net.ssl is to have a
17
library of pre-written code relating to secure network transactions. (FOF 13.) The selection,
18
structure, sequence and organization of the methods, fields, classes and other elements in the
19
java.net.ssl package, and the relationships among those elements is the expression of that idea.
20
152.
The detailed, creative expression of the API packages is not a method of operation
21
or system or otherwise barred by section 102(b). Johnson Controls, 886 F.2d at 1175. See also
22
Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366, 1370 (“We conclude that although an element of a work
23
may be characterized as a method of operation, that element may nevertheless contain expression
24
that is eligible for copyright protection.”); Toro Co. v. R&R Prods. Co., 787 F.2d 1208, 1211-12
25
(8th Cir. 1986) (section 102(b) did not bar copyright protection for parts number system: question
26
is whether particular expression is copyrightable); 1-2 Nimmer on Copyright § 2.03[D].
27
28
153.
“Under the merger doctrine, courts will not protect a copyrighted work from
infringement if the idea underlying the copyrighted work can be expressed in only one way, lest
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
25
1
there be a monopoly on the underlying idea.” Satava v. Lowry, 323 F.3d 805, 812 n.5 (9th Cir.
2
2003). The structure, sequence, and organization of the 37 Java API packages in suit have not
3
merged with the underlying ideas because there are multiple ways to express an API with the
4
same or similar functionality. (FOF 33, 38-40, 43, 45-49.)
5
154.
“Under the scenes a faire doctrine, when certain commonplace expressions are
6
indispensable and naturally associated with the treatment of a given idea, those expressions are
7
treated like ideas and therefore not protected by copyright.” Swirsky v. Carey, 376 F.3d 841, 850
8
(9th Cir. 2004). The SSO of the 37 Java API packages in suit are not scenes a faire because these
9
elements are not commonplace, nor are they indispensable or standard to expressing any idea.
10
(FOF 33, 39-40, 42-43, 45-48.)
11
155.
The SSO of the 37 API packages is not dictated by function since very little
12
structure is required for the code to operate with the virtual machine and computer. (FOF 43, 45-
13
48.)
14
156.
Google was not required to copy the 37 API packages for compatibility with the
15
Java programming language. (FOF 40, 42, 50-51.) Google could have designed its own APIs,
16
and did in other areas for Android. (FOF 40, 50, 51.)
17
157.
“Words and short phrases such as names, titles, and slogans” are “not subject to
18
copyright.” 37 C.F.R. § 202.1(a). “[A] combination of unprotectable elements is eligible for
19
copyright protection only if those elements are numerous enough and their selection and
20
arrangement original enough that their combination constitutes an original work of authorship.”
21
Satava v. Lowry, 323 F.3d 805, 811 (9th Cir. 2003). In this case, the original combination of the
22
thousands names of the elements in the 37 Java API packages in suit is copyrightable. (FOF 15,
23
16, 18-23, 29-39, 42-49.)
24
158.
The structure described in written documentation is copyrightable when it reflects
25
creative expression. See, e.g., Situation Mgmt. Sys., Inc. v. ASP Consulting Group, 560 F.3d 53,
26
61 (1st Cir. 2009) (overall arrangement and structure of training manuals found to be subject to
27
copyright protection even though they described uncopyrightable system); Jacobsen v. Katzer,
28
2009 U.S. Dist. LEXIS 115204, at *9-10 (N.D. Cal. Dec. 10, 2009) (selection and arrangement of
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
26
1
data reflecting information obtained from model railroad manufacturers entitled to copyright
2
protection).
3
159.
The structure, sequence, and organization of the documentation for the 37 Java
4
API packages is the same as the structure, sequence, and organization of the class libraries to
5
which they relate since both are generated from the same source code. (FOF 23-24.) These
6
aspects of the documentation are copyrightable for the same reasons that the structure, sequence,
7
and organization of the code are copyrightable.
8
9
160.
Google copied the structure, sequence and organization for the 37 Java API
packages into the Android documentation. (FOF 14, 25-26, 28, 57.)
10
C.
Derivative Works
11
161.
A copyright owner has the exclusive right “to prepare derivative works based upon
12
the copyrighted work.” 17 U.S.C. § 106(2). “A ‘derivative work’ is a work based upon one or
13
more preexisting works, such as a translation.” 17 U.S.C. § 101.
14
162.
Because Google based the code for the Android core libraries on the Java API
15
specifications’ SSO, as well as the English prose descriptions contained therein, Google infringed
16
Oracle’s copyright by creating a derivative work. (FOF 23-26, 57.)
17
163.
In Sheldon v. Metro-Goldwyn Pictures Corp., Judge Learned Hand found
18
copyright infringement when the defendant created a movie that copied much of the detailed plot
19
outline of the plaintiff’s play, although it included none of the dialogue and changed many of the
20
specifics: “The play is the sequence of the confluents of all these means, bound together in an
21
inseparable unity; it may often be most effectively pirated by leaving out the speech, for which a
22
substitute can be found, which keeps the whole dramatic meaning. That as it appears to us is
23
exactly what the defendants have done here, the dramatic significance of the scenes we have
24
recited is the same, almost to the letter.” 81 F.2d 49, 50-56 (2nd Cir. 1936) (emphasis added).
25
See also eScholar LLC v. Otis Educational Sys., Inc., 2005 U.S. Dist. LEXIS 40727, at *25
26
(S.D.N.Y. Nov. 3, 2005) (citing Sheldon and stating “[c]opyright protection of the non-literal
27
elements of a computer program is analogous to protection that has been extended in other areas
28
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
27
1
in this circuit”); Twin Peaks Prods. V. Pul’n Int’l Ltd., 996 F.2d 1366, 1373-74 (2nd Cir. 1993)
2
(detailed recounting of plot outline of TV series held to be infringement).
3
164.
While the ideas behind particular individual elements described in the
4
documentation for the 37 API packages that Google copied may not be copyrightable, Google
5
chose to copy the protectable selection, structure, sequence and organization for the thousands of
6
elements expressed in that documentation, almost in its entirety, and to effectively give all of
7
these elements the same “dramatic meaning” within that copied structure. Sheldon, 81 F.2d at 56.
8
165.
In SAS Institute, Inc. v. S&H Computer Sys. Inc., 605 F. Supp. 816, 830 (M.D. TN.
9
1985), the court held defendant created an infringing derivative work that was “based on” the
10
SAS statistical analysis software by copying its structure. The court rejected the defendant’s
11
attempt to downplay the 44 examples of copying specific lines of code: “In addition, the copying
12
proven at trial does not affect only the specific lines of code cited by Dr. Peterson in his
13
testimony. Rather, to the extent that it represents copying of the organizational and structural
14
details of SAS, such copying pervades the entire S&H product.” Id. (emphasis added).
15
Similarly, in Meredith v. Harper & Row, Publishers, Inc., the court found copyright infringement
16
based on the defendants copying of 11% of a book along with its structure: “Thus I conclude
17
while the Meredith text contains some independent ideas of the author, some independent
18
research, some additional topics and some differing structure, the topic selection and arrangement
19
of the Meredith book are in substantial part the result of copying of the Mussen book not
20
attributable to independent effort by Meredith or the necessary result of limited possibilities for
21
organizing and presenting the material to be covered.” 413 F. Supp. 385, 387 (S.D.N.Y. 1975)
22
(emphasis in original). Google’s deliberate copying of the structure, sequence and organization of
23
the 37 Java APIs pervades all of the 37 accused Android API packages, notwithstanding Google’s
24
claim that it wrote the implementing source code itself.
25
D.
Waiver
26
166.
To show waiver, Google must prove Sun/Oracle had an intent to relinquish its
27
known rights to its copyrights in the 37 API packages and code and that Sun/Oracle manifested
28
that intent in an unequivocal manner. United States v. King Features Entm’t, Inc., 843 F.2d 394,
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
28
1
399 (9th Cir. 1988); Adidas Am., Inc. v. Payless Shoesource, Inc., 546 F. Supp. 2d 1029, 1074
2
(D. Or. 2008) (“waiver must be manifested in an unequivocal manner” (internal citations
3
omitted)); see Novell, Inc. v. Weird Stuff, Inc., 1993 U.S. Dist. LEXIS 6674, at *54 (N.D. Cal.
4
May 14, 1993).
5
167.
“An implied waiver of rights will be found where there is ‘clear, decisive and
6
unequivocal’ conduct which indicates a purpose to waive the legal rights involved.” Adidas,
7
546 F. Supp. 2d at 1074 (quoting Groves v. Prickett, 420 F.2d 1119, 1126 (9th Cir. 1970)).
8
9
10
168.
In light of all the credible evidence, Sun/Oracle did not unequivocally intend to
relinquish its intellectual property rights. (FOF 83-85, 95-101, 103-107.)
169.
The fact that Sun and Oracle expressed continued concern and engaged in repeated
11
negotiations with Google to persuade it to take a license negates any inference from blog posts or
12
otherwise that Oracle had an unequivocal intent to relinquish its rights to the 37 Java API
13
packages. King, 843 F.2d at 399; Adidas, 546 F. Supp. 2d at 1074. (FOF 85-87, 98-99, 102.)
14
170.
Whether Sun/Oracle failed to prevent third parties, such as Apache or GNU
15
Classpath, from infringing is not sufficient to prove Sun/Oracle’s express and affirmative intent to
16
relinquish its copyrights against Google. Adidas, 546 F. Supp. 2d at 1074-75 (citing Novell, 0094
17
WL 16458729, at *13 ([E]ven if [plaintiff] failed to take preventative measures to stop
18
[defendant’s infringement-related activities, failure to act, without more is insufficient evidence
19
of the trademark owner’s intent to waive its right to claim infringement.”)).
20
21
171.
Because Google has not proved that Sun/Oracle manifested an unequivocal intent
to relinquish its rights, Google’s defense of waiver fails.
22
E.
Estoppel
23
172.
“Estoppel arises only when a party’s conduct misleads another to believe that a
24
right will not be enforced and causes him to act to his detriment in reliance upon this belief.”
25
Novell, 1993 U.S. Dist. LEXIS 6674, at *41; Adidas, 564 F. Supp. 2d at 1075.
26
173.
Four elements must be present to establish the defense of estoppel: (1) The party to
27
be estopped must know the facts; (2) he must intend that his conduct shall be acted on or must so
28
act that the party asserting the estoppel has a right to believe it is so intended; (3) the latter must
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
29
1
be ignorant of the true facts; and (4) he must rely on the former’s conduct to his injury.
2
Hampton v. Paramount Pictures Corp., 279 F.2d 100, 104 (9th Cir. 1960); Novell, 1993 U.S.
3
Dist. LEXIS 6674, at *42, 54-55 (N.D. Cal. May 14, 1993).
4
174.
Google had the burden of establishing each of the four elements of estoppel. .
5
Adidas, 546 F. Supp. 2d at 1075 (“Because Payless cannot prove each element of equitable
6
estoppel, the defense must fail.”).
7
175.
Google’s defense relied heavily upon a November 5, 2007 blog post by Jonathan
8
Schwartz and a statement made by Larry Ellison in April 2009, but Google failed to prove that
9
Sun or Oracle knew of Google’s infringement when it made those two public statements, or any
10
other statements or conduct by Sun or Oracle. (FOF 91-94.) As such, Google failed to establish
11
the facts necessary for the first element of this defense.
12
176.
Google also failed to prove that Sun or Oracle intended its conduct to give Google
13
a reason to believe that Sun or Oracle would not seek to enforce any intellectual property rights
14
against Google in connection with Android. (FOF 94-95, 98-101.) Sun continued to pursue
15
discussions with Google regarding Android, and Sun and then Oracle told Google that it needed a
16
license for Android. These facts undermine Google’s defense. (FOF 85-86.)
17
177.
Google also failed to prove that it was ignorant of any facts, including Sun’s
18
assertions of its copyrights in connection with the Java API or Google’s use of Sun’s intellectual
19
property for Android. (FOF 53-56, 58-60, 62-65, 67-74, 81-82.) This element cannot be
20
established given Google’s knowing use of Sun’s copyrighted APIs without any license and
21
Google’s recognition, in its internal documents, that Google faced potential legal action by Sun in
22
connection with Android.
23
178.
Google also failed to prove reliance on any conduct by Sun or Oracle in
24
connection with Android. Google’s documents demonstrated that Google was acutely aware of
25
Sun’s concerns in connection with Android, and Sun sought to have Google take a license and
26
make Android compatible. (FOF 60, 62-63, 65-72, 85-86, 95-96, 98, 114, 117, 121-122, 132.) In
27
response, Google took steps to conceal its conduct from Sun and to avoid further discussions with
28
Sun. Such evidence bars application of this defense. (FOF 123-126.)
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
30
1
179.
Google was never “lulled into a sense of security” by Sun or Oracle. A.C.
2
Aukerman Co. v. R.L. Chaides Constr. Co., 960 F.2d 1020, 1043 (9th Cir. 1992) (“to show
3
reliance, the infringer must have had a relationship or communication with the plaintiff which
4
lulls the infringer into a sense of security in going ahead”). To the contrary, Google was acutely
5
aware of Sun’s concerns over Android, and at one point considered approaching Sun with a
6
proposal to buy Java for hundreds of millions of dollars, including the Java copyrights and
7
patents, and in doing so make Google’s “Java lawsuits go away.” (FOF 129-130.)
8
9
180.
Google’s defense also fails because Google did not change its position in reliance
on any conduct of Sun or Oracle to its detriment. (FOF 136-141.) It had chosen to use Sun’s
10
copyrighted Java APIs long before it announced Android, and before the statements by
11
Mr. Schwartz and Mr. Ellison. (FOF 119.) See Hampton, 279 F.2d at 105 (finding no estoppel
12
where “any change of position by [infringer] was in reliance upon the representations of the third
13
parties and despite the notice conveyed to him by [copyright holder’s] assertion of right printed
14
on each film.”); Novell, 1993 U.S. Dist. LEXIS 6674, at *54-55; Adidas, 546 F. Supp. 2d at 1075
15
(“[T]here is no evidence that Payless actually relied on Adidas’ alleged inaction. Because Payless
16
cannot prove each element of equitable estoppel, the defense must fail.”). (FOF 109-115, 119,
17
123.)
18
181.
Because Google has not proven each element of estoppel, the defense fails.
19
F.
Implied License
20
182.
For the equitable defense of implied license, Google must prove that Oracle/Sun
21
affirmatively granted permission to Google to use the 37 API packages at issue and that the entire
22
course of conduct between the parties over the relevant time period led Google to reasonably infer
23
Oracle/Sun’s consent. Effects Assocs. v. Cohen, 908 F.2d 555, 558-559 (9th Cir. 1990) Implied
24
licenses exist “only in ‘narrow’ circumstances where one party ‘created a work at [the other’s]
25
request and handed it over, intending that [the other] copy and distribute it.” A&M Records,
26
Inc. v. Napster, Inc., 239 F.3d 1004, 1026 (9th Cir. 2001) (citing Effects Assocs., 908 F.2d at 558)
27
(alterations in original); Oddo v. Ries, 743 F.2d 630, 634 (9th Cir. 1984) (in a partnership to
28
create and publish a book, plaintiff handed copyrighted manuscript to defendant for publication,
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
31
1
thus court found plaintiff “impliedly gave the partnership a license to use the articles insofar as
2
they were incorporated in the manuscript”); Metro-Goldwyn-Mayer Studios, Inc. v. Grokster,
3
Ltd., 518 F. Supp. 2d 1197, 1226 (C.D. Cal. 2007) (rejecting implied license defense where
4
“[o]bviously, Plaintiffs did not create their copyrighted works at StreamCast’s request or for
5
StreamCast’s benefit”).
6
183.
Sun/Oracle did not affirmatively grant permission to Google to use the 37 API
7
packages or code at issue here without a license; in fact the record shows the contrary. (FOF 66,
8
83-84, 98-99, 107, 133.)
9
184.
It was not reasonable for Google to infer consent to use the 37 Java APIs without a
10
license because the entire course of conduct between the parties demonstrated Sun/Oracle’s
11
assertion of its IP rights. (FOF 83-108.)
12
G.
Laches
13
185.
For the equitable defense of laches, Google must prove that (1) Oracle/Sun
14
unreasonably delayed filing the lawsuit; (2) the delay was inexcusable, and (3) that Google has
15
suffered material prejudice due to Oracle/Sun’s delay. Danjaq LLC v. Sony Corp., 263 F.3d 942
16
(9th Cir. 2001) (three-part analysis of “delay,” “reasonableness of the delay,” and “prejudice”).
17
186.
First, “the relevant delay is the period from when the plaintiff knew (or should
18
have known) of the allegedly infringing conduct, until the initiation of the lawsuit in which the
19
defendant seeks to counterpose the laches defense.” Danjaq, 263 F.3d at 952.
20
21
22
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 93.)
188.
Courts recognize negotiations with the accused as an excuse for delay. In re Katz
23
Interactive Call Processing Patent Litig., 712 F. Supp. 2d 1080, 1110 (C.D. Cal. 2010) (“the
24
negotiation must ‘ordinarily be continuous and bilaterally progressing, with a fair chance of
25
success, so as to justify significant delays’”); Lucent Techs., Inc. v. Gateway, Inc., 580 F. Supp.
26
2d 1016, 1053 (S.D. Cal. 2008); A.C. Aukerman Co., 960 F.2d at 1033.
27
28
189.
Courts have found delay reasonable or excusable where evidence shows that for
several years leading up to the start of litigation, plaintiff engaged in efforts to sell a license to
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
32
1
defendant or engaged in bilateral negotiations with a fair chance of success. Lucent, 580 F. Supp.
2
2d at 105; In re Katz, 712 F. Supp. 2d at, 1110-11.
3
190.
Since Sun/Oracle’s continued discussions and negotiations with Google regarding
4
licensing options were bilateral and had a fair chance of success, including through the time of
5
Google’s CEO Larry Page’s testimony at trial, Sun/Oracle’s delay in bringing suit is excusable.
6
In re Katz, 712 F. Supp. 2d at 1110-11 (rejecting argument that correspondence between parties
7
were “sporadic” and futile and holding that their 6 year correspondence, up until defendant
8
conclusively communicated that it does not need a license, constituted rebuttal of presumption of
9
laches and raised genuine issue of excuse); Lucent Techs., 580 F. Supp. 2d at 1053 (“Court
10
concludes that any delay was reasonable or excusable since Lucent attempted to seek
11
compensation for its patent through the computer manufacturers”). (FOF 85, 86, 98-100, 102,
12
133.)
13
191.
Third, Google has failed to demonstrate prejudice by showing that it took actions
14
or suffered consequences that it would not have, had Sun/Oracle brought suit promptly. Danjaq,
15
263 F.3d at 955. (FOF 141.)
16
192.
Indeed, “[t]he very purpose of laches as an equitable doctrine – and the reason that
17
it differs from a statute of limitations – is that the claim is barred because the plaintiff’s delay
18
occasioned the defendant’s prejudice. Danjaq, 263 F.3d at 955 (quoting Telink Inc. v. U.S., 24
19
F.3d 42, 45 (9th Cir. 1994)); A.C. Aukerman Co., 960 F.2d 1020, 1033 (9th Cir. 1992) (“Material
20
prejudice to adverse parties resulting from the plaintiff’s delay is essential to the laches
21
defense.”).
22
193.
Google’s policy was to push forward and develop Android with the infringing Java
23
APIs, “making enemies along the way,” and thus did not change its position in reliance on
24
Oracle’s inaction. (FOF 58-65, 71-74, 82, 109-119.)
25
194.
Moreover, “laches is not available in a case of willful infringement, when the
26
infringing conduct occurs ‘with knowledge that the defendant’s conduct constitutes copyright
27
infringement.” Winn v. Opryland Music Group, Inc., 22 Fed. Appx. 728, 729 (9th Cir. 2001)
28
(internal citations omitted).
PLAINTIFF’S PROPOSED FINDINGS OF FACT AND CONCLUSIONS OF LAW
CASE NO. CV 10-03561 WHA
sf-3138210
33
1
195.
As the evidence indicates that Google’s infringement was willful, Google is
2
ineligible to assert the defense of laches. (FOF 57-65, 69-74, 79, 109-119, 122-132.)
3
Dated: May 1, 2012
4
BOIES, SCHILLER & FLEXNER LLP
By: Steven C. Holtzman
Steven C. Holtzman
5
Attorneys for Plaintiff
ORACLE AMERICA, INC.
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
34
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?