Oracle America, Inc. v. Google Inc.

Filing 1191

Brief Oracle's May 23, 2012 Copyright Brief filed byOracle America, Inc.. (Jacobs, Michael) (Filed on 5/23/2012)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

MORRISON & FOERSTER LLP
MICHAEL A. JACOBS (Bar No. 111664)
[e-mail]
KENNETH A. KUWAYTI (Bar No. 145384)
[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]
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

Plaintiff,

24

v.

25

GOOGLE INC.

26

Defendant.

27
28
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

Case No. CV 10-03561 WHA
ORACLE MAY 23, 2012
COPYRIGHT BRIEF
Dept.: Courtroom 8, 19th Floor
Judge: Honorable William H. Alsup

1

Oracle submits this brief in response to the Court’s request for further briefing regarding

2

interfaces, exceptions and interoperability (ECF No. 1181).

3

I.

4

INTERFACES AND EXCEPTIONS
A.

6

Please state how many “interfaces” are included in the joint table supplied by
counsel. (Dkt. No. 1124). Also please state how many “exceptions” were
“thrown” and the extent to which they were duplicated by Google. Each side
should also include one example of an “interface” and one example of a
“throw” to illustrate the most salient points about these features.

7

1.

5

8
9

Interfaces

The joint table at ECF No. 1124 includes 171 interfaces from Java 2 Standard Edition
(“J2SE”) 5.0 and 158 interfaces from Android Froyo.

10

Interfaces can be used to group classes in different packages. For example, the interface

11

java.util.Set is implemented by seven classes spread across three different packages. See TX

12

610.2 at /docs/api/java/util/Set.html under “All Known Implementing Classes.” The classes

13

implementing java.util.Set include, among others, java.util.EnumSet, java.util.HashSet,

14

java.util.concurrent.CopyOnWriteArraySet, and javax.print.attribute.standard.JobStateReasons.

15

Id.

16

While a class can only inherit from one superclass, it can implement more than one

17

interface. TX 984 at 259. The class java.util.HashSet, for example, implements the interfaces

18

java.util.Set, java.lang.Cloneable and java.io.Serializable. TX 610.2 at

19

/docs/api/java/util/HashSet.html. An interface establishes relationships that might not otherwise

20

exist between classes. See TX 984 at 259; RT 589:13-590:23 (Reinhold); RT 1239:5-7

21

(Mitchell).

22

Interfaces influence SSO at the method level as well. Every method declared in an

23

interface must be implemented by each class that implements that interface, or else be inherited

24

from a superclass of that class. TX 984 at 224. As mentioned above, java.util.HashSet

25

implements the interface java.util.Set, which declares 15 distinct methods. The HashSet class

26

implements eight of those methods itself (add, clear, clone, contains, isEmpty, iterator, remove

27

and size); it inherits three of them (equals, hashCode, removeAll, and the toArray methods) from

28
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

1

1

its direct superclass AbstractSet; and it inherits the remainder from AbstractCollection, the direct

2

superclass of AbstractSet. TX 610.2 at /docs/api/java/util/HashSet.html.

3
4
5

Interfaces can also be subtypes of interfaces in different packages. RT 601:22-602:1
(Reinhold) (interfaces in java.nio.Channels are subtypes of the interface java.io.Closeable).
Google copied many of the classes that implement the interfaces defined in the J2SE API,

6

but not all of them. For example, Google implemented only a subset of the classes that

7

implement the interface java.util.Set: Android does not include the class

8

javax.print.attribute.standard.JobStateReasons, which is present in J2SE, because Android did not

9

include the javax.print package. Compare TX 610.2 at /docs/api/java/util/Set.html with TX 767

10

at /java/util/Set.html. As the above shows, the interfaces in J2SE embody significant creative

11

expression. Google copied them, including their complex SSO, by choice, not by necessity.

12

2.

Exceptions

13

Exceptions are used to report error conditions. “When a program violates the semantic

14

constraints of the Java programming language, the Java virtual machine signals this error to the

15

program as an exception.” “Programs can also throw exceptions explicitly, using throw

16

statements.” TX 984 at 297. The API documentation for J2SE 5.0 specifies 176 exceptions in

17

the 37 asserted packages. See package listings for each of the 37 J2SE API packages in TX

18

610.2. Of these, 165 are copied into Android Froyo. Compare id. with TX 767.

19

Based on an analysis of the compiled class libraries for J2SE 5, the throws clauses

20

(exception lists) of the 6,508 J2SE 5.0 methods in the table at ECF No. 1142 contain 2,220

21

exceptions (including scenarios when multiple methods threw the same exceptions). Based on a

22

similar analysis, there are 2,241 exceptions mentioned in the exception lists for Android Froyo.

23

Of these, 1,828 throws clauses (comprising 2,014 exceptions) are identical between J2SE 5.0 and

24

Android Froyo, including the order of exceptions.

25

The list of exceptions a method throws represents the expression of a structural choice.

26

According to the Java Language Specification, “When an exception is thrown, control is

27

transferred from the code that caused the exception to the nearest dynamically-enclosing catch

28

clause of a try statement (§14.20) that handles the exception.” TX 984 at 302. The “catch”
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

2

1

clause that handles the exception can be within the method either directly or indirectly. See id.

2

For example, the method java.security.cert.Certificate declares the following method:

3

public abstract void verify(PublicKey key, String sigProvider)
throws CertificateException, NoSuchAlgorithmException, InvalidKeyException,
NoSuchProviderException, SignatureException

4
5
6
7
8
9

TX 610.2 at /docs/api/java/security/cert/Certificate.html. This method “[v]erifies that this
certificate was signed using the private key that corresponds to the specified public key,” and it
throws various exceptions in the event of unsupported signature algorithms, an incorrect key, and
other scenarios. Id. By specifying that this method “throws” five different types of exceptions,
the API designers have required any code that calls the method to handle all five error scenarios.

10
11
12
13
14
15
16
17

In Android, Google could have created different exception lists using supertypes of the
listed exceptions. “For each checked exception that can result from execution of the body of a
method or constructor, a compile-time error occurs unless that exception type or a supertype of
that exception type is mentioned in a throws clause in the declaration of the method or
constructor.” TX 984 at 221 (emphasis added). For example, in the case of the verify() method
listed above, all of the listed exceptions are subtypes of java.security.GeneralSecurityException.
TX 610.2 at /docs/api/java/security/GeneralSecurityException.html. The method would still
compile if the throws clause had included only GeneralSecurityException.

18
19
20
21
22
23
24
25

The Java Language Specification places no significance on the order of the exceptions in
a throws clause. See TX 984 at 221-22. The fact that Android copied 1,828 exception lists
verbatim shows that Google copied more than what it required for its alleged goal of
“compatibility.” To the extent that the exception lists are identical between Java and Android, it
is because the Android API designers chose to make them identical.
II.

EVIDENCE REGARDING INTEROPERABILITY
A.

To what extent, if at all, have applications and programs written for the J2SE
platform before Android arrived been able to run on Android?

26

No application or program written for the J2SE platform runs on Android. There are

27

several reasons for this: (a) Android applications start up in a completely different way from

28

standard Java applications; (b) Android applications are compiled to Dalvik bytecode rather than
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

3

1

Java bytecode; and (c) Android applications are packaged as “apk” files, which are similar to but

2

incompatible with Java’s “jar” files. Many applications and programs written for the J2SE

3

platform will not run on Android for the additional reason that Google did not include all of the

4

Java API packages and classes. Evidentiary support for each of these points can be found in the

5

trial record as described below.

6
7

The Q&A that Google developed for the Android announcement and “early look” release
of the Android SDK in November 2007 confirms that Android is not interoperable with Java:

8

Q48. Does Android support existing Java apps?

9

A. No.

10

Q49. Is Android Java compatible?

11

A. No.

12
13

TX 383 at 8.
No application written for the Java platform will run on Android, even if it uses only the

14

51 API packages from J2SE 5.0 that Google copied into Android. Java platform applications are

15

required to include a special method called “main” that serves as the entry point (where program

16

execution begins), but Android does not use the main() entry point. The Java platform

17

requirement for the main() method may be found, for example, in Section 2.16.1 of the Java

18

Virtual Machine Specification:

19
20
21
22
23

A Java Virtual Machine starts execution by invoking the method main of some
specified class, passing it a single argument, which is an array of strings. This
causes the specified class to be loaded (§2.16.2), linked (§2.16.3) to other types
that it uses, and initialized (§2.16.4). The method main must be declared public,
static, and void.
TX 25 at 40; see also TX 984 at 309.
Android embodies a different application model than the Java platform. It does not use

24

the main() method as the entry point of an application. As Dr. Astrachan confirmed, Java

25

programs must be rewritten to run on Android:

26
27
28

Q. Mr. Jacobs asked you about the program that you wrote this morning, and he
asked you whether it would run, whether it would compile on the Android
platform as opposed to Java. Would you have written this program any differently
if someone told you it needed to run on the Android platform as opposed to the
Java Platform?
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

4

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

A. I would have changed the main. That’s a Java entry point. Otherwise nothing
else would change.
Q. Okay.
THE COURT: Change what?
THE WITNESS: The main.
THE COURT: Where is that?
THE WITNESS: The Public Static Void Main. That’s a requirement of the Java
Platform and the Java Language on that platform. That’s the launch point for a
program.
THE COURT: You would change it to what?
THE WITNESS: For how to do that on Android. That’s a little different.
RT 2221:11-2222:3 (Astrachan).
Java applications will not run on Android for the additional reason that Java applications
are compiled to Java bytecode, while Android applications are compiled to Dalvik bytecode. See
RT 2287:9-22 (Mitchell). Since programs are not normally distributed in source code format for
security and efficiency reasons, this means a program compiled for distribution for the Java
platform has to be recompiled by the developer for distribution for the Android platform before it
can run on Android. An Android phone does not have the ability to convert Java class files to
Android dex files.
A third reason why Java applications will not run on Android is that Java and Android use
different file formats. Java applications are distributed in “jar” files. See, e.g., TX 610.2 at
/docs/guide/jar/jar.html. Google distributes Android applications in “apk” files. See TX 757.
This is only the tip of the iceberg, however. Oracle has already described elsewhere how
many categories of Java applications that will not run on Android because Google chose not to
include the API packages or classes they require for common functions like interacting with the
graphical user interface, sound, image input/output and printing. See ECF No. 1118 at 18-19.
While Oracle is not aware of any metric that measures the exact percentage of programs that are
incompatible for this reason, it is instructive to look at the relatively simple applications Sun
distributed with JDK5 as demos and samples to teach developers how to program for the Java

28
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

5

1

platform. These demos and samples are contained in the JDK5 archives found in the directory

2

licenseebundles/jdk1.5.0 of TX 623. There are 36 relevant examples. Of these only one, the

3

sample application in sample/nio/server, might run on Android if compiled into Dalvik bytecode

4

and distributed as an apk file but for the fact that, like all Java applications, it uses main() as an

5

entry point. See RT 2221:11-2222:3 (Astrachan). The 20 Java demo applets in demo/applets will

6

not run on Android because Android does not support applets and is missing the required

7

java.applet and java.awt API packages and subpackages. See TX 1072 (list of copied packages).

8

The 11 demo applications in demo/jfc will not run in Android because Android is missing the

9

required java.awt and javax.swing API packages and subpackages, among other reasons. See id.

10

The four applications in demo/management will not run on Android because Android is missing

11

the required java.lang.management API package, among other reasons. See id.1

12

The fact that Android will not run simple applications designed to demonstrate the

13

features of the Java platform is strong evidence that Android was never meant to be compatible

14

with Java.

15

B.

16
17
18
19
20
21
22
23
24
25
26
27
28

To what extent, if at all, have applications and programs written after
Android arrived been able to run both on Android and J2SE?

As shown above, applications written for the Java platform do not run on Android. This
did not change after Android arrived. Applications written for Android do not run on the Java
platform. As with the JDK5 examples above, an examination of the sample applications that
Google provides with the Android SDK to teach developers how to program for Android shows
that none of the Android applications Google included will run on the Java platform, even though
they are written in the Java programming language. (See TX 43\cupcake15 - GOOGLE-0000000523\development\samples.) Dr. Bloch testified that the “simplest program that you can
write in any language is called the Hello World Program. It just uses that programming language
to print Hello World, and that’s how you sort of start off with [a] new language. You learn how to
1

The directory demo/jvmti also contains seven “instrumentation agents” that demonstrate how
the Java Virtual Machine Tools Interface (JVMTI) can be used to access information in a running
VM, but these will not work on Android since Android doesn’t include JVMTI. However JVMTI
is optional under the TCK rules for J2SE 5.0, so Oracle does not include them in its count.

ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

6

1

write a program that simply prints Hello World in the language.” RT 782:23-783:2 (Bloch).

2

Google’s “Hello World” application for Android is called “HelloActivity.java,” and it will not run

3

on the Java platform. See HelloActivity.java in TX43\cupcake15 - GOOGLE-00-

4

00000523\development\samples\HelloActivity\src\com\example\android\helloactivity. Google’s

5

HelloActivity.java lacks a main() method, which is a required Java platform entry point, and it

6

requires classes and methods defined in the android.app and android.os API packages, which do

7

not exist in the Java platform. Id.; see TX 1072 (Android API packages copied from Java begin

8

with “java” or “javax.”); see also RT 2180:3-15 (Astrachan).

9

The other sample applications, which are more complex than “Hello World” yet still

10

relatively simple, are not interoperable with Java either. For example, the LunarLander

11

application requires classes and methods defined in the android.app, android.content,

12

android.content.res, android.graphics, android.graphics.drawable, android.os, android.util,

13

android.view, android.widget API packages, none of which exist in the Java platform. See

14

LunarLander.java and LunarView.java in TX43\cupcake15 - GOOGLE-00-

15

00000523\development\samples\LunarLander\src\com\example\android\lunarlander; TX 1072.

16

Similarly, none of the standard “stock” applications for Android, which include the calculator,

17

calendar, and alarm clock, are interoperable with Java. See, e.g., AlarmClock.java in

18

TX43\cupcake15 - GOOGLE-00-00000523\packages\apps\AlarmClock\src\com\

19

android\alarmclock; TX 1072.

20

When even Google’s simple, sample applications will not run on the Java platform, it

21

confirms what Google said at the inception of Android: Android does not support existing Java

22

applications, and Android is not Java-compatible. TX 383 at 8.

23
24
25
26
27
28

C.

How, if at all, have Android and the replication of virtually all of the 37
packages promoted interoperability?

Android’s use of the 37 API packages copied from Java has not promoted interoperability.
Android has harmed interoperability.
As discussed in sections II.A and II.B above, Android and the Java platform are not
interoperable. Applications and programs written for one will not run on the other. See
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

7

1

RT 1331:16-1332:2 (Mitchell) (“So you don’t really have compatibility. You can’t ship code

2

from one platform to another.”).

3

Google will no doubt argue that by copying some of the Java APIs packages it has

4

furthered interoperability to some degree. But Google cannot claim interoperability even for the

5

37 APIs Google it copied nearly identically because it did not copy everything from those

6

packages. See ECF No. 1124-1 at Ex. A (missing classes and methods in java.awt.font,

7

java.beans, javax.security.auth, java.security.auth.callback, javax.security.auth.login, and

8

javax.security.auth.x500). The result is, as noted above, that many standard Android applications,

9

including “the simplest program you can write in any language” (RT 782:23-783:2 (Bloch)),

10
11

cannot run on Java. See section II.B supra.
This type of partial, selective copying is harmful to interoperability, not helpful. Google’s

12

strategy, known as “embrace and extend,” was to adopt enough of the Java APIs to attract Java

13

developers to Android, but not enough to make Android compatible. Sun successfully raised a

14

similar claim in the Sun v. Microsoft case, where it alleged Microsoft “embraced” Java by

15

licensing the Java technology and then “extended” it by developing “strategic incompatibilities”

16

in the version of Java it created for the Windows platform. Sun Microsystems, Inc. v. Microsoft

17

Corp., 87 F. Supp. 2d 992, 995 (N.D. Cal. 2000). Judge Whyte recognized how damaging such a

18

partially compatible platform can be:

19
20
21
22
23
24
25
26

In the present case, Sun has demonstrated a possibility of irreparable harm, if an
injunction restraining Microsoft’s distribution of non-compliant Java Technology
is not issued. Microsoft’s unauthorized distribution of incompatible
implementations of Sun’s Java Technology threatens to undermine Sun’s goal of
cross-platform and cross-implementation compatibility. The threatened
fragmentation of the Java programming environment harms Sun’s relationship
with other licensees who have implemented Java virtual machines for Win32based and other platforms. In addition, Microsoft’s unparalleled market power and
distribution channels relating to computer operating systems pose a significant risk
that an incompatible and unauthorized version of the Java Technology will become
the de facto standard. The court further finds that money damages are inadequate
to compensate Sun for the harm resulting from Microsoft’s distribution of software
products incorporating non-compliant Java Technology as the harm to Sun’s
revenues and reputation is difficult to quantify.

27
28
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

8

1

Id. at 997-98. See also ADA v. Delta Dental Plans Ass’n, 126 F.3d 977, 981 (7th Cir. 1997)

2

(noting that “standardization of language promotes interchange among professionals” and “[t]he

3

fact that Delta uses most of the Code but made modifications is the reason ADA objects”).

4

Google’s distribution of its “free” Android platform is just as harmful to Oracle. Oracle is

5

forced to compete using its for-charge licensing model against an infringing system that is

6

licensed for free. And, similar to Microsoft in the operating system market, Google has achieved

7

a dominant position in the smartphone market, where Android phones containing these

8

incompatible APIs are being activated at a rate of 750,000 phones per day. See RT 1017:4-16

9

(Morrill).

10

If Google wanted to promote interoperability, it could have made Android compatible. A

11

well-developed system is in place for promoting the interoperability of Java implementations and

12

the platform’s “write once, run anywhere capability,” supported by many individuals and

13

companies. See, e.g., RT 293:8-296:4 (Ellison); 360:6-363: 10 (Kurian); 2055:7-21 (McNealy).

14

The Java specification license allows an independent implementation if, among other things, it

15

“fully implements” the specification, does not “modify, subset, superset or otherwise extend” the

16

Java name space, and passes the TCK. TX 610.1. Google itself acknowledged that “[t]he only

17

way to demonstrate compatibility with the Java specification is by meeting all of the requirements

18

of Sun’s Technology Compatibility Kit, TCK, for a particular edition of Sun’s Java.” RT 976:16-

19

978:1 (deemed admission). But Google never even attempted to have Android pass the TCK.

20

(RT at 984:22-24 (Lee).)

21

Rather than further interoperability by following these procedures and taking a license,

22

Google undermined interoperability by creating an incompatible fork of the Java platform. The

23

uncontroverted evidence at trial was that Google is the only company that is commercially using

24

the Java APIs that has not taken a license. See, e.g., RT 293:8-294:21 (Ellison); 385:20-386:8

25

(Kurian), 487:10-488:7 (Page). Google is a source of incompatibility, not interoperability.

26
27
28
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

9

1
2
3
4
5
6
7
8
9

D.

To what extent was interoperability an actual motive of Google at the time the
decision was made to replicate the 37 packages?

Google never proved interoperability was its motive in replicating the 37 packages. To
the contrary, the evidence showed Google did not care about interoperability. It copied what it
wanted to provide Java developers with a familiar enough programming environment so they
would migrate over to Android.
Under questioning from his own counsel, Google developer Dan Bornstein testified
bluntly that interoperability was not one of Google’s goals:
Q. Did Android implement all the API packages present in any particular Java
Platform?

10

A. No.

11

Q. All right. And why not?

12

A. That wasn’t a goal of the project. The goal of the project was to provide
something that was familiar to developers. It wasn’t to provide any particular
preexisting set of packages.

13
14
15

RT at 1783:15-22 (Bornstein).
Daniel Morrill, the technical program manager for Android compatibility, testified at trial

16

that Google has a compatibility program that “is intended to make sure that compatible Android

17

devices can run applications written to the Android SDK.” (1001:10-12, 1009:19-1010:4). But

18

he made it clear Google does not even try to support applications written to the Java SDK:

19

Q. Now, Android does not support Java applications, correct?

20

A. That is correct.

21

Q. And so Android is not Java compatible, correct?

22

A. That’s correct.

23
24
25
26
27

RT 1010:4-7 (Morrill).
Even Google’s counsel conceded that, rather than promote interoperability, Google chose
to replace Java API packages with Android packages that Google thought were “better:”
So there were lots of packages that would make no sense to put them in Android,
the user interface, some of the other things that make a smart phone a smart phone.
So there was no reason to put those in Android.

28
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

10

1
2
3
4
5
6

Then there were others where we were doing our own Android specific APIs, so
there was no need for the Java ones. We had better ones that we wanted to put in
for our APIs.
So you started with all of them. You took out the ones that weren’t applicable.
You took out the ones where we had better ones. And what you had left was this
collection of 51 that were certainly all of the core ones.
RT 1138:21-1139:12 (emphasis added).
Google’s approach stands in contrast to what Andy Rubin claimed Danger did when it

7

created its smartphone platform. Mr. Rubin stated that Danger expressly set out to try to be

8

interoperable with Java. See RT at 1588:19-25 (“Well we wanted to make sure that when

9

somebody, when one of those university students who graduated knew how to program in Java

10

wrote a program, we wanted to make sure that that program could run on other devices too, not

11

only our device. So we wanted to make sure that we were compatible with other devices that

12

happened to be running the Java programming language.”). Mr. Rubin did not claim there was

13

any such goal for Android.

14

The most Google has argued was that it was trying to create some kind of limited

15

interoperability for the 37 API packages it copied. Dr. Astrachan made this argument. See RT

16

2183:2-11, 2224:3-8 (Astrachan). Dr. Astrachan, of course, cannot speak directly to Google’s

17

motive, which is not a proper subject of expert testimony. The actual evidence that Google

18

intended to further even this limited form of interoperability was scant. Mr. Lee mentioned it in

19

passing, claiming Google referred back to Sun’s API specifications “to make sure that we were

20

maintaining—not—or maintaining interoperability with their implementations.” RT 1201:12-22

21

(Lee). Mr. Lee certainly did not claim Google was trying to achieve interoperability overall,

22

however. Instead, he testified that Google only “supports certain Java APIs,” which he described

23

as the “good stuff from Java.” TX 1067 (Lee Dep.) at 48:10-14, 48:16 (played at RT 982:15-21).

24

In any event, neither Mr. Lee’s nor Dr. Astrachan’s testimony supports the notion that

25

Google was trying to achieve interoperability even with the 37 API packages at issue because, as

26

noted in section II.C above, the parties agree that Google did not include all of the classes or

27

interfaces from even those 37 APIs. See ECF No. 1124.

28
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

11

1

Moreover, even if Google had what it thought were “better” APIs, if its motive had been

2

to promote interoperability then in cases where Google had alternate APIs it preferred it still

3

could have supported the use of the existing standard Java user-interface APIs alongside its own.

4

Google presented no evidence at trial that it ever did anything of the kind.

5

This case is not Sony or Sega for many reasons. See, e.g., ECF No. 853 at 15-16. Of

6

particular relevance here, however, is that Google’s copying has nothing to do with the type of

7

interoperability addressed in those cases. In Sony, the defendant engaged in reverse engineering

8

that was necessary to develop a final product which Sony did not allege infringed its copyrights.

9

Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d 596, 600, 603 (9th Cir. 2000).

10

Likewise in Sega, the court found reverse engineering to be fair use “[w]here disassembly is the

11

only way to gain access to the ideas and functional elements embodied in a copyrighted computer

12

program and where there is a legitimate reason for seeking such access[.]” Sega Enters. Ltd. V.

13

Accolade, Inc., 977 F.2d, 1510, 1527-28 (9th Cir. 1992). The court emphasized that its decision

14

“does not, of course, insulate Accolade from a claim of copyright infringement with respect to its

15

finished products.” Id. at 1528. Notably, in rejecting the contention that copying Sega’s simple

16

20 byte initialization code was not fair use, the court distinguished this basic sequence from the

17

console key in Atari v. Nintendo, because “Creativity and originality went into the design of that

18

program.” Id. at 1524 n. 7 (citing Atari v. Nintendo, 975 F.2d 832, 840 (Fed. Cir. 1992).)

19

Here, Google’s copying was neither “intermediate” nor necessary. Google’s expert

20

admitted that Google could have designed its own APIs and in fact did so elsewhere. See, e.g.,

21

RT 2212:25-2213:19 (Astrachan). Dan Bornstein testified that Google’s copying included API

22

packages “where it might―it might not be necessary, but it would be surprising to not find

23

them.” RT 1782:6-1783:10 (Bornstein). Copying to lure a competitor’s developers is not the

24

same as reverse engineering to ensure interoperability. Unlike the Accolade games that would

25

not have functioned on Sega’s Nintendo system unless Accolade copied the 20 byte instruction

26

sequence, Android could have functioned perfectly well if Google had not copied the Java APIs

27

that took more than a decade to build. And unlike Sony and Sega, Android is not interoperable

28

with Java. The reasoning in Sony and Sega does not apply here.
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

12

1
2

Dated: May 23, 2012

3

MORRISON & FOERSTER LLP
By: /s/ Michael A. Jacobs
Michael A. Jacobs

4

Attorneys for Plaintiff
ORACLE AMERICA, INC.

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
ORACLE MAY 23, 2012 COPYRIGHT BRIEF
CASE NO. CV 10-03561 WHA
pa-1529740

13