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)

Download PDF
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) KENNETH A. KUWAYTI (Bar No. 145384) MARC DAVID PETERS (Bar No. 211725) DANIEL P. MUINO (Bar No. 209624) 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) 333 Main Street, Armonk, NY 10504 Telephone: (914) 749-8200 / Facsimile: (914) 749-8300 STEVEN C. HOLTZMAN (Bar No. 144177) 1999 Harrison St., Suite 900, Oakland, CA 94612 Telephone: (510) 874-1000 / Facsimile: (510) 874-1460 ORACLE CORPORATION DORIAN DALEY (Bar No. 129049) DEBORAH K. MILLER (Bar No. 95527) MATTHEW M. SARBORARIA (Bar No. 211600) 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 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 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 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 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 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 “,” and it will not run 3 on the Java platform. See in TX43\cupcake15 - GOOGLE-00- 4 00000523\development\samples\HelloActivity\src\com\example\android\helloactivity. Google’s 5 lacks a main() method, which is a required Java platform entry point, and it 6 requires classes and methods defined in the 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.content, 12 android.content.res,,, android.os, android.util, 13 android.view, android.widget API packages, none of which exist in the Java platform. See 14 and 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., 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,,,, and 8 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?