Oracle America, Inc. v. Google Inc.

Filing 1192

TRIAL BRIEF Google's May 23, 2012 Copyright Liability Trial Brief by Google Inc.. (Attachments: #1 Exhibit A, #2 Exhibit B, #3 Exhibit C, #4 Exhibit D, #5 Exhibit E)(Van Nest, Robert) (Filed on 5/23/2012)

1
2
3
4
5
6
7
8
9
10
11
12

KEKER & VAN NEST LLP
ROBERT A. VAN NEST - #84065
[e-mail]
CHRISTA M. ANDERSON - #184325
[e-mail]
MICHAEL S. KWUN - #198945
[e-mail]
633 Battery Street
San Francisco, CA 94111-1809
Tel: [phone]
Fax: [phone]

KING & SPALDING LLP
DONALD F. ZIMMER, JR. - #112279
[e-mail]
CHERYL A. SABNIS - #224323
[e-mail]
101 Second Street, Suite 2300
San Francisco, CA 94105
Tel: [phone]
Fax: [phone]

KING & SPALDING LLP
SCOTT T. WEINGAERTNER
(Pro Hac Vice)
[e-mail]
ROBERT F. PERRY
[e-mail]
BRUCE W. BABER (Pro Hac Vice)
1185 Avenue of the Americas
New York, NY 10036
Tel: [phone]
Fax: [phone]

IAN C. BALLON - #141819
[e-mail]
HEATHER MEEKER - #172148
[e-mail]
GREENBERG TRAURIG, LLP
1900 University Avenue
East Palo Alto, CA 94303
Tel: [phone]
Fax: [phone]

13
14

Attorneys for Defendant
GOOGLE INC.

15

UNITED STATES DISTRICT COURT

16

NORTHERN DISTRICT OF CALIFORNIA

17

SAN FRANCISCO DIVISION

18

ORACLE AMERICA, INC.,

19
20
21
22

Plaintiff,

Case No. 3:10-cv-03561 WHA
GOOGLE’S MAY 23, 2012 COPYRIGHT
LIABILITY TRIAL BRIEF

v.
Dept.:
Judge:

GOOGLE INC.,

Courtroom 8, 19th Floor
Hon. William Alsup

Defendant.

23
24
25
26
27
28
GOOGLE’S MAY 23, 2012 COPYRIGHT LIABILITY TRIAL BRIEF
Case No. 3:10-CV-03561 WHA
667463.01

1

Google hereby responds to the Court’s request for more briefing regarding interfaces,

2

exceptions and interoperability. See Dkt. 1181. Like the other aspects of the SSO of the 37 API

3

packages, interfaces and exceptions are functional requirements for compatibility with the APIs in

4

those packages, and therefore are not copyrightable. Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d

5

1510, 1522 (9th Cir. 1992) (citing 17 U.S.C. § 102(b)). By implementing the SSO of the 37 API

6

packages, Google increased the extent to which source code is compatible with both the Android

7

and J2SE platforms.

8

I.

9
10

The interfaces and exceptions that are publicly declared in the 37 API packages are
functional requirements for compatibility with the APIs in those packages, and
therefore are not copyrightable.
A.

11

With respect to the 37 API packages, J2SE and Android declare substantially
the same number of interfaces, and throw exactly the same number of
exceptions.

12

In J2SE 5.0, the 37 API packages at issue include declarations for 171 interfaces, while in

13

Android 2.2 (“Froyo”), the 37 API packages include declarations for 158 interfaces. These 158

14

interfaces in Android 2.2 are a subset of the 171 interfaces in J2SE 5.0, i.e., source code

15

referencing, implementing or extending these 158 interfaces in Android 2.2 will also be

16

compatible with J2SE 5.0. Exhibit A, attached hereto, shows the number of interface declarations

17

on a package-by-package basis. For most of the 37 packages, the number of interface

18

declarations is the same in J2SE and Android. See Ex. A.

1

19

In both J2SE 5.0 and Android 2.2, the public methods in the 37 API packages throw 1,257

20

exceptions. Exhibit B, attached hereto, shows the number of exceptions thrown by the public

21

methods on a package-by-package basis. For each of the 37 packages, the number of exceptions

22

thrown is the same in J2SE and Android. See Ex. B.

23

B.

24

Interfaces are a listing of methods and fields that “capture what is common across . . . very

25

Example: the Comparable interface.

different things,” with the purpose of allowing standardized, simplified interaction with those

26
27
28

1

Exhibits A and B were both created by programmatic analysis of compiled versions of J2SE 5.0
and Android 2.2—i.e., programmatic analysis of compiled versions of the source code that was
admitted into evidence as TX 623 (J2SE 5.0) and TX 46 (Android 2.2).
1
GOOGLE’S MAY 23, 2012 COPYRIGHT LIABILITY TRIAL BRIEF
Case No. 3:10-CV-03561 WHA

667463.01

1

common features. RT 590:9-11 (Reinhold). Like classes and methods, interfaces have a

2

declaration, and are part of the APIs at issue. TX 984 (The Java Language Specification, 3d ed.)

3

at 114; RT 590:1-3 (Reinhold) (“The term Application Programming Interface includes these

4

interfaces in the classes and methods and everything else.”).

5

For example, the java.lang package includes a declaration for the “Comparable” interface.

6

This interface has a single method, called compareTo. The source code declaration of the

7

Comparable interface, without comments, is:

8

public interface Comparable<T> {
...
public int compareTo(T o);
}

9
10

2

Ex. C (excerpt from TX 623), lines 82, 121-22. This means that any class that “implements” the
11
Comparable interface must declare a method called “compareTo” that returns an integer and
12
accepts a single argument that has the same “type” as the class being declared. The
13
documentation for the compareTo method provides that if there are two objects called “x” and
14
“y” that are instantiated from the same class, and that class implements the Comparable interface,
15
the source code expression “x.compareTo(y)” will return a negative integer if x is less than y, a
16
zero if x and y are equal, and a positive integer if x is greater than y. See Ex. C, lines 114-16.
17
The Comparable interface includes only one method, but an interface can have additional
18
methods or fields.
19
The Comparable interface allows a developer to declare a method that relies on the
20
presence of the compareTo method that is promised for all classes that implement the
21
Comparable interface. For example, the ComparableTimSort.java file, written by Josh Bloch,
22
includes a method that sorts arrays of objects that implement the Comparable interface. See
23
Ex. D (TX 45.2), lines 20-22. At various points in ComparableTimSort.java, the source code
24
generically refers to a “Comparable” object, e.g.:
25
if (((Comparable) a[runHi++]).compareTo(a[lo]) < 0) {

26
27
28

2

Exhibit C is a printed version of the file licenseebundles/sourcebundles/tmp/j2se/src/share/classes/java/lang/Comparable.java, from TX 623.
2
GOOGLE’S MAY 23, 2012 COPYRIGHT LIABILITY TRIAL BRIEF
Case No. 3:10-CV-03561 WHA

667463.01

1

Ex. D, line 286. The “(Comparable)” syntax indicates that the object “a” must be an object

2

instantiated from a class that implements the Comparable interface. By making use of the

3

interface construct, Josh Bloch was able to write the ComparableTimSort method in a manner that

4

works for any array of Comparable objects. Indeed, if tomorrow a developer were to create a new

5

class that implemented the Comparable interface, Josh Bloch’s ComparableTimSort method

6

would sort an array of objects instantiated from that new class, even though Josh Bloch could not

7

have known about that developer’s new class when he wrote the source code for the

8

ComparableTimSort method.

9

Had Google not implemented the publicly declared interfaces that are in the 37 API

10

packages, code that depends on them would not work. For example, if Android did not declare

11

the Comparable interface, then a class that includes “implements Comparable” as part of its

12

declaration would not compile. Moreover, had Android omitted the Comparable interface,

13

methods that depend on it, like ComparableTimSort, would not function on the Android platform.

14

Thus, because the public interfaces in the 37 API packages are functionally required for

15

compatibility with the APIs in those packages, those interface declarations are not copyrightable.

16

Sega, 977 F.2d at 1522 (citing 17 U.S.C. § 102(b)).

17

C.

18

Exceptions are a type of class used by the Java language to communicate to a program

Example: the FileNotFoundException exception.

19

that a particular error has occurred. TX 984 at 297. An exception can signal a problem internal

20

to the program, such as having a beginning index that is greater than the ending index when

21

sorting an array. An exception can also signal an external problem, such as a missing file.

22

When an error occurs, the method in which the error occurs is said to “throw” the relevant

23

exception. Id. The method can then either address (“catch”) the exception itself, or pass the

24

exception on to the code that called the method. In the latter case, the declaration of the method

25

generally must include the word “throws” followed by the type of exception that is thrown. Id. at

3

26
27
28

3

Because a method that throws an exception passes that exception to the code that calls the
method, the exception can be thought of as part of the “input-output” schema for a method,
although it is not the same as the “return” for the method.
3
GOOGLE’S MAY 23, 2012 COPYRIGHT LIABILITY TRIAL BRIEF
Case No. 3:10-CV-03561 WHA

667463.01

1

394 (discussing inclusion of throw in method and constructor declarations); see also id. at 301-02,

2

222 (explaining why not all types of exceptions must be listed in the method declaration).

3

Methods may throw more than one exception. Id. at 221.

4

4

As an example, the method java.io.FileReader FileReader(File file) can throw the

5

java.io.FileNotFoundException. This informs the code that called the FileReader method that the

6

requested file could not be found, and thus could not be read. The declaration of the

7

java.io.InputStream method indicates the type of exception that may be thrown so that developers

8

invoking FileReader know that their code needs to “catch” that type of exception:

9
10

public FileReader(File file) throws FileNotFoundException
5

Ex. E (excerpt from TX 610.2 ) (emphasis added).

11

The exceptions named in the throws clause are “part of the contract between the

12

implementor [of the method] and the user [of the method—i.e., the developer writing source code

13

that invokes the method].” TX 984 at 299. Because of this, the Java language specification

14

requires the compiler to check to ensure that exceptions are properly handled. Id. at 299. For

15

example, if “throws FileNotFoundException” is removed from the declaration of a method that

16

throws that exception in the implementation of that method (such as the FileReader method), the

17

class that contains the method will not compile. Id. at 301. In addition, if an application catches

18

that exception, but the method that throws the exception does not have a throw clause with that

19

exception in its declaration, the application that calls the method will fail to compile. Id.

20

As a result, maintaining the correct information about thrown exceptions in the method

21

declaration is necessary for compatibility. Indeed, the thrown exceptions are part of the method

22

declaration. See TX 984 at 210 (defining “Throwsopt” as part of the “MethodHeader”), 221

23

(discussing the “throws” clause). Because the thrown exceptions are part of the functional

24

requirements for compatibility with the 37 API packages, they are not copyrightable. Sega, 977

25

4

26
27
28

The table in Ex. B counts the total number of exceptions thrown by methods in the public API.
Because more than one exception may be thrown by a method, this is larger than the number of
methods that throw exceptions.
5
Exhibit D is a printed version of the file /java/lang/Comparable.html, from TX 610.2. This file
is also available on the web at http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/
Comparable.html.
4
GOOGLE’S MAY 23, 2012 COPYRIGHT LIABILITY TRIAL BRIEF
Case No. 3:10-CV-03561 WHA

667463.01

1

F.2d at 1522 (citing 17 U.S.C. § 102(b)).

2

II.

3
4

Because the SSO of the 37 API packages is functionally required for compatibility
with the APIs in those packages, it is not copyrightable.
A.

Because Android implements the SSO of the 37 API packages, code written
using the APIs in those packages is interoperable between Android and J2SE.

5

There is no quantitative data in the trial record that demonstrates the extent to which J2SE

6

applications written before Android was released are able to run on the Android platform. Nor is

7

there any quantitative data in the trial record that demonstrates the extent to which post-Android

8

applications are able to run both on the Android and J2SE platforms.

9

The record does demonstrate, however, that code that relies on APIs that are common to

10

the two platforms will compile and execute on both platforms. RT 2172:6-11 (Astrachan)

11

(“Q. Do you have an opinion, professor, whether, from a computer science perspective, Android

12

and Java are compatible with respect to the methods and other constructors and other items in the

13

classes of the 37 accused packages? A. Yes. For those 37 packages, the code that I write on one

14

platform will run on the other platform.”); see also RT 2171:24-2172:11 (Astrachan); RT 2287:1-

15

8 (Mitchell) (“I think the point that was illustrated by this code and Dr. Astrachan’s description of

16

it is that, for a given piece of code such as this class that he wrote with a marker, it may run on

17

both platforms if the only things it requires are things that are common to the two”); RT 2292:25-

18

2293:14 (Mitchell) (agreeing that Dr. Astrachan’s code would work both on the Android and

19

J2SE platforms, and that calling the two platforms “compatible” in this sense is using “a great

20

definition of ‘compatible’”). Professor Astrachan explained this during trial as follows:

21
22
23
24
25

Q.
Have you formed an opinion, Professor, regarding what, if anything,
accounts for the fact that the 37 packages in both have the same structure,
organization, and use the same names?
A.
Those same names that we have in Android and in Java are needed so that
the code inter-operates, so that code I write can be reused in another situation. So
for the functionality of using those APIs, the method signatures need to be the
same so that the code will inter-operate and meet programmer expectations.
RT 2183:2-11. Ensuring that the signatures used by Android for the APIs in the 37 packages

26
match the signatures used in J2SE “is what allows me to use the libraries on both—use the code I
27
write, like that code up there, on both platforms. Because I’m using those method signatures, my
28
5
GOOGLE’S MAY 23, 2012 COPYRIGHT LIABILITY TRIAL BRIEF
Case No. 3:10-CV-03561 WHA
667463.01

1

code will function the same on both platforms.” RT 2183:17-20; see also RT 2185:5-9 (“that

2

structure of the names of the classes, packages, and methods needs to be the same so that the code

3

will work on both platforms, be compatible, inter-operate, so that I can call the methods. Those

4

need to be the same.”).

5

Moreover, even to the extent that a J2SE application relies on J2SE APIs that are not

6

supported on the Android platform—or to the extent that an Android application relies on

7

Android APIs that are not supported on the J2SE platform—the portion of the source code that

8

relies on APIs that are common to the two platforms will not need to be rewritten. Thus, even for

9

applications that rely on APIs that are not common to both platforms, the Android and J2SE

10

platforms are still partially compatible. Indeed, Professor Mitchell testified that one reason why

11

he believes Google wanted to use the APIs in the 37 packages is because those APIs “are known

12

and used in existing code.” RT 2289:21-13 (emphasis added); see also RT 1787:23-1788:4

13

(Bornstein) (“And, actually, not even just a matter of comfort, but there’s a lot of source code out

14

there that wasn’t—you know, wasn’t written by—well, that was written by lots of people that

15

already existed that could potentially work just fine on Android. And if we went and changed all

16

the names of things, then that source code wouldn’t just work—”).

17

By implementing these core APIs, Google reduced the effort required to “port” an

18

application from one platform (e.g., the J2SE platform) to another (e.g., the Android platform),

19

thus promoting increased interoperability. This effort is similar to what is necessary to “port”

20

applications from, for example, the J2SE platform to a given profile of the J2ME platform, or

21

from one profile of the J2ME platform to another. As Dr. Reinhold testified:

22
23
24
25
26
27

Write once, run anywhere was never a promise that if you wrote code for
one Java platform that it would automatically/magically work on another.
The write once, run anywhere promise is relative to a one of the Java
platforms. If you write an application that uses Java SE 5, then you can run it on
Sun’s implementation, on Oracle’s implementation, on IBM’s implementation, and
on others.
Will that same code run on a particular configuration of Java ME? Well, it
depends. It might. It might not. It depends which APIs it uses.
RT 725:10-20 (emphasis added).

28
6
GOOGLE’S MAY 23, 2012 COPYRIGHT LIABILITY TRIAL BRIEF
Case No. 3:10-CV-03561 WHA
667463.01

1

In addition, because the Android platform shares a common core set of APIs with the

2

J2SE platform, developers are able to use experience they gain from working with one platform

3

when developing applications for the other platform. Developers expect these core APIs when

4

they write code in the Java language. RT 2202:6-11, 2203:11-15 (Astrachan); RT 2291:1-8

5

(Mitchell); RT 364:17-21 (Kurian); RT 519:16-520:6 (Screven). In this sense, Android is

6

compatible with the skills and expectations of Java language programmers.

7

Finally, the record establishes that interoperability was a motive of Google at the time it

8

made the decision to implement the 37 API packages. Google chose the 37 API packages

9

precisely because Java language developers expect them to be present when they write code in

10

the Java language. RT 1782:6-1783:10 (Bornstein). “The goal of the project was to provide

11

something that was familiar to developers.” RT 1783:19-21. And in hiring the contractor Noser

12

to help write source code implementing the 37 API packages, Google explained in its Statement

13

of Work detailing “the responsibilities of Noser and the Project Services to be provided by Noser”

14

that Google was “interested in compatibility with J2SE 1.5 . . . .” TX 2765 at 9, 12 (emphasis

15

added).

16
17

B.

Under Sega, elements that are functionally required for compatibility are not
copyrightable, regardless of how they are used.

18

In Sega, the Ninth Circuit held that Accolade’s copying and disassembly of Sega’s

19

firmware code was a fair use, because Accolade’s purpose in copying was “for studying or

20

examining the unprotected aspects of a copyrighted computer program . . . .” 977 F.2d at 1520

21

(emphasis added). Those unprotected aspects were “the functional requirements for compatibility

22

with the Genesis console—aspects of Sega’s programs that are not protected by copyright.

23

17 U.S.C. § 102(b).” Id. at 1522 (emphasis added).

24

The logical order of the Ninth Circuit’s reasoning is important. The Ninth Circuit did not

25

hold that the fair use doctrine allowed Accolade to copy aspects of Sega’s programs that were

26

required for compatibility. Instead, the Ninth Circuit held that functional requirements for

27

compatibility are not protected by the Copyright Act in the first instance. That is, Accolade did

28

not need to rely on the fair use doctrine to establish that it was entitled to copy functional
7
GOOGLE’S MAY 23, 2012 COPYRIGHT LIABILITY TRIAL BRIEF
Case No. 3:10-CV-03561 WHA

667463.01

1

requirements for compatibility. Instead, it relied on the fair use doctrine to establish that it was

2

allowed Accolade to copy and disassemble all of Sega’s code to the extent necessary to determine

3

what was functionally required for compatibility.

4

Because aspects of a computer program that are functionally required for compatibility are

5

not copyrightable, it does not matter what the defendant does with them. Even if the defendant’s

6

product is not compatible with the plaintiff’s product, the plaintiff still cannot assert infringement

7

based only on the copying of unprotected elements. “The protection established by the Copyright

8

Act for original works of authorship does not extend to the ideas underlying a work or to the

9

functional or factual aspects of the work.” Sega, 977 F.2d at 1524 (emphasis added) (citing

10

17 U.S.C. § 102(b)). A “party claiming infringement may place no reliance upon any similarity

11

in expression resulting from unprotectable elements.” Apple Computer, Inc. v. Microsoft Corp.,

12

35 F.3d 1435, 1446 (9th Cir. 1994) (quotation marks and citation omitted; emphasis in original).

13

Thus, because the SSO of the 37 API packages is functionally required for compatibility, Google

14

was entitled to use that SSO, regardless of whether its use made Android fully compatible or not.

15

However, as noted, by implementing the SSO of the 37 API packages, Google intended to

16

promote interoperability. And by implementing that SSO, Google increased the extent to which

17

source code written for one platform will operate on the other.

18

Dated: May 23, 2012

KEKER & VAN NEST LLP

19
20

By:

21

/s/ Robert A. Van Nest
ROBERT A. VAN NEST
Attorneys for Defendant
GOOGLE INC.

22
23
24
25
26
27
28
8

GOOGLE’S MAY 23, 2012 COPYRIGHT LIABILITY TRIAL BRIEF
Case No. 3:10-CV-03561 WHA
667463.01