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)
mjacobs@mofo.com
KENNETH A. KUWAYTI (Bar No. 145384)
kkuwayti@mofo.com
MARC DAVID PETERS (Bar No. 211725)
mdpeters@mofo.com
DANIEL P. MUINO (Bar No. 209624)
dmuino@mofo.com
755 Page Mill Road, Palo Alto, CA 94304-1018
Telephone: (650) 813-5600 / Facsimile: (650) 494-0792
BOIES, SCHILLER & FLEXNER LLP
DAVID BOIES (Admitted Pro Hac Vice)
dboies@bsfllp.com
333 Main Street, Armonk, NY 10504
Telephone: (914) 749-8200 / Facsimile: (914) 749-8300
STEVEN C. HOLTZMAN (Bar No. 144177)
sholtzman@bsfllp.com
1999 Harrison St., Suite 900, Oakland, CA 94612
Telephone: (510) 874-1000 / Facsimile: (510) 874-1460
ORACLE CORPORATION
DORIAN DALEY (Bar No. 129049)
dorian.daley@oracle.com
DEBORAH K. MILLER (Bar No. 95527)
deborah.miller@oracle.com
MATTHEW M. SARBORARIA (Bar No. 211600)
matthew.sarboraria@oracle.com
500 Oracle Parkway, Redwood City, CA 94065
Telephone: (650) 506-5200 / Facsimile: (650) 506-7114
Attorneys for Plaintiff
ORACLE AMERICA, INC.
19
UNITED STATES DISTRICT COURT
20
NORTHERN DISTRICT OF CALIFORNIA
21
SAN FRANCISCO DIVISION
22
ORACLE AMERICA, INC.
23
Plaintiff,
24
v.
25
GOOGLE INC.
26
Defendant.
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
Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.
Why Is My Information Online?