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)
[e-mail]
MARC DAVID PETERS (Bar No. 211725)
[e-mail]
DANIEL P. MUINO (Bar No. 209624)
[e-mail]
755 Page Mill Road, Palo Alto, CA 94304-1018
Telephone: [phone] / Facsimile: [phone]
BOIES, SCHILLER & FLEXNER LLP
DAVID BOIES (Admitted Pro Hac Vice)
[e-mail]
333 Main Street, Armonk, NY 10504
Telephone: [phone] / Facsimile: [phone]
STEVEN C. HOLTZMAN (Bar No. 144177)
[e-mail]
1999 Harrison St., Suite 900, Oakland, CA 94612
Telephone: [phone] / Facsimile: [phone]
ALANNA RUTHERFORD (Admitted Pro Hac Vice)
[e-mail]
575 Lexington Avenue, 7th Floor, New York, NY 10022
Telephone: [phone] / Facsimile: [phone]
ORACLE CORPORATION
DORIAN DALEY (Bar No. 129049)
[e-mail]
DEBORAH K. MILLER (Bar No. 95527)
[e-mail]
MATTHEW M. SARBORARIA (Bar No. 211600)
[e-mail]
500 Oracle Parkway, Redwood City, CA 94065
Telephone: [phone] / Facsimile: [phone]
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