decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books


Groklaw Gear

Click here to send an email to the editor of this weblog.

You won't find me on Facebook


Donate Paypal

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

Oracle v. Google - Copyright Reply Briefs ~mw
Friday, May 25 2012 @ 08:45 AM EDT

The parties have each responded to the latest copyright brief on the other with respect to, what we can only hope, are the final questions from Judge Alsup before he rules on the issue of copyright protection of APIs. In its reply (1198 [PDF; Text]) Google argues that Oracle has the compatibility argument all wrong. The compatibility Google is talking about is with the Java language, not J2SE. As for the compatibility to which Oracle refers, Google states:

Indeed, Oracle has itself benefitted from the compatibility between the J2SE and Android platforms. For example, Oracle admitted that it accepted Google’s contribution of Josh Bloch’s and source code and incorporated it into Oracle’s OpenJDK 7, which is the current Oracle release of J2SE.
Google also sees Sony v. Connectix as directly supporting its position, a view which, not surprisingly, Oracle does not share.

Oracle (1197 [PDF; Text]) returns to its interoperability argument. However, as we pointed out yesterday, this same interoperability issue exists between the many different Java platforms (J2SE, J2ME, ...).

In the end, nothing to get too excited about in either of these briefs.



05/24/2012 - 1194 - Transcript of Proceedings held on May 23, 2012, before Judge William H. Alsup. Court Reporter/Transcriber Katherine Powell Sullivan, RPR, CRR, CSR, Telephone number 415-794-6659/ Per General Order No. 59 and Judicial Conference policy, this transcript may be viewed only at the Clerks Office public terminal or may be purchased through the Court Reporter/Transcriber until the deadline for the Release of Transcript Restriction.After that date it may be obtained through PACER. Any Notice of Intent to Request Redaction, if required, is due no later than 5 business days from date of this filing. Redaction Request due 6/14/2012. Redacted Transcript Deadline set for 6/25/2012. Release of Transcript Restriction set for 8/22/2012. (Sullivan, Katherine) (Filed on 5/24/2012) (Entered: 05/24/2012)

05/24/2012 - 1195 - Exhibit List Joint List of Admitted Trial Exhibits - Phase 1 by Oracle America, Inc... (Jacobs, Michael) (Filed on 5/24/2012) (Entered: 05/24/2012)

05/24/2012 - 1196 - Exhibit List Joint List of Admitted Trial Exhibits - Phase 2 by Oracle America, Inc... (Jacobs, Michael) (Filed on 5/24/2012) (Entered: 05/24/2012)

05/24/2012 - 1197 - Brief re 1192 Trial Brief Oracle's May 24, 2012 Copyright Reply Brief filed byOracle America, Inc.. (Related document(s) 1192 ) (Jacobs, Michael) (Filed on 5/24/2012) (Entered: 05/24/2012)

05/24/2012 - 1198 - TRIAL BRIEF Google's May 24, 2012 Copyright Liability Trial Brief by Google Inc.. (Attachments: # 1 Exhibit A, # 2 Exhibit B)(Van Nest, Robert) (Filed on 5/24/2012) (Entered: 05/24/2012)




MICHAEL A. JACOBS (Bar No. 111664)
KENNETH A. KUWAYTI (Bar No. 145384)
MARC DAVID PETERS (Bar No. 211725)
DANIEL P. MUINO (Bar No. 209624)
[email address telephone fax]

DAVID BOIES (Admitted Pro Hac Vice)
[email address telephone fax]
STEVEN C. HOLTZMAN (Bar No. 144177)
[email address telephone fax]

DORIAN DALEY (Bar No. 129049)
DEBORAH K. MILLER (Bar No. 95527)
[email address telephone fax]

Attorneys for Plaintiff



Case No. CV 10-03561 WHA

ORACLE’S MAY 24, 2012

Dept.: Courtroom 8, 19th Floor
Judge: Honorable William H. Alsup

Android is not interoperable with Java. Java applications cannot run on Android. Android applications cannot run on Java. This was intentional. Google did not want an interoperable platform and offers no proof it set out to create one. Google took only what it wanted, hijacking the Java developers by using their familiarity with the Java APIs to get them to program for Android. Google’s “compatibility” claim is not supported by the law or the facts.


The parties agree that Android Froyo includes 158 of the 171 interfaces from the 37 API packages in J2SE 5.0. ECF No. 1192 at 1. This illustrates not just the extent of Google’s copying, but also that Google selected the interfaces it wanted to copy. Google’s failure to implement all of the interfaces puts the lie to Google’s claim that “the public interfaces in the 37 API packages are functionally required for compatibility with the APIs in those packages.” Id. at 3. Google’s copying served its own business goals and was not compelled by any compatibility requirement, functional or otherwise. In fact, Google deliberately chose not to be compatible.

Google’s example of the Comparable interface demonstrates this as well. The Java programming language does not require a Comparable interface (TX 1062), and it did not exist in Java before version 1.2 (ECF No. 1192-3 at line 79), so Google did not have to copy it. In J2SE, 50 classes in a variety of packages implement the Comparable interface. Android copies this same structure, but omits a few of the 50 classes. For example, the classes CompositeName and CompoundName from the javax.naming API package each implement Comparable, but Android does not include that package. See TX 610.2 at docsapijavalangComparable.html.

The parties count different numbers of exceptions, but they agree Google copied over 1250 throws clauses. See ECF No. 1192 at 1. Oracle’s exception count shows Google again copied almost all, but not all, of the throws clauses exactly, further confirming that compatibility requirements did not drive its extensive copying. Google gives the example of the FileNotFoundException, which is not required by the Java programming language (TX 1062), but was included in Android anyway. Google failed to include other exceptions defined in J2SE 5.0, such as RefreshFailedException, which is part of Java’s API package but not


Android’s version of the package. Compare TX 610.2 at docsapijavaxsecurityauthpackagesummary. html with TX 767 at javaxsecurityauthpackage-summary.html.


Android is not interoperable with Java. Surely it is a huge red flag that in response to the Court’s questions about interoperability, Google resorts to claiming Android is “compatible with the skills and expectations of Java language programmers.” ECF No. 1192 at 7.

Google states there is no quantitative data in the record showing the extent to which applications written for one platform will run on the other. Id. at 5. Actually, there is. The testimony of both parties’ experts is 0%. See ECF No. 1191 at 4-5. Google could not identify a single application at trial or in its brief that can run on both platforms. But the record contains plenty of evidence of simple applications that will not run on both platforms because Google left out many Java API packages, apparently in favor of its own “better” APIs. See id. at 3-7.

Google can point only to the short piece of code Dr. Astrachan wrote at trial, and his testimony that “For those 37 packages, the code that I write on one platform will run on the other platform.” ECF No. 1192 at 5. As discussed in Oracle’s opening brief, even this is not true, as Dr. Astrachan himself admitted. See ECF No. 1191 at 3-6. Moreover, Google presented no evidence at trial that its selective API copying will allow the reuse of a significant number of such code fragments. It cites only to Dan Bornstein’s vague statement that “there’s a lot source code out there that wasn’t—you know, wasn’t written by—well, that was written by lots of people that already existed that could potentially work just fine on Android.” ECF No. 1192 at 6. Google now claims it selective copying “reduced the effort required to ‘port’ an application” from Java to Android in a way that is “similar” to what is necessary to port an application from one Java platform to another. Id. But the record contains no evidence at all of the effort required to port code from one Java platform to another, or how that compares with porting code from Java to Android. Google’s quotation from Dr. Reinhold has nothing to do with this point. See id.

Google fails to identify any evidence in the record that its copying motive was interoperability. Google cites to only two things. The first is Dan Bornstein’s testimony that the goal was not to create interoperability but only to “provide something that was familiar to


developers.” ECF 1192 at 7 (quoting RT 1783:19-21 (Bornstein)). Mr. Bornstein confirms immediately before and after this sentence that it was not a goal to implement all of the packages in any Java platform. See RT 1783:15-22 (Bornstein). Google also cites the Noser statement of work, which it quotes as stating Google “was ‘interested in compatibility with J2SE 1.5…..’” ECF No. 1192 at 7 (emphasis in original). But the document requires Noser to provide only a subset of packages, and makes clear Google never intended to fully implement even those, stating Google will deliver “a ‘detailed minimum list of methods and classes to be implemented.’” TX 2765 at 21-22. Google wanted to capture Java developers, not achieve interoperability.


Sega is a fair use case. The Ninth Circuit summarized its holding as follows:

We conclude that where disassembly is the only way to gain access to the ideas and functional elements embodied in a copyrighted computer program and where there is a legitimate reason for seeking such access, disassembly is a fair use of the copyrighted work, as a matter of law. Our conclusion does not, of course, insulate Accolade from a claim of copyright infringement with respect to its finished products.
Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1527-28 (9th Cir. 1993).

Google seizes on the court’s statement that “Accolade copied Sega’s software solely in order to discover the functional requirements for compatibility with the Genesis console―aspects of Sega’s programs that are not protected by copyright.” Id. at 1522. But that statement does not help it here. First, Google did not copy the Java APIs to “discover” anything. The APIs were readily available for viewing online and Google copied them into Android, so the holding of Sega does not even apply. Second, Google has not shown the Java APIs are merely “functional requirements.” The Ninth Circuit did not conduct a detailed analysis of this issue in Sega because the question of infringement in the final product was reserved by Sega and left for remand. See id. at 1528. But the decision shows that in determining whether an element of a computer program is a mere functional requirement the court will look to the level of creative expression involved. That is what the court used to distinguish the S-E-G-A 20 byte initialization code from the “original program” in Atari v. Nintendo, 975 F.2d 832, 840 (Fed. Cir. 1992). Sega, 977 F.2d at 1524 n.7 (emphasis in original). Google witnesses admitted there was significant creative


expression here. See RT 750:2-752:14 (Bloch); TX 1090 at 128:8-18 (Astrachan Dep.). Third, uses the term “compatibility” very differently from the Ninth Circuit in Sega. The issue in Sega was that defendant’s games “would not operate” on Sony’s console without copying, not that being “compatible with the skills and expectations of Java language programmers” permitted copying. Compare Sega, 977 F.2d at 1515-16 with ECF No. 1192 at 7.

Google also overlooks the fact that Sega was about fair use. It incorrectly claims that under Sega “it does not matter” whether or not it copied to make Android compatible. ECF No. 1192 at 8. Sega requires a defendant to have “a legitimate reason” for even intermediate copying. See, e.g., Sega, 977 F.2d at 1527-28. Google’s interoperability argument does not pass the red face test. Copying to “embrace and extend” is the opposite of what the court endorsed.


The Court asked the parties to address what Connectix ultimately duplicated to allow desktops to run PlayStation games. The Ninth Circuit and district court opinions do not discuss or analyze this issue. Both courts emphasize that Sony did not accuse the final product of infringement. See, e.g., Sony Computer Entm’t Inc. v. Connectix Corp., 48 F. Supp. 2d 1212, 1217 (N.D. Cal. 1999) (“Sony I”) (“Sony’s copyright infringement claim is based on a theory of intermediate infringement.”); Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d 596, 604 (9th Cir. 2000) (“Sony II”) (“nor does Sony contend that Connectix’s final product contains infringing material”). Unfortunately, because Sony is twelve years old, Oracle could not obtain copies of the complete record within the Court’s briefing timetable.

The materials Oracle has been able to retrieve show the content Connectix duplicated is far simpler than the Java APIs. Connectix alleged it “began with an empty table consisting of entry points into the BIOS.” Connectix’s Opening Appellate Brief, 1999 WL 33623860, at *13 (9th Cir. May 27, 1999). The precise nature of this empty table or its entry points is unclear, but most likely it was a list of memory addresses of functions that game programs could invoke as needed. Connectix alleged that about a third to a half of the functions were “standard ‘C’ language functions that would be familiar to any experienced programmer.” Id. Connectix alleged that it implemented 137 of 242 of the functions from Sony’s BIOS. See id. at *18.


Oracle does not see any reference in the record it retrieved to an application binary interface (“ABI”). An ABI describes low-level system conventions, such as how one routine passes arguments to, and receives a return value from, another. Unlike an API, an ABI does not specify which routines must exist or how they are intended to be used.

As Sony shows, not all interfaces are the same. Nothing in the Sony record suggests that there was significant creativity in the entry point table Connectix copied, in stark contrast to the trial record in this case. Neither opinion addressed whether Connectix copied an original structure, sequence, or organization in its BIOS program or the table. The district court noted that “Sony BIOS consists of a combination of C source code and R3000 micro-processor assembly language.” Sony I, 48 F. Supp. 2d at 1215. The C language does not recognize the concepts of a class or interface hierarchy, and nothing in Connectix’s table approaches the complex interrelationships in the Java APIs. The only reference to sequence at all is Connectix’s claim that its entry point table needed to “contain the same entry points, and be in the same order and format” as Sony’s table. Connectix Opening Appellate Br., 1999 WL 33623860, at *13.

Whether Connectix copied names from Sony’s BIOS, and for what purpose, is also unclear, but it appears to have been very limited, unlike here. Sony alleged that Connectix’s Virtual Game Station (“VGS”) “includes several function names that are identical to function names used in the PlayStation operating system.” Pl.’s Mot. TRO, 1999 WL 33743495 at 2 (N.D. Cal. Feb. 3, 1999). Sony argued this point not to claim that Connectix’s VGS (the final product) was infringing, but instead as evidence to prove that Connectix had, at some intermediate point, disassembled (and therefore copied) Sony’s BIOS when creating the VGS. See id. But it is not clear that the names were used to call the functions—they could have been used for debugging purposes instead—and Connectix’s allegation regarding the table of entry points suggests they were not. Connectix’s Opening Appellate Brief, 1999 WL 33623860, at *13.

In any event, none of this had anything to do with the holding in Sony. Sony, like Sega, was a fair use case about intermediate copying for reverse engineering. See Sony II, 203 F.3d at 608. For the same reasons that Sega does not bear on the copyrightability of the SSO of the Java APIs or absolve Google for its infringement, neither does Sony.


Dated: May 24, 2012


By: /s/ Michael A. Jacobs
Michael A. Jacobs

Attorneys for Plaintiff



ROBERT A. VAN NEST - # 84065
[email address telephone fax]

BRUCE W. BABER (Pro Hac Vice)
[address telephone fax]

DONALD F. ZIMMER, JR. - #112279
CHERYL A. SABNIS - #224323
[email address telephone fax]

IAN C. BALLON - #141819
[address telephone fax]

Attorneys for Defendant



Case No. 3:10-cv-03561 WHA


Dept.: Courtroom 8, 19th Floor
Judge: Hon. William Alsup

I. The exceptions counts in Google’s May 23, 2012 brief

Due to errors in the program used, Google’s May 23, 2012 Brief misstated the number of exceptions thrown by J2SE 5.0 and Android 2.2. As summarized in Exhibit A to this brief, for the 37 packages at issue, the public methods in J2SE 5.0 throw 2,400 exceptions, while the public methods for those packages in Android 2.2 (“Froyo”) throw 2,316 exceptions. For the 37 packages at issue, the public methods in the two platforms throw 2,304 exceptions that are the same in the two platforms, while J2SE throws 107 exceptions that are not thrown by Android— 84 of which are thrown by methods that are not implemented in Android—and Android throws 12 exceptions that are not thrown by J2SE. For most of the packages at issue, the public methods in Android and J2SE throw exactly the same exceptions.1

II. Oracle’s “compatibility” arguments

Oracle argues in its May 23 brief that the Android and J2SE platforms are not compatible for three reasons, but these reasons are irrelevant to determining whether the SSO of the 37 API packages is copyrightable. Specifically, Oracle argues that Android and J2SE applications are not compatible because Android applications (1) typically use a different “entry point” than J2SE applications, (2) once compiled, are in Dalvik bytecode instead of Java bytecode, and (3) once compiled, typically are stored in “apk” files instead of “jar” files.

First, Oracle’s arguments proceed from an erroneous premise—that the “compatibility” analysis should be based on whether the Android platform is compatible in all respects with the J2SE platform. That misses the point. The purpose of implementing the Java language APIs in Android is to allow developers writing in the freely-available Java language to use the familiar, established and basic APIs that Java language developers all learn. See RT 762:13-23 (Bloch); RT 961:13-962:3 (Swetland); RT 1018:4-23 (Morrill); RT 1769:11-17 (Bornstein). Implementing those APIs in Android allows Java language developers to use the skills and experience they have, and ensures that they can reuse source code that they have written using the APIs in the 37 API packages. RT 2183:2-11 (Astrachan). Without these basic APIs, the Java


1 These numbers are not identical to the numbers reported by Oracle, which may be due to slight differences in how the exceptions were counted.


language is largely useless. RT 683:14-684:4 (Reinhold); RT 782:9-14 (Bloch); RT 1477:2-13 (Schmidt); RT 1960:4-8 (Schwartz).

The relevant compatibility analysis, therefore, is whether Google’s implementation of the APIs in the 37 packages is compatible with J2SE’s implementation of those APIs from a technical, computer science perspective—and it is. RT 2172:6-11 (Astrachan); RT 2292:25- 2293:14 (Mitchell). It is irrelevant whether Android is compatible, in its entirety, with a specific product of Oracle, with Oracle’s licensing or business model, or with definitions of “compatibility” that Oracle has chosen to adopt for self-serving business reasons.2

Second, each of Oracle’s arguments also points only to superficial distinctions that ignore that source code that uses the APIs that are common to the two platforms is interoperable with both platforms. With respect to the entry point used, Professor Astrachan explained that while J2SE encloses applications in a method called “main,” Android uses a procedure that is “a little different.” RT 2221:11-2222:3. But Professor Astrachan also explained that, aside from this slightly different startup procedure, “[o]therwise nothing else would change.” RT 2221:18 (emphasis added).3 The other two points that Oracle raised—the differences in the bytecode used and the differences between the “apk” and “jar” file formats—are relevant only to the compiled versions of applications. Neither of the latter two points affects whether source code written for the Android platform will function on the J2SE platform or whether source code written for the J2SE platform can be re-used for the Android platform—the salient question for compatibility.

Oracle further argues that these three arguments represent only the “tip of the iceberg,” in that J2SE and Android applications are not fully compatible because Google did not implement all 168 of the J2SE 5.0 API packages. But as Google explained in its May 23 brief, even if source


2 Oracle implicitly acknowledges in its May 23 brief that its “interoperability” arguments are grounded in its concerns about its “for-charge licensing model” and that it is wedded to the erroneous notion that the only compatibility that matters is the type it prefers, namely that a set of Java APIs is not “compatible” unless it is compatible with “a particular edition of Sun’s Java.” Dkt. 1191 at 9:4-20.

3 Although Professor Astrachan testified that the launch point for applications in Android is “a little different,” there is nothing in the record that states that Android cannot use “main” as an entry point for an Android application. Indeed, a “command line” Android application can use “main” as its entry point.


code written for one platform uses APIs not available on the other platform, the portions of the source code that rely on common APIs will run on both platforms, which means the platforms are, with respect to those APIs, compatible. See Dkt. 1192 at 6:5-10. Professor Mitchell conceded that this is useful. RT 2289:21-23; see also RT 1787:23-1788:4 (Bornstein).

Oracle’s brief illogically assumes that it would for some reason be better for Android to be incompatible in every sense rather than being, as it is, compatible with the APIs in the 37 packages.4 Jonathan Schwartz—Sun’s CEO at the time that Android was launched—testified to the contrary:

Q. And did you actually give interviews in which you said you thought Android was helping Java?

A. I did. . . . .

At least if they picked an Open Source Java implementation, they could be a part of the community. If they had picked something that was completely variant, it would have had no utility to us whatsoever.

RT 1992:2-12.

Indeed, Oracle has itself benefitted from the compatibility between the J2SE and Android platforms. For example, Oracle admitted that it accepted Google’s contribution of Josh Bloch’s and source code and incorporated it into Oracle’s OpenJDK 7, which is the current Oracle release of J2SE. RT 1865:11-20 (Oracle’s Resp. to Google’s RFA No. 170); RT 822:10-15 (Bloch); see also RT 823:3 (Bloch) (testifying that Dr. Reinhold of Oracle praised the performance of TimSort when J2SE 7 was released). It is undisputed that TimSort is compatible with both the J2SE and Android platforms.

III. Sony Comp. Entm’t, Inc. v. Connectix Corp.

In Sony Comp. Entm’t, Inc. v. Connectix Corp., the Ninth Circuit held that Connectix’s copying and disassembly of the Sony PlayStation BIOS—the “basic input-output system” that was the software program that operated the Sony PlayStation video game console—was a fair use


4 Oracle’s quote from Judge Whyte’s decision in Sun v. Microsoft is inapposite. “Write once, run anywhere was never a promise that if you wrote code for one Java platform that it would automatically/magically work on another.” RT 725:10-12 (Reinhold). Unlike Microsoft, Google has never claimed that Android is an implementation of J2SE. Android is a different platform than J2SE.


because Connectix’s purpose in doing so was “for the purpose of gaining access to the unprotected elements of Sony’s software.” 203 F.3d 596, 598, 602 (9th Cir. 2000).

The Ninth Circuit’s opinion does not discuss in any detail precisely what the unprotected elements were; instead, the opinion refers to the “functional” and unprotected elements of the Sony software, without identifying specifically what they are. See, e.g., id. at 603 (“There is no question that the Sony BIOS contains unprotected functional elements.”), 605 (“If Sony wishes to obtain a lawful monopoly on the functional concepts in its software, it must satisfy the more stringent standards of the patent laws.”).

In its opening Ninth Circuit appellate brief, however, Connectix explained that its Virtual Game Station software (“VGS”) emulated both the Sony PlayStation hardware, and the Sony PlayStation BIOS software. In developing VGS, Connectix first emulated the PlayStation’s microprocessor in software. Ex. B (Connectix Br.) at 11.5 Connectix also studied the “interaction between Sony’s BIOS and the hardware” and then “wrote software to emulate the hardware functionality.” Id. at 11-12. The Connectix code that emulated the Sony PlayStation hardware dwarfed the Connectix code that it subsequently wrote that emulated Sony’s BIOS, see id. at 31 n.8, much as the Android source code that implements the 37 API packages is dwarfed by the rest of the Android source code.

After Connectix had written its hardware emulation code, it “reverse engineered Sony’s BIOS by running PlayStation games in conjunction with the BIOS and its software emulator of the hardware.” Id. at 12. This was necessary because “[o]perations systems, system interface procedures, and other programs like the Sony BIOS are not visible to the user when they are operating.” Sony, 203 F.3d at 600. Connectix then “proceeded to write code to emulate the necessary BIOS functionality.” Ex. B at 13. This final step was therefore analogous to the process by which Google wrote its own code implementing the 37 API packages. Connectix “began with an empty table consistent of the entry points into the BIOS.” Id. In order to ensure that the VGS was compatible with PlayStation games, this table had to “contain the same entry


5 Google previously filed a copy of Connectix’s opening appellate brief as Exhibit GG to the Reply Declaration of Michael S. Kwun that was filed on August 29, 2011. See Dkt. 369-3.


points, and be in the same order and format, as the table in Sony’s BIOS.” Id.

It appears that when the software code in PlayStation games invoked the Sony BIOS, this process included the name of the BIOS function that was being accessed. See id. at 13-14 (“Connectix engineers could typically deduce the requisite BIOS functionality by examining the function name, the information sent to and from the BIOS, or the general grouping of functions requested by PlayStation games.”). Through a variety of means, Connectix determined the purpose, parameters and return formats for 137 of the 242 functions implemented in the Sony BIOS,6 and then “independently wrote code to implement the required functionality.” Id. at 13- 15 & n.3. A minority of these functions (“a third to a half”) were standard C programming language functions, id. at 13, while the rest were not. In sum, Connectix’s VGS implemented the Sony PlayStation BIOS interfaces. See JONATHAN BAND &MASANOBU KATOH, INTERFACES ON TRIAL 2.0 at 61 (MIT Press 2011) (in Sony, the Ninth Circuit found that intermediate copies were fair use where “they were necessary for the uncovering of elements not protected by Sony’s copyright—specifically, the BIOS’s interface specifications.”).

Again, this process was analogous to the process by which Google implemented the 37 API packages. Google, like Connectix, implemented some but not all of the functions from the plaintiff’s software system, choosing only those functions necessary to accomplish its purpose. For those functions, Google, like Connectix, ensured that it duplicated the same “entry points” and each function’s functionality, including the information sent to and from the system. Many of the Sony functions, like many of the J2SE functions, performed standard functions familiar to any programmer. Google, like Connectix, wrote its own implementing code. Indeed, the key distinction between the present case and Sony, is that Connectix created intermediate copies of Sony’s implementing code, for which it had to rely on fair use. Google did not copy Oracle’s implementing code, and thus section 102(b) itself precludes copyright infringement liability.


6 Connectix implemented only 137 of the 242 functions because those were the only functions invoked by the games that Connectix tested. Id. at 18. This parallels Google’s decision to implement some but not all of the J2SE 5.0 API packages, and most but not all of the JS2E 5.0 exceptions. Moreover, this means that VGS likely was not “fully compatible” with the Sony PlayStation—and that full compatibility is not relevant to the section 102(b) analysis.


Dated: May 24, 2012


/s/ Robert A. Van Nest

Attorneys for Defendant



Oracle v. Google - Copyright Reply Briefs ~mw | 393 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections thead
Authored by: nsomos on Friday, May 25 2012 @ 08:51 AM EDT
Please post any needed corrections here.
Summerize if possible in posts title.
(Summer is getting closer)

Summerize -> Summarize

[ Reply to This | # ]

OT here
Authored by: SpaceLifeForm on Friday, May 25 2012 @ 09:07 AM EDT


You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

News Picks commentary here
Authored by: SpaceLifeForm on Friday, May 25 2012 @ 09:08 AM EDT
Please note the article you are
referencing and include a link
for future readers.


You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

Comes notes here
Authored by: SpaceLifeForm on Friday, May 25 2012 @ 09:10 AM EDT


You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

Grasping at a thin straw: Oracle v. Google - Copyright Reply Briefs
Authored by: Anonymous on Friday, May 25 2012 @ 09:18 AM EDT
My read of the Oracle brief is that they're trying to tie together two or three independent threads and hoping that the result is a finished quilt. I don't see it working. The pieces don't add up. Oracle's definition of compatibility appears to be with Java as a whole , but has been said dozens of times, this isn't a case about the whole of Java, it is about Android and a couple of functions or procedures. I am not a lawyer, but this line of argument seems weak to me.

[ Reply to This | # ]

Can't have it both ways.
Authored by: Anonymous on Friday, May 25 2012 @ 09:24 AM EDT
Oracle is arguing that Selection, Structure, and
Organization is hard work and copyrightable.

But they're also arguing Android represents the spectre of
fragmentation - it's not completely compatible with Java!

If that's so, then the API for Android, while it might be
inspired by Java, is not the same.

This implies that Google expended "time and effort" to
Select, Structure, and Organize it's API to something that
Oracle itself is arguing is DIFFERENT from Java. That seems
to be a creative act by Oracle's very argument, doesn't it?

Otherwise, Oracle's API itself is derivative of many
languages that came before...

[ Reply to This | # ]

Directional compatibility
Authored by: Anonymous on Friday, May 25 2012 @ 10:27 AM EDT
Oracle's making the argument "Not everything that runs in
Java runs on Android. Therefore, Android isn't compatible
with Java."

That's clever slight-of-hand that misses the point.

Android was never intended as a piece-wise replacement for
Java. It's deliberately a subset of Java. Claiming it's
not "compatible" because it can't run every Java program
isn't the proper definition of "compatible."

The operative question is whether ANDROID programs can run
in JAVA, not the other way round.

[ Reply to This | # ]

It would be nice to have specific examples...
Authored by: Anonymous on Friday, May 25 2012 @ 11:26 AM EDT
of Java programs, with clear descriptions of their purpose and the hardware on
which they'd have to be or are intended to be run, that couldn't be processed
through dexopt and run in the Dalvik VM (Android). It would likely be quite
clear then that Oracle's argument is inappropriate re: interoperability.

It isn't up to Google to go looking for Java programs that could be processed to
run in Android.


[ Reply to This | # ]

I don't get the compatibility argument
Authored by: Anonymous on Friday, May 25 2012 @ 12:32 PM EDT
Does Oracle mean it would be ok if Google had "copied" even *more*?

[ Reply to This | # ]

What is the next show?
Authored by: argee on Friday, May 25 2012 @ 03:37 PM EDT
The SCO cases have dwindled to just the footnotes
on the screen at the end of the show.

Oragaggle is winding down. Season finale is next

News at 11.

What is next? When?


[ Reply to This | # ]

Oracle Didn't Do Homework?
Authored by: Anonymous on Friday, May 25 2012 @ 08:18 PM EDT
Is anyone else surprised by Oracle's statement about how they didn't do their
homework and couldn't find a copy of this case even after several days?

What do they think that will buy them, exactly? Do they intend to use it as an
excuse for misrepresenting the holdings of that case?

[ Reply to This | # ]

Could Google's team throw straws
Authored by: kawabago on Friday, May 25 2012 @ 11:28 PM EDT
Could Google's team throw straws for Oracles team to grasp

[ Reply to This | # ]

Newspicks??Microsoft Requests Takedowns From Google, But Content Remains on Bing
Authored by: Anonymous on Saturday, May 26 2012 @ 12:50 AM EDT
From wired . ... we would expect Bing to remove all of the same links that Microsoft requests Google Search to remove. Unfortunately, this isn’t the case all the time. One reason could be that Microsoft, which recently released a new version of Bing, wants to give itself a slight edge over its largest competitor. Mickey$oft strikes again lol.

[ Reply to This | # ]

Seems like the Connectix case was about ABIs
Authored by: xtifr on Saturday, May 26 2012 @ 03:17 AM EDT

It looks to me like the Connectix case was about ABIs--Application Binary interfaces, not about APIs (Application Program Interface. ABIs are about the kind of binary compatibility that Oracle is discussing, but APIs are for the programmer. They are in the source, and may not even exist anymore once the code passes through a compiler. I'm not sure which should be afforded more protection (assuming the value is non-zero in either case), but my instincts tell me that APIs are less protectable than ABIs!

An API only appears in the source code--though it may match an underlying ABI. It's basically (as I've argued before) an extension to the language, expressive in the same way that words in a language are: it's not the words that are protected (not the API), but the use (a program using that API--as well, of course, as the implementation behind the API). Oracle keeps talking about binary compatibility, which is irrelevant when we're discussing APIs. The point of using an existing API is to provide a familiar language for the programmer. And, like any other computer language, is inherently not protectable.

ABIs, on the other hand, actually involve links between compiled code, and I could see arguing that linking to existing compiled code on either side of an ABI could be creating a derivative work. Any point in a compiled program could be declared as an ABI, but only some are necessary for compatibility, which is why compatibility is an important issue when discussing ABIs in the context of infringement. Which is why I suggest that ABIs are more protectable than APIs. (Though I admit it's a stretch to call an arbitrary point in an existing program an ABI.)

There's a reason why ISO standards for languages like C and C++ (which actually have standards, unlike Java, which really still only has Oracle's whim)--the APIs are part of the language. Even third-party APIs merely extend the language. It's still a language, and the Java language (and like any computer language) is not copyrightable, because it's a means of expression, not an expression itself.

So not only is Oracle's argument unavailing, but they're not even on-point in half of what they talk about.

Do not meddle in the affairs of Wizards, for it makes them soggy and hard to light.

[ Reply to This | # ]

What's reasonable?
Authored by: Anonymous on Sunday, May 27 2012 @ 09:34 AM EDT
I'm pro Google...

That said, what do you think would be a reasonable
judgement, given the evidence we've heard about APIs and

It's not disputed that Google copied the API's. I personally
don't think that the _reason_ for compatibility
- whether for programming compatibility or to help
programmers learn the environment -is of any relevancy. I do
think that it was reasonable for Google to
use the work; Java is free and open - Sun made it that way.
But even if it wasn't open, reusing an API should be fair
use. It's not reasonable to Google to call their work
call Java; that's something that Sun protected. And Google
made no representations that it was Java, so I don't
think that Java fragmentation discussion is at all relevant.
I do think that there is work and choice in designing an
API, but that APIs are functional.

Overall API use. I think it's in the name; they could
reimplement them to their heart's content whether they were
required for the language or not, provided they meet a very
low bar of needing to for interoperability. And personally,
I think even without interoperabililty, these are functional
things, and shouldn't be copyrightable.

SSO. I don't think that Oracle was clear about what they
meant. Not in any evidence I heard, anyway. Google had to
use the same package names to make for
transferability of skills and code between the
platforms. They had to use the same class names for the same
reason. Ditto interface names. Ditto exceptions. In
particular to Java (and not all other programming languages)
they did not have to use the same parameter names to
methods. Some of those parameter names are purely
functional, and there's very little choice - e.g. color.
Others could be different. It's great to be able to reuse
the Java documentation, but this is not a requirement
enforced by the programming language. I think Google should
pay something in respect of the re-use of parameter names
that are non-functional. I'd like to see the tariff set at
$60 in total.

With respect of the order of the methods in classes, and the
classes in the packages, I think Google had some choice. I
haven't checked whether the ordering in Java was
alphabetical, but if it doesn't follow alphabetical
ordering, or some other predicable ordering, and if the
Google ordering is the same, then I'd say this was
copyrightable, and again, the tariff should be $60 in total.

With respect to the 9 lines. I disagree with the judge, and
side with the jury - I'd say they were de-minimus. However,
the judge disagrees. I'd say $60 total tariff for the 9
lines, and I think this is high, considering the way that
those lines entered Android and Java. (I wonder if Oracle
should _pay_ $60 for the use of these lines as part of the
Timsort routines. Oracle having to pay something would be
justice for this unbelievably stupid court case. I'd like to
see them spin that into some sort of win!)

With regard to the test files. They should not have been
present, and whether a subcontractor included them or not is
irrelevant; Google bears responsibility. However, they were
never shipped, and there's no evidence that I know of that
they were of use. I would say $60 total for the

I think the judgement as a whole should be written to
protect the use of APIs where they are being used. It should
distinguish between the API and the implementation. I'm
referring specifically to the API, not the implementation. I
would like to see it being made clear that anything that's
functional is covered by protected use. I'd like to see
specific criticism of the arguments that Oracle has deployed
in this case, and their game playing. I'd like to see
elements of the judgement that make them think twice about
whether it would be a good idea to appeal.

Overall, I think Google was in the right, were using Java
fairly, and that any infringement was inadvertent. I think
$240 is a fair price for their mistakes. I don't think that
costs should be awarded. Actually, I'd like to see Oracle
having to pay Google's costs, but that's unfortunately

[ Reply to This | # ]

Oracle v. Google - Next Steps?
Authored by: Anonymous on Tuesday, May 29 2012 @ 08:40 AM EDT
So, what happens next on this, and is there any expected

Here's what I think still needs to happen (please advise if
I'm missing anything). In no particular order:

I expect at some point the judge will rule on the
outstanding motions, and notably API copyrightability.

We need the bench trial/determination on copyright liability
for the 9 lines of timsort and the decompiled help files.
Not sure if that depends on the API ruling or not.

We need final judgement entered on patents. This may
require waiting for some JMOL motions from Oracle claiming
"no reasonable jury could have found for Google on these
facts" and asking the judge to set aside the verdict.

And then, of course, we wait for the inevitable appeal by
Oracle on patents, by whoever loses the API ruling on
copyrights, and possibly by both on the timsort/helpfiles
copyright (I expect Google to appeal on de minimis for both
and that the judge used an improper definition of the
"complete work," I expect Oracle to lose on infringers
profits and appeal on that).

Is the list above complete and accurate? And do any of the
first 3 steps have an expected timeline?

[ Reply to This | # ]

"de minimis" defined
Authored by: Anonymous on Tuesday, May 29 2012 @ 10:50 AM EDT
There is an old and well-known* saying "De minimis non curat lex",
which means "The law does not concern itself with trifles".

Clearly this is no longer the case, and our Judges are in danger of getting
jelly and cream all over their wigs.

*OK, well-known among lawyers who speak Latin. But well-known enough that it's
usually abbreviated to "de minimis".

[ Reply to This | # ]

About that fragmentation...
Authored by: webmink on Wednesday, May 30 2012 @ 11:00 AM EDT
Going back through my materials to write an article for CWUK this week, I suddenly realised the significance of a video interview I did with the director of Java ME at JavaOne in 2009 which I also blogged. It clearly demonstrates that Java ME was already fragmented in 2004 (when Java Verified launched), that Sun had made multiple attempts to address it, and that it was nothing to do with Android.

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )