decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

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


Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal


User Functions

Username:

Password:

Don't have an account yet? Sign up as a New User

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

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Oracle v. Google - Now Back to the Copyright Question and How Oracle Fragments Java ~mw
Thursday, May 24 2012 @ 08:10 AM EDT

We all know the outcome of the patent infringement claims, but if you are interested in seeing the special verdict form, here it is [PDF; Text]. Also available is a copy of all of those notes the jury kept sending to the judge asking further questions. (1193 [PDF]) Also, Oracle put one last objection on file before the jury returned its verdict (1189 [PDF; Text]), objecting to the Court's final interpretation of "symbolic reference" for the jury. I think Oracle was looking for a definition that said a "symbolic reference" is whatever we say it is, even when it is no longer symbolic but static.

So now we are back to the remaining and important copyright questions. The parties have each responded to the Court's request for additional (and, I am hopeful, final) briefing on the subject. What is interesting is the spin that each party gives to answering the Court's questions.

In Google's case (1192 [PDF, including Exhibits; Text, excluding exhibits]) everything ties back to compatibility, i.e., the compatibility between Android and Java and the assertion that programs that run on Android should be able to run on Java, at least to the extent they are written to only use the 37 APIs.

The record does demonstrate, however, that code that relies on APIs that are common to the two platforms will compile and execute on both platforms. RT 2172:6-11 (Astrachan) (“Q. Do you have an opinion, professor, whether, from a computer science perspective, Android and Java are compatible with respect to the methods and other constructors and other items in the classes of the 37 accused packages? A. Yes. For those 37 packages, the code that I write on one platform will run on the other platform.”); see also RT 2171:24-2172:11 (Astrachan); RT 2287:1- 8 (Mitchell) (“I think the point that was illustrated by this code and Dr. Astrachan’s description of it is that, for a given piece of code such as this class that he wrote with a marker, it may run on both platforms if the only things it requires are things that are common to the two”); RT 2292:25- 2293:14 (Mitchell) (agreeing that Dr. Astrachan’s code would work both on the Android and J2SE platforms, and that calling the two platforms “compatible” in this sense is using “a great definition of ‘compatible’”).
Google also morphs this compatibility argument into a non-copyrightable functional code argument.

Had Google not implemented the publicly declared interfaces that are in the 37 API packages, code that depends on them would not work. For example, if Android did not declare the Comparable interface, then a class that includes “implements Comparable” as part of its declaration would not compile. Moreover, had Android omitted the Comparable interface, methods that depend on it, like ComparableTimSort, would not function on the Android platform. Thus, because the public interfaces in the 37 API packages are functionally required for compatibility with the APIs in those packages, those interface declarations are not copyrightable.
and
Because aspects of a computer program that are functionally required for compatibility are not copyrightable, it does not matter what the defendant does with them. Even if the defendant’s product is not compatible with the plaintiff’s product, the plaintiff still cannot assert infringement based only on the copying of unprotected elements. “The protection established by the Copyright Act for original works of authorship does not extend to the ideas underlying a work or to the functional or factual aspects of the work.” Sega, 977 F.2d at 1524 (emphasis added) (citing 17 U.S.C. § 102(b)). A “party claiming infringement may place no reliance upon any similarity in expression resulting from unprotectable elements.” Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435, 1446 (9th Cir. 1994) (quotation marks and citation omitted; emphasis in original). Thus, because the SSO of the 37 API packages is functionally required for compatibility, Google was entitled to use that SSO, regardless of whether its use made Android fully compatible or not.
Oracle, for its part, hammers home on identical copying or substantial similarity, skirting the issue of the functional nature of the code or the need (for programmers) for compatibility (1191 [PDF; Text]) There is also a clear contraction between what Google asserts, with respect to program compatibility, and what Oracle asserts. Google argued that at least some programs run on J2SE could run on Android, and Prof. Astrachan, as noted above, actually wrote some code that would run on both, as acknowledged by Oracle's expert, Dr. Mitchell. But Oracle states:

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

...

Many applications and programs written for the J2SE platform will not run on Android for the additional reason that Google did not include all of the Java API packages and classes.

Oracle then lays out how J2SE and Android work differently. And much of the Oracle response focuses on the lack of interoperability between J2SE and Android. What Oracle doesn't mention is that programs written for J2SE are also not necessarily compatible with J2ME because they use different interface styles. (See, e.g., http://www.java-tips.org/ java-me-tips/midp/are-j2se-and-j2me-jvms-bytecode-compatible.html)

So did Oracle (Sun) itself fragment J2SE with J2ME?


***************

Docket

05/23/2012 - 1189 - OBJECTIONS to Answer to Juror May 22 question regarding "symbolic reference" and Request for Curative Instruction by Oracle America, Inc.. (Jacobs, Michael) (Filed on 5/23/2012) (Entered: 05/23/2012)

05/23/2012 - 1190 - JURY VERDICT (Phase II). (dt, COURT STAFF) (Filed on 5/23/2012) (Entered: 05/23/2012)

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

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

05/23/2012 - 1193 - Jury Notes - Phase I and Phase II (4/18/12 - 5/23/12) (dt, COURT STAFF) (Filed on 5/23/2012) (Entered: 05/23/2012)


***************

Documents

1189

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

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

ORACLE CORPORATION
DORIAN DALEY (Bar No. 129049)
[email]
DEBORAH K. MILLER (Bar No. 95527)
[email]
MATTHEW M. SARBORARIA (Bar No. 211600)
[email address telephone fax]

Attorneys for Plaintiff
ORACLE AMERICA, INC.

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

ORACLE AMERICA, INC.
Plaintiff,
v.
GOOGLE INC.
Defendant.

Case No. CV 10-03561 WHA

ORACLE AMERICA, INC.’S
OBJECTION TO COURT’S
ANSWER TO JUROR QUESTION
REGARDING “SYMBOLIC
REFERENCE”AND REQUEST FOR
CURATIVE INSTRUCTION

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


Oracle further objects to the Court’s answer delivered on May 22, 2012 to the question asked by a juror at 10:35 a.m. regarding “the symbolic reference definition” and requests a curative instruction.

As part of its answer to the juror’s question, the Court instructed the jury that a reference to data might be numeric or symbolic, but cannot be both. The Court’s construction of “symbolic reference” does not have a “one or the other” quality, so the Court’s May 22 instruction was not consistent with its claim construction. The inconsistency can be mitigated if the Court clarifies that the “data” referred to in its construction is the ultimate data to be obtained or used after symbolic reference resolution is performed—that is the “data” that is claimed elsewhere in the claim language. Oracle requests that the Court promptly provide a curative instruction on that point for the jury during deliberations on May 23, 2012.

The juror’s question on May 22 at 10:35 a.m. asked:

In the symbolic reference definition, if we find a reference that identifies data by a numeric memory location of the data, does the existence of an initial numeric reference preclude the existence of a symbolic reference?
(RT 4352:8-13.) In response, the Court repeated the construction of “symbolic reference”—“a reference that identifies data by a name other than the numeric memory location of the data, and that is resolved dynamically rather than statically”—but then instructed the jury that the references in question must be in the instructions and that a reference is “either going to be a numeric reference or it’s going to be a symbolic reference.” (RT 4353:9-16.) The Court further stated that “for any given reference, it can’t be both. It’s got to be one or the other.” (Id.) The Court explained the jury’s inquiry was to be as follows:

So how do you tell what it is? You look at the instruction set. You look at the reference. And you ask this question: Is that thing referring to the numeric memory location?

If the answer is yes, then it’s a numeric reference. If the answer is no, it’s not referring to the numeric memory location, then it’s a symbolic reference.

(RT 4353:17-23.) The Court stated:

If you find a numeric reference, that's a numeric reference. End of story. It can't be both. Because a numeric reference is something that refersdirectly to the location in memory where that data is stored. It’s not symbolic.

1


(RT 4354:5-8.)

The Court’s claim construction of “symbolic reference” imposes no such limitation. In particular, under the Court’s construction, a reference could be symbolic as to some data and numeric as to other data. Indeed, so long as the reference is symbolic as to some data, then it “identifies data by a name other than the numeric memory location of the data” and the reference is a symbolic reference, regardless of whether it identifies other data by location. Hence, the answer to the juror’s question should have been, “No, the existence of an initial numeric reference does not preclude the existence of a symbolic reference.” By instructing the jury as it did, the Court imposed an additional limitation on its construction of “symbolic reference” that is not present in the original construction. That additional limitation may result in a finding of noninfringement or no finding at all, as the jury wrestles with the question whether, in Android, an index to an entry in a table can only be a numeric reference to data even if it is also a symbolic reference to data in the data object.

Clarifying what “data” is actually at issue in the Court’s construction could mitigate the harm. The Court’s construction is not explicit on what that “data” may be. Reading the construction of symbolic reference in context, the “data” of the Court’s construction is the “data” that is actually claimed in the ’104 patent: the data that is “obtained” in Claim 11 and the data that is “thereafter used” in Claims 39, 40, and 41. By disambiguating what “data” is at issue in the Court’s construction of symbolic reference, on the facts here, the jury may have less difficulty determining whether a reference is symbolic or numeric.

Oracle’s infringement position is that Dalvik bytecode instructions contain “symbolic references” (as defined by the Court) in the form of indices (including field indices—the “01” from Google’s demonstrative) that identify the actual data to be obtained by a name (“01”) other than the numeric memory location of that data. See, e.g., RT 3303:2-3304:20 (Mitchell); TX 4015, 7:12-13.

By contrast, Google argued that the field indices (“01”) can only be numeric references because they are the location of “data” in the Field ID table of a dex file, which contains information used to perform the resolution process and locate the data to be obtained. Google’s

2/p>


argument ignores that the field indices specify the actual data to be obtained (i.e., the data in an Android data object), making them symbolic references under the Court’s construction of “symbolic reference.” Moreover, the ’104 patent never refers to information used in the resolution process as “data.” Instead, the patent specification and claim language refer to “data” as being thereafter used for the operation identified by the instruction (e.g., the LOAD instruction accesses or fetches a value from a data object). Under the Court’s construction, the jury could find that the indices contained in Dalvik bytecode instructions are “symbolic references” to the actual data they identify—they refer to that data by a name (e.g., field index “01”) other than the numeric memory location of that data (e.g., byte offset “48”).

If the Court clarifies that “data” in its construction means the “data” that is actually claimed in the ’104 patent, then any inconsistency will be mitigated. (’104 patent, Claim 11: “obtaining data in accordance to said numerical references”; Claims 39, 40: “wherein data from a storage location identified by a numeric reference is thereafter used for the operation when the instruction contains a symbolic field reference”; Claim 41: “wherein data from a storage location is used thereafter for the operation when the instruction contains a symbolic field reference.”)

Without that clarification, the jury may be misled into thinking that because Google has argued that a field index (“01”) is a location in the Field ID table, which contains information not claimed or mentioned in the ’104 patent claims, the field index must only be a numeric reference and cannot be a symbolic reference to the claimed data—the actual data to be obtained. That is incorrect under the Court’s construction of “symbolic reference.”

Oracle therefore requests that the Court promptly provide a curative instruction to the jury that the “data” referenced in the asserted claims of the ’104 patent is the claimed data—the actual data to be obtained or used after symbolic reference resolution is performed.

Dated: May 23, 2012

MORRISON & FOERSTER LLP

By: /s/ Michael A. Jacobs
Michael A. Jacobs
Attorneys for Plaintiff
ORACLE AMERICA, INC.

3



1190

IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF CALIFORNIA

ORACLE AMERICA, INC.,
Plaintiff,
v.
GOOGLE INC.,
Defendant.

No. C 10-03561 WHA

SPECIAL VERDICT FORM

YOUR ANSWERS MUST BE UNANIMOUS.

Direct Infringement

1. Has Oracle proven by a preponderance of the evidence that Google directly infringes claims 11, 27, 29, 39, 40, or 41 of United States Patent Number RE38,104?

Yes
(Infringing)
No
(Not Proven)
CLAIM 11:___________X____
CLAIM 27:___________X____
CLAIM 29:___________X____
CLAIM 39:___________X____
CLAIM 40:___________X____
CLAIM 41:___________X____


2. Has Oracle proven by a preponderance of the evidence that Google directly infringes claims 1 or 20 of United States Patent Number 6,061,520?

Yes
(Infringing)
No
(Not Proven)
CLAIM 1:___________X____
CLAIM 20:___________X____

3. Has Oracle proven by clear and convincing evidence that Google willfully infringed one or more claim of an asserted patent? (Answer this question only if above you answered “Yes” to one or more claims of a given patent.)

Yes
(Willful)
No
(Not Proven)
For the '104 Patent:________________
For the '520 Patent:________________

Dated: May 23, 2012.

/s/ Greg Thompson
FOREPERSON

2



1191

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

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

ORACLE CORPORATION
DORIAN DALEY (Bar No. 129049)
[email]
DEBORAH K. MILLER (Bar No. 95527)
[email]
MATTHEW M. SARBORARIA (Bar No. 211600)
[email address telephone fax]

Attorneys for Plaintiff
ORACLE AMERICA, INC.

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

ORACLE AMERICA, INC.
Plaintiff,
v.
GOOGLE INC.
Defendant.

Case No. CV 10-03561 WHA

ORACLE MAY 23, 2012
COPYRIGHT BRIEF

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


Oracle submits this brief in response to the Court’s request for further briefing regarding interfaces, exceptions and interoperability (ECF No. 1181).

I. INTERFACES AND EXCEPTIONS

A. 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.

1. 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.

Interfaces can be used to group classes in different packages. For example, the interface java.util.Set is implemented by seven classes spread across three different packages. See TX 610.2 at /docs/api/java/util/Set.html under “All Known Implementing Classes.” The classes implementing java.util.Set include, among others, java.util.EnumSet, java.util.HashSet, java.util.concurrent.CopyOnWriteArraySet, and javax.print.attribute.standard.JobStateReasons. Id.

While a class can only inherit from one superclass, it can implement more than one interface. TX 984 at 259. The class java.util.HashSet, for example, implements the interfaces java.util.Set, java.lang.Cloneable and java.io.Serializable. TX 610.2 at /docs/api/java/util/HashSet.html. An interface establishes relationships that might not otherwise exist between classes. See TX 984 at 259; RT 589:13-590:23 (Reinhold); RT 1239:5-7 (Mitchell).

Interfaces influence SSO at the method level as well. Every method declared in an interface must be implemented by each class that implements that interface, or else be inherited from a superclass of that class. TX 984 at 224. As mentioned above, java.util.HashSet implements the interface java.util.Set, which declares 15 distinct methods. The HashSet class implements eight of those methods itself (add, clear, clone, contains, isEmpty, iterator, remove and size); it inherits three of them (equals, hashCode, removeAll, and the toArray methods) from

1


its direct superclass AbstractSet; and it inherits the remainder from AbstractCollection, the direct superclass of AbstractSet. TX 610.2 at /docs/api/java/util/HashSet.html.

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, but not all of them. For example, Google implemented only a subset of the classes that implement the interface java.util.Set: Android does not include the class javax.print.attribute.standard.JobStateReasons, which is present in J2SE, because Android did not include the javax.print package. Compare TX 610.2 at /docs/api/java/util/Set.html with TX 767 at /java/util/Set.html. As the above shows, the interfaces in J2SE embody significant creative expression. Google copied them, including their complex SSO, by choice, not by necessity.

2. Exceptions
Exceptions are used to report error conditions. “When a program violates the semantic constraints of the Java programming language, the Java virtual machine signals this error to the program as an exception.” “Programs can also throw exceptions explicitly, using throw statements.” TX 984 at 297. The API documentation for J2SE 5.0 specifies 176 exceptions in the 37 asserted packages. See package listings for each of the 37 J2SE API packages in TX 610.2. Of these, 165 are copied into Android Froyo. Compare id. with TX 767.

Based on an analysis of the compiled class libraries for J2SE 5, the throws clauses (exception lists) of the 6,508 J2SE 5.0 methods in the table at ECF No. 1142 contain 2,220 exceptions (including scenarios when multiple methods threw the same exceptions). Based on a similar analysis, there are 2,241 exceptions mentioned in the exception lists for Android Froyo. Of these, 1,828 throws clauses (comprising 2,014 exceptions) are identical between J2SE 5.0 and Android Froyo, including the order of exceptions.

The list of exceptions a method throws represents the expression of a structural choice. According to the Java Language Specification, “When an exception is thrown, control is transferred from the code that caused the exception to the nearest dynamically-enclosing catch clause of a try statement (§14.20) that handles the exception.” TX 984 at 302. The “catch”

2


clause that handles the exception can be within the method either directly or indirectly. See id. For example, the method java.security.cert.Certificate declares the following method:

public abstract void verify(PublicKey key, String sigProvider)
throws CertificateException, NoSuchAlgorithmException, InvalidKeyException,
NoSuchProviderException, SignatureException
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.

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.

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?
No application or program written for the J2SE platform runs on Android. There are several reasons for this: (a) Android applications start up in a completely different way from standard Java applications; (b) Android applications are compiled to Dalvik bytecode rather than

3


Java bytecode; and (c) Android applications are packaged as “apk” files, which are similar to but incompatible with Java’s “jar” files. Many applications and programs written for the J2SE platform will not run on Android for the additional reason that Google did not include all of the Java API packages and classes. Evidentiary support for each of these points can be found in the trial record as described below.

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:

Q48. Does Android support existing Java apps?

A. No.

Q49. Is Android Java compatible?

A. No.

No application written for the Java platform will run on Android, even if it uses only the 51 API packages from J2SE 5.0 that Google copied into Android. Java platform applications are required to include a special method called “main” that serves as the entry point (where program execution begins), but Android does not use the main() entry point. The Java platform requirement for the main() method may be found, for example, in Section 2.16.1 of the Java Virtual Machine Specification:

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 the main() method as the entry point of an application. As Dr. Astrachan confirmed, Java programs must be rewritten to run on Android:

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?

4


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

5


platform. These demos and samples are contained in the JDK5 archives found in the directory licenseebundles/jdk1.5.0 of TX 623. There are 36 relevant examples. Of these only one, the sample application in sample/nio/server, might run on Android if compiled into Dalvik bytecode and distributed as an apk file but for the fact that, like all Java applications, it uses main() as an entry point. See RT 2221:11-2222:3 (Astrachan). The 20 Java demo applets in demo/applets will not run on Android because Android does not support applets and is missing the required java.applet and java.awt API packages and subpackages. See TX 1072 (list of copied packages). The 11 demo applications in demo/jfc will not run in Android because Android is missing the required java.awt and javax.swing API packages and subpackages, among other reasons. See id. The four applications in demo/management will not run on Android because Android is missing the required java.lang.management API package, among other reasons. See id.1

The fact that Android will not run simple applications designed to demonstrate the features of the Java platform is strong evidence that Android was never meant to be compatible with Java.

B. 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 43cupcake15 - GOOGLE-00- 00000523developmentsamples.) 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.

6


write a program that simply prints Hello World in the language.” RT 782:23-783:2 (Bloch). Google’s “Hello World” application for Android is called “HelloActivity.java,” and it will not run on the Java platform. See HelloActivity.java in TX43cupcake15 - GOOGLE-00- 00000523developmentsamplesHelloActivitysrccomexampleandroidhelloactivity. Google’s HelloActivity.java lacks a main() method, which is a required Java platform entry point, and it requires classes and methods defined in the android.app and android.os API packages, which do not exist in the Java platform. Id.; see TX 1072 (Android API packages copied from Java begin with “java” or “javax.”); see also RT 2180:3-15 (Astrachan).

The other sample applications, which are more complex than “Hello World” yet still relatively simple, are not interoperable with Java either. For example, the LunarLander application requires classes and methods defined in the android.app, android.content, android.content.res, android.graphics, android.graphics.drawable, android.os, android.util, android.view, android.widget API packages, none of which exist in the Java platform. See LunarLander.java and LunarView.java in TX43cupcake15 - GOOGLE-00- 00000523developmentsamplesLunarLandersrccomexampleandroidlunarlander; TX 1072. Similarly, none of the standard “stock” applications for Android, which include the calculator, calendar, and alarm clock, are interoperable with Java. See, e.g., AlarmClock.java in TX43cupcake15 - GOOGLE-00-00000523packagesappsAlarmClocksrccom androidalarmclock; TX 1072.

When even Google’s simple, sample applications will not run on the Java platform, it confirms what Google said at the inception of Android: Android does not support existing Java applications, and Android is not Java-compatible. TX 383 at 8.

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

7


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

Google will no doubt argue that by copying some of the Java APIs packages it has furthered interoperability to some degree. But Google cannot claim interoperability even for the 37 APIs Google it copied nearly identically because it did not copy everything from those packages. See ECF No. 1124-1 at Ex. A (missing classes and methods in java.awt.font, java.beans, javax.security.auth, java.security.auth.callback, javax.security.auth.login, and javax.security.auth.x500). The result is, as noted above, that many standard Android applications, including “the simplest program you can write in any language” (RT 782:23-783:2 (Bloch)), cannot run on Java. See section II.B supra.

This type of partial, selective copying is harmful to interoperability, not helpful. Google’s strategy, known as “embrace and extend,” was to adopt enough of the Java APIs to attract Java developers to Android, but not enough to make Android compatible. Sun successfully raised a similar claim in the Sun v. Microsoft case, where it alleged Microsoft “embraced” Java by licensing the Java technology and then “extended” it by developing “strategic incompatibilities” in the version of Java it created for the Windows platform. Sun Microsystems, Inc. v. Microsoft Corp., 87 F. Supp. 2d 992, 995 (N.D. Cal. 2000). Judge Whyte recognized how damaging such a partially compatible platform can be:

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 Win32- based 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.

8


Id. at 997-98. See also ADA v. Delta Dental Plans Ass’n, 126 F.3d 977, 981 (7th Cir. 1997) (noting that “standardization of language promotes interchange among professionals” and “[t]he fact that Delta uses most of the Code but made modifications is the reason ADA objects”).

Google’s distribution of its “free” Android platform is just as harmful to Oracle. Oracle is forced to compete using its for-charge licensing model against an infringing system that is licensed for free. And, similar to Microsoft in the operating system market, Google has achieved a dominant position in the smartphone market, where Android phones containing these incompatible APIs are being activated at a rate of 750,000 phones per day. See RT 1017:4-16 (Morrill).

If Google wanted to promote interoperability, it could have made Android compatible. A well-developed system is in place for promoting the interoperability of Java implementations and the platform’s “write once, run anywhere capability,” supported by many individuals and companies. See, e.g., RT 293:8-296:4 (Ellison); 360:6-363: 10 (Kurian); 2055:7-21 (McNealy). The Java specification license allows an independent implementation if, among other things, it “fully implements” the specification, does not “modify, subset, superset or otherwise extend” the Java name space, and passes the TCK. TX 610.1. Google itself acknowledged that “[t]he only way to demonstrate compatibility with the Java specification is by meeting all of the requirements of Sun’s Technology Compatibility Kit, TCK, for a particular edition of Sun’s Java.” RT 976:16- 978:1 (deemed admission). But Google never even attempted to have Android pass the TCK. (RT at 984:22-24 (Lee).)

Rather than further interoperability by following these procedures and taking a license, Google undermined interoperability by creating an incompatible fork of the Java platform. The uncontroverted evidence at trial was that Google is the only company that is commercially using the Java APIs that has not taken a license. See, e.g., RT 293:8-294:21 (Ellison); 385:20-386:8 (Kurian), 487:10-488:7 (Page). Google is a source of incompatibility, not interoperability.

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?

A. No.

Q. All right. And why not?

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.

RT at 1783:15-22 (Bornstein).

Daniel Morrill, the technical program manager for Android compatibility, testified at trial that Google has a compatibility program that “is intended to make sure that compatible Android devices can run applications written to the Android SDK.” (1001:10-12, 1009:19-1010:4). But he made it clear Google does not even try to support applications written to the Java SDK:

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

A. That is correct.

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

A. That’s correct.

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.

10


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 created its smartphone platform. Mr. Rubin stated that Danger expressly set out to try to be interoperable with Java. See RT at 1588:19-25 (“Well we wanted to make sure that when somebody, when one of those university students who graduated knew how to program in Java wrote a program, we wanted to make sure that that program could run on other devices too, not only our device. So we wanted to make sure that we were compatible with other devices that happened to be running the Java programming language.”). Mr. Rubin did not claim there was any such goal for Android.

The most Google has argued was that it was trying to create some kind of limited interoperability for the 37 API packages it copied. Dr. Astrachan made this argument. See RT 2183:2-11, 2224:3-8 (Astrachan). Dr. Astrachan, of course, cannot speak directly to Google’s motive, which is not a proper subject of expert testimony. The actual evidence that Google intended to further even this limited form of interoperability was scant. Mr. Lee mentioned it in passing, claiming Google referred back to Sun’s API specifications “to make sure that we were maintaining—not—or maintaining interoperability with their implementations.” RT 1201:12-22 (Lee). Mr. Lee certainly did not claim Google was trying to achieve interoperability overall, however. Instead, he testified that Google only “supports certain Java APIs,” which he described as the “good stuff from Java.” TX 1067 (Lee Dep.) at 48:10-14, 48:16 (played at RT 982:15-21).

In any event, neither Mr. Lee’s nor Dr. Astrachan’s testimony supports the notion that Google was trying to achieve interoperability even with the 37 API packages at issue because, as noted in section II.C above, the parties agree that Google did not include all of the classes or interfaces from even those 37 APIs. See ECF No. 1124.

11


Moreover, even if Google had what it thought were “better” APIs, if its motive had been to promote interoperability then in cases where Google had alternate APIs it preferred it still could have supported the use of the existing standard Java user-interface APIs alongside its own. Google presented no evidence at trial that it ever did anything of the kind.

This case is not Sony or Sega for many reasons. See, e.g., ECF No. 853 at 15-16. Of particular relevance here, however, is that Google’s copying has nothing to do with the type of interoperability addressed in those cases. In Sony, the defendant engaged in reverse engineering that was necessary to develop a final product which Sony did not allege infringed its copyrights. Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d 596, 600, 603 (9th Cir. 2000). Likewise in Sega, the court found reverse engineering to be fair use “[w]here 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[.]” Sega Enters. Ltd. V. Accolade, Inc., 977 F.2d, 1510, 1527-28 (9th Cir. 1992). The court emphasized that its decision “does not, of course, insulate Accolade from a claim of copyright infringement with respect to its finished products.” Id. at 1528. Notably, in rejecting the contention that copying Sega’s simple 20 byte initialization code was not fair use, the court distinguished this basic sequence from the console key in Atari v. Nintendo, because “Creativity and originality went into the design of that program.” Id. at 1524 n. 7 (citing Atari v. Nintendo, 975 F.2d 832, 840 (Fed. Cir. 1992).)

Here, Google’s copying was neither “intermediate” nor necessary. Google’s expert admitted that Google could have designed its own APIs and in fact did so elsewhere. See, e.g., RT 2212:25-2213:19 (Astrachan). Dan Bornstein testified that Google’s copying included API packages “where it might―it might not be necessary, but it would be surprising to not find them.” RT 1782:6-1783:10 (Bornstein). Copying to lure a competitor’s developers is not the same as reverse engineering to ensure interoperability. Unlike the Accolade games that would not have functioned on Sega’s Nintendo system unless Accolade copied the 20 byte instruction sequence, Android could have functioned perfectly well if Google had not copied the Java APIs that took more than a decade to build. And unlike Sony and Sega, Android is not interoperable with Java. The reasoning in Sony and Sega does not apply here.

12


Dated: May 23, 2012

MORRISON & FOERSTER LLP

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

Attorneys for Plaintiff
ORACLE AMERICA, INC.

13



1192

KEKER & VAN NEST LLP
ROBERT A. VAN NEST - # 84065
[email]
CHRISTA M. ANDERSON - # 184325
[email]
DANIEL PURCELL - # 191424
[email address telephone fax]

KING & SPALDING LLP
SCOTT T. WEINGAERTNER (Pro Hac Vice)
[email]
ROBERT F. PERRY
[email]
BRUCE W. BABER (Pro Hac Vice)
[address telephone fax]

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

IAN C. BALLON - #141819
[email]
HEATHER MEEKER - #172148
[email]
GREENBERG TRAURIG, LLP
[address telephone fax]

Attorneys for Defendant
GOOGLE INC.

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

ORACLE AMERICA, INC.,
Plaintiff,
v.
GOOGLE INC.,
Defendant.

Case No. 3:10-cv-03561 WHA

GOOGLE’S MAY 23, 2012 COPYRIGHT
LIABILITY TRIAL BRIEF

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


Google hereby responds to the Court’s request for more briefing regarding interfaces, exceptions and interoperability. See Dkt. 1181. Like the other aspects of the SSO of the 37 API packages, interfaces and exceptions are functional requirements for compatibility with the APIs in those packages, and therefore are not copyrightable. Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1522 (9th Cir. 1992) (citing 17 U.S.C. § 102(b)). By implementing the SSO of the 37 API packages, Google increased the extent to which source code is compatible with both the Android and J2SE platforms.

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

A. With respect to the 37 API packages, J2SE and Android declare substantially
the same number of interfaces, and throw exactly the same number of
exceptions.
In J2SE 5.0, the 37 API packages at issue include declarations for 171 interfaces, while in Android 2.2 (“Froyo”), the 37 API packages include declarations for 158 interfaces. These 158 interfaces in Android 2.2 are a subset of the 171 interfaces in J2SE 5.0, i.e., source code referencing, implementing or extending these 158 interfaces in Android 2.2 will also be compatible with J2SE 5.0. Exhibit A, attached hereto, shows the number of interface declarations on a package-by-package basis.1 For most of the 37 packages, the number of interface declarations is the same in J2SE and Android. See Ex. A.

In both J2SE 5.0 and Android 2.2, the public methods in the 37 API packages throw 1,257 exceptions. Exhibit B, attached hereto, shows the number of exceptions thrown by the public methods on a package-by-package basis. For each of the 37 packages, the number of exceptions thrown is the same in J2SE and Android. See Ex. B.

B. Example: the Comparable interface.
Interfaces are a listing of methods and fields that “capture what is common across . . . very different things,” with the purpose of allowing standardized, simplified interaction with those

______________________

1 Exhibits A and B were both created by programmatic analysis of compiled versions of J2SE 5.0 and Android 2.2—i.e., programmatic analysis of compiled versions of the source code that was admitted into evidence as TX 623 (J2SE 5.0) and TX 46 (Android 2.2).

1


common features. RT 590:9-11 (Reinhold). Like classes and methods, interfaces have a declaration, and are part of the APIs at issue. TX 984 (The Java Language Specification, 3d ed.) at 114; RT 590:1-3 (Reinhold) (“The term Application Programming Interface includes these interfaces in the classes and methods and everything else.”).

For example, the java.lang package includes a declaration for the “Comparable” interface. This interface has a single method, called compareTo. The source code declaration of the Comparable interface, without comments, is:

public interface Comparable {
. . .
public int compareTo(T o);
}
Ex. C (excerpt from TX 623),2 lines 82, 121-22. This means that any class that “implements” the Comparable interface must declare a method called “compareTo” that returns an integer and accepts a single argument that has the same “type” as the class being declared. The documentation for the compareTo method provides that if there are two objects called “x” and “y” that are instantiated from the same class, and that class implements the Comparable interface, the source code expression “x.compareTo(y)” will return a negative integer if x is less than y, a zero if x and y are equal, and a positive integer if x is greater than y. See Ex. C, lines 114-16.

The Comparable interface includes only one method, but an interface can have additional methods or fields. The Comparable interface allows a developer to declare a method that relies on the presence of the compareTo method that is promised for all classes that implement the Comparable interface. For example, the ComparableTimSort.java file, written by Josh Bloch, includes a method that sorts arrays of objects that implement the Comparable interface. See Ex. D (TX 45.2), lines 20-22. At various points in ComparableTimSort.java, the source code generically refers to a “Comparable” object, e.g.:

if (((Comparable) a[runHi++]).compareTo(a[lo])
________________________

2 Exhibit C is a printed version of the file licenseebundles/sourcebundles/ tmp/j2se/src/share/classes/java/lang/Comparable.java, from TX 623.

2


Ex. D, line 286. The “(Comparable)” syntax indicates that the object “a” must be an object instantiated from a class that implements the Comparable interface. By making use of the interface construct, Josh Bloch was able to write the ComparableTimSort method in a manner that works for any array of Comparable objects. Indeed, if tomorrow a developer were to create a new class that implemented the Comparable interface, Josh Bloch’s ComparableTimSort method would sort an array of objects instantiated from that new class, even though Josh Bloch could not have known about that developer’s new class when he wrote the source code for the ComparableTimSort method.

Had Google not implemented the publicly declared interfaces that are in the 37 API packages, code that depends on them would not work. For example, if Android did not declare the Comparable interface, then a class that includes “implements Comparable” as part of its declaration would not compile. Moreover, had Android omitted the Comparable interface, methods that depend on it, like ComparableTimSort, would not function on the Android platform. Thus, because the public interfaces in the 37 API packages are functionally required for compatibility with the APIs in those packages, those interface declarations are not copyrightable. Sega, 977 F.2d at 1522 (citing 17 U.S.C. § 102(b)).

C. Example: the FileNotFoundException exception.
Exceptions are a type of class used by the Java language to communicate to a program that a particular error has occurred. TX 984 at 297. An exception can signal a problem internal to the program, such as having a beginning index that is greater than the ending index when sorting an array. An exception can also signal an external problem, such as a missing file.

When an error occurs, the method in which the error occurs is said to “throw” the relevant exception. Id. The method can then either address (“catch”) the exception itself, or pass the exception on to the code that called the method.3 In the latter case, the declaration of the method generally must include the word “throws” followed by the type of exception that is thrown. Id. at

________________________

3 Because a method that throws an exception passes that exception to the code that calls the method, the exception can be thought of as part of the “input-output” schema for a method, although it is not the same as the “return” for the method.

3


394 (discussing inclusion of throw in method and constructor declarations); see also id. at 301-02, 222 (explaining why not all types of exceptions must be listed in the method declaration). Methods may throw more than one exception.4 Id. at 221.

As an example, the method java.io.FileReader FileReader(File file) can throw the java.io.FileNotFoundException. This informs the code that called the FileReader method that the requested file could not be found, and thus could not be read. The declaration of the java.io.InputStream method indicates the type of exception that may be thrown so that developers invoking FileReader know that their code needs to “catch” that type of exception:

public FileReader(File file) throws FileNotFoundException
Ex. E (excerpt from TX 610.25) (emphasis added).

The exceptions named in the throws clause are “part of the contract between the implementor [of the method] and the user [of the method—i.e., the developer writing source code that invokes the method].” TX 984 at 299. Because of this, the Java language specification requires the compiler to check to ensure that exceptions are properly handled. Id. at 299. For example, if “throws FileNotFoundException” is removed from the declaration of a method that throws that exception in the implementation of that method (such as the FileReader method), the class that contains the method will not compile. Id. at 301. In addition, if an application catches that exception, but the method that throws the exception does not have a throw clause with that exception in its declaration, the application that calls the method will fail to compile. Id.

As a result, maintaining the correct information about thrown exceptions in the method declaration is necessary for compatibility. Indeed, the thrown exceptions are part of the method declaration. See TX 984 at 210 (defining “Throwsopt” as part of the “MethodHeader”), 221 (discussing the “throws” clause). Because the thrown exceptions are part of the functional requirements for compatibility with the 37 API packages, they are not copyrightable. Sega, 977

__________________________

4 The table in Ex. B counts the total number of exceptions thrown by methods in the public API. Because more than one exception may be thrown by a method, this is larger than the number of methods that throw exceptions.

5 Exhibit D is a printed version of the file /java/lang/Comparable.html, from TX 610.2. This file is also available on the web at http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/ Comparable.html.

4


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

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

A. Because Android implements the SSO of the 37 API packages, code written
using the APIs in those packages is interoperable between Android and J2SE.
There is no quantitative data in the trial record that demonstrates the extent to which J2SE applications written before Android was released are able to run on the Android platform. Nor is there any quantitative data in the trial record that demonstrates the extent to which post-Android applications are able to run both on the Android and J2SE platforms.

The record does demonstrate, however, that code that relies on APIs that are common to the two platforms will compile and execute on both platforms. RT 2172:6-11 (Astrachan) (“Q. Do you have an opinion, professor, whether, from a computer science perspective, Android and Java are compatible with respect to the methods and other constructors and other items in the classes of the 37 accused packages? A. Yes. For those 37 packages, the code that I write on one platform will run on the other platform.”); see also RT 2171:24-2172:11 (Astrachan); RT 2287:1- 8 (Mitchell) (“I think the point that was illustrated by this code and Dr. Astrachan’s description of it is that, for a given piece of code such as this class that he wrote with a marker, it may run on both platforms if the only things it requires are things that are common to the two”); RT 2292:25- 2293:14 (Mitchell) (agreeing that Dr. Astrachan’s code would work both on the Android and J2SE platforms, and that calling the two platforms “compatible” in this sense is using “a great definition of ‘compatible’”). Professor Astrachan explained this during trial as follows:

Q. Have you formed an opinion, Professor, regarding what, if anything, accounts for the fact that the 37 packages in both have the same structure, organization, and use the same names?

A. Those same names that we have in Android and in Java are needed so that the code inter-operates, so that code I write can be reused in another situation. So for the functionality of using those APIs, the method signatures need to be the same so that the code will inter-operate and meet programmer expectations.

RT 2183:2-11. Ensuring that the signatures used by Android for the APIs in the 37 packages match the signatures used in J2SE “is what allows me to use the libraries on both—use the code I write, like that code up there, on both platforms. Because I’m using those method signatures, my

5


code will function the same on both platforms.” RT 2183:17-20; see also RT 2185:5-9 (“that structure of the names of the classes, packages, and methods needs to be the same so that the code will work on both platforms, be compatible, inter-operate, so that I can call the methods. Those need to be the same.”).

Moreover, even to the extent that a J2SE application relies on J2SE APIs that are not supported on the Android platform—or to the extent that an Android application relies on Android APIs that are not supported on the J2SE platform—the portion of the source code that relies on APIs that are common to the two platforms will not need to be rewritten. Thus, even for applications that rely on APIs that are not common to both platforms, the Android and J2SE platforms are still partially compatible. Indeed, Professor Mitchell testified that one reason why he believes Google wanted to use the APIs in the 37 packages is because those APIs “are known and used in existing code.” RT 2289:21-13 (emphasis added); see also RT 1787:23-1788:4 (Bornstein) (“And, actually, not even just a matter of comfort, but there’s a lot of 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. And if we went and changed all the names of things, then that source code wouldn’t just work—”).

By implementing these core APIs, Google reduced the effort required to “port” an application from one platform (e.g., the J2SE platform) to another (e.g., the Android platform), thus promoting increased interoperability. This effort is similar to what is necessary to “port” applications from, for example, the J2SE platform to a given profile of the J2ME platform, or from one profile of the J2ME platform to another. As Dr. Reinhold testified:

Write once, run anywhere was never a promise that if you wrote code for one Java platform that it would automatically/magically work on another.

The write once, run anywhere promise is relative to a one of the Java platforms. If you write an application that uses Java SE 5, then you can run it on Sun’s implementation, on Oracle’s implementation, on IBM’s implementation, and on others.

Will that same code run on a particular configuration of Java ME? Well, it depends. It might. It might not. It depends which APIs it uses.

RT 725:10-20 (emphasis added).

6


In addition, because the Android platform shares a common core set of APIs with the J2SE platform, developers are able to use experience they gain from working with one platform when developing applications for the other platform. Developers expect these core APIs when they write code in the Java language. RT 2202:6-11, 2203:11-15 (Astrachan); RT 2291:1-8 (Mitchell); RT 364:17-21 (Kurian); RT 519:16-520:6 (Screven). In this sense, Android is compatible with the skills and expectations of Java language programmers.

Finally, the record establishes that interoperability was a motive of Google at the time it made the decision to implement the 37 API packages. Google chose the 37 API packages precisely because Java language developers expect them to be present when they write code in the Java language. RT 1782:6-1783:10 (Bornstein). “The goal of the project was to provide something that was familiar to developers.” RT 1783:19-21. And in hiring the contractor Noser to help write source code implementing the 37 API packages, Google explained in its Statement of Work detailing “the responsibilities of Noser and the Project Services to be provided by Noser” that Google was “interested in compatibility with J2SE 1.5 . . . .” TX 2765 at 9, 12 (emphasis added).

B. Under Sega, elements that are functionally required for compatibility are not
copyrightable, regardless of how they are used.
In Sega, the Ninth Circuit held that Accolade’s copying and disassembly of Sega’s firmware code was a fair use, because Accolade’s purpose in copying was “for studying or examining the unprotected aspects of a copyrighted computer program . . . .” 977 F.2d at 1520 (emphasis added). Those unprotected aspects were “the functional requirements for compatibility with the Genesis console—aspects of Sega’s programs that are not protected by copyright. 17 U.S.C. § 102(b).” Id. at 1522 (emphasis added).

The logical order of the Ninth Circuit’s reasoning is important. The Ninth Circuit did not hold that the fair use doctrine allowed Accolade to copy aspects of Sega’s programs that were required for compatibility. Instead, the Ninth Circuit held that functional requirements for compatibility are not protected by the Copyright Act in the first instance. That is, Accolade did not need to rely on the fair use doctrine to establish that it was entitled to copy functional

7


requirements for compatibility. Instead, it relied on the fair use doctrine to establish that it was allowed Accolade to copy and disassemble all of Sega’s code to the extent necessary to determine what was functionally required for compatibility.

Because aspects of a computer program that are functionally required for compatibility are not copyrightable, it does not matter what the defendant does with them. Even if the defendant’s product is not compatible with the plaintiff’s product, the plaintiff still cannot assert infringement based only on the copying of unprotected elements. “The protection established by the Copyright Act for original works of authorship does not extend to the ideas underlying a work or to the functional or factual aspects of the work.” Sega, 977 F.2d at 1524 (emphasis added) (citing 17 U.S.C. § 102(b)). A “party claiming infringement may place no reliance upon any similarity in expression resulting from unprotectable elements.” Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435, 1446 (9th Cir. 1994) (quotation marks and citation omitted; emphasis in original). Thus, because the SSO of the 37 API packages is functionally required for compatibility, Google was entitled to use that SSO, regardless of whether its use made Android fully compatible or not.

However, as noted, by implementing the SSO of the 37 API packages, Google intended to promote interoperability. And by implementing that SSO, Google increased the extent to which source code written for one platform will operate on the other.

Dated: May 23, 2012

KEKER & VAN NEST LLP

/s/ Robert A. Van Nest
By: ROBERT A. VAN NEST

Attorneys for Defendant
GOOGLE INC.

8



  


Oracle v. Google - Now Back to the Copyright Question and How Oracle Fragments Java ~mw | 380 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections here!
Authored by: fredex on Thursday, May 24 2012 @ 08:25 AM EDT
Please place any corrections here.

[ Reply to This | # ]

No application or program written for the J2SE platform runs on Android.
Authored by: ThrPilgrim on Thursday, May 24 2012 @ 08:26 AM EDT
Who's up for that challenge?

---
Beware of him who would deny you access to information for in his heart he
considers himself your master.

[ Reply to This | # ]

Is Dilbert working in the stupid lawsuit department?
Authored by: SirHumphrey on Thursday, May 24 2012 @ 08:29 AM EDT
http://www.dilbert.com/strips/comic/2012-05-24/

[ Reply to This | # ]

Off topic
Authored by: SirHumphrey on Thursday, May 24 2012 @ 08:32 AM EDT
Such as the price of Tea in China

[ Reply to This | # ]

Oracle v. Google - Now Back to the Copyright Question and How Oracle Fragments Java
Authored by: Anonymous on Thursday, May 24 2012 @ 08:33 AM EDT
"longer symbolic but static" ? What does that mean?

[ Reply to This | # ]

News picks
Authored by: feldegast on Thursday, May 24 2012 @ 08:34 AM EDT
Please make links clickable

---
IANAL
My posts are ©2004-2012 and released under the Creative Commons License
Attribution-Noncommercial 2.0
P.J. has permission for commercial use.

[ Reply to This | # ]

"applications and programs written for the J2SE platform will not run on Android"
Authored by: Anonymous on Thursday, May 24 2012 @ 09:02 AM EDT
Oracle - "applications and programs written for the J2SE
platform will not run on Android"...

So, Sun's CEO didn't seem to care.

AND, Google doesn't care either.

If they did care, then they would have followed SUN's idea
and rules, where they would have to check for compatibility
using SUN's program.... and on top of that, could call the
whole thing "JAVA". However, they took the Harmony route,
and could make their own, and not call it JAVA, and not make
it perfectly "like" JAVA from a compatibility point of view.

All that SUN CEO thought about, and approved of as being ok,
... as SUN CEO said and meant in court, is that, the real
benefit of folks using JAVA and knockoffs of JAVA, knockoffs
via the free license that SUN allowed others to develop and
program under, is, that the folks out there in the computer
world were using something other than using Microsoft's
government supported Monopoly lock-in software - that SUN
could not compete with if it was "TOO STRONG" and used by
everyone - for fracturing is good, Microsoft ONLY is very
bad. Got it now.

FACT - one reason why GPL software exists, as FREE software
was the only thing for a while that seemed able to exist
without fear of MS building the same thing, and putting you
out of business (or just buying you out, and killing off the
software in favor of their own version). Then, like Fox Pro
... killing their own MS software to move people to buy
something else costing business a lot of money that they
would not have to spend if MS just would support what they
had out there, even if it wasn't making then new license
money.

So, SUN knew about MS, and knew that FREE software (as in
Speech), was one way they could use, so used, to get their
software USED enough so that they could play and license a
little bit (depending) for tools etc as well. AND, maybe
then MS didn't grow anymore into spaces where SUN was
already... including putting their SUN UNIX out of business
via MS OS being so profitable due to APPs and TOOLs, that
none would use the SUN software, or hardware, bye bye SUN.

Free was the only option... remember, the US government and
the courts never really corrected the MS Monopoly, they just
made it look like something was done, but in reality,
everyone in the computer business, who were techs saw the
reality that the lawyers, and judges, and US government
Justice Dept lawyers, could not see (as the lawyers, like in
this case about APIs and SW Patents, don't understand
either).

SW patents, should not exist. Software is MATH. That is a
fact.

[ Reply to This | # ]

Could Google have got a license from someone other than Sun/Oracle?
Authored by: ais523 on Thursday, May 24 2012 @ 09:09 AM EDT
There's something that didn't really resonate in the coverage of the trial for
me, but which seems pretty clear from the jury questions. There's a huge number
of questions all on the same subject: could Google have copied the APIs from
some free-to-use source which wasn't Sun or Oracle? (Apache was mentioned
frequently.)

I'm not sure how I'd have answered these, had I been in the judge/lawyers'
positions.

[ Reply to This | # ]

  • Could Google have got a license from someone other than Sun/Oracle? - Authored by: Anonymous on Thursday, May 24 2012 @ 09:41 AM EDT
  • They did. - Authored by: Anonymous on Thursday, May 24 2012 @ 09:42 AM EDT
    • They did. - Authored by: Anonymous on Thursday, May 24 2012 @ 11:23 AM EDT
      • They did. - Authored by: Mark Haanen on Thursday, May 24 2012 @ 11:31 AM EDT
        • They did. - Authored by: Anonymous on Thursday, May 24 2012 @ 04:26 PM EDT
      • They did. - Authored by: Anonymous on Thursday, May 24 2012 @ 12:38 PM EDT
        • They did. - Authored by: Anonymous on Thursday, May 24 2012 @ 12:47 PM EDT
          • They did. - Authored by: Anonymous on Thursday, May 24 2012 @ 03:01 PM EDT
            • They did. - Authored by: PJ on Thursday, May 24 2012 @ 03:28 PM EDT
          • They did. - Authored by: Anonymous on Thursday, May 24 2012 @ 03:08 PM EDT
            • They did. - Authored by: PJ on Thursday, May 24 2012 @ 03:31 PM EDT
              • They did. - Authored by: BJ on Thursday, May 24 2012 @ 04:18 PM EDT
              • Interesting ... - Authored by: Anonymous on Friday, May 25 2012 @ 08:06 AM EDT
                • Interesting ... - Authored by: Anonymous on Wednesday, May 30 2012 @ 09:25 PM EDT
              • They did. - Authored by: AlexWright on Friday, May 25 2012 @ 11:23 AM EDT
      • They did. - Authored by: Anonymous on Thursday, May 24 2012 @ 01:46 PM EDT
      • They did. - Authored by: PJ on Thursday, May 24 2012 @ 03:30 PM EDT
      • you missed the point I think - Authored by: Anonymous on Thursday, May 24 2012 @ 04:51 PM EDT
Oracle v. Google - Now Back to the Copyright Question and How Oracle Fragments Java
Authored by: Anonymous on Thursday, May 24 2012 @ 09:09 AM EDT
From OraGoogle-1191/ page 3
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.

Oracle doesn't tell the whole truth. In order to stay compatible Google must throw the same Exceptions.

Otherwise Code (which would compile), would wait for the wrong Exception.

This simple example would no longer work correctly.
try {
  verify(publicKey, sigProvider);
} catch (SignatureException ex) {
  LOGGER.warn("Signature Exception", ex);
} catch (GeneralSecurityException ex) {
  LOGGER.error("Other verify exception", ex);
}

[ Reply to This | # ]

Google leaves no stone unturned
Authored by: PolR on Thursday, May 24 2012 @ 09:09 AM EDT
Google says:
because the SSO of the 37 API packages is functionally required for compatibility, Google was entitled to use that SSO, regardless of whether its use made Android fully compatible or not.
So the SSO doesn't become magically copyrightable if compatibility is not implemented. Nice observation.

[ Reply to This | # ]

Oracle v. Google - Now Back to the Copyright Question and How Oracle Fragments Java
Authored by: Anonymous on Thursday, May 24 2012 @ 09:26 AM EDT
Document 1191, page 9 (10/14)
Google undermined interoperability by creating an incompatible fork of the Java platform. The
uncontroverted evidence at trial was that Google is the only company that is commercially using
the Java APIs that has not taken a license. See, e.g., RT 293:8-294:21 (Ellison); 385:20-386:8
(Kurian), 487:10-488:7 (Page).

What is Oracle refering to?

I thought HP had its own jvm and that there are others too?

Am I missing something?

[ Reply to This | # ]

Interfaces
Authored by: Anonymous on Thursday, May 24 2012 @ 09:33 AM EDT
To respond to Oracle, even J2SE does not distribute all classes that
implement the interfaces defined in the JAVA API.

Interfaces are defined so that the API can call code (classes and methods) not
yet implemented. When you create a class in a modern IDE and state that it
implements an interface, that IDE will copy the SSO of that interface to help
you. If interfaces are copywriteable, then IDEs such as Eclipse are inducers to

infringement. In fact, code that uses an interface requires that it has the same

SSO as defined to even include the fully qualified name of that interface.

The public methods on a class are considered to be the interface of that class.

The only difference is that you cannot declare a class as implementing
another class.

This shows that APIs are generally considered to be uncopywriteable subject
matter by the industry.

[ Reply to This | # ]

Oracle v. Google - Now Back to the Copyright Question and How Oracle Fragments Java
Authored by: Anonymous on Thursday, May 24 2012 @ 09:38 AM EDT
Love this line from Oracle's brief:
Copying to lure a competitor’s developers is not the same as reverse engineering to ensure interoperability.
First, "lure"--having a subset of Java skills apply to both Android and Java is actually of benefit to Oracle. Consider a developer who must decide whether to invest in learning Java or in learning Objective C.

Second, "competitor"--where exactly can I buy that Pure Java smartphone?

[ Reply to This | # ]

Interesting original Jury notes: Many of them were never answered?
Authored by: Anonymous on Thursday, May 24 2012 @ 09:41 AM EDT
It's fascinating to see those original handwritten notes from
the Jury. Thanks so much, PJ!

It's interesting that many of those notes don't seem to have
received answers. Wonder why...

[ Reply to This | # ]

Oracle v. Google - Now Back to the Copyright Question and How Oracle Fragments Java
Authored by: darlmclied on Thursday, May 24 2012 @ 10:27 AM EDT
Just read this: FUD filled article on zdnet.com

Author claims to have been in the courthouse, I suspect they were in a different trial.

[ Reply to This | # ]

It's interesting the way the claims are being moved around during this ca
Authored by: Anonymous on Thursday, May 24 2012 @ 11:16 AM EDT
It's an interesting strategy. Oracle have forced Google to
defend so far on the basis of "no it's not Java, it was
never intended to be compatible with Java", in order to now
try to get them in trouble for not producing a compatible
implementation

Both in terms of implying fragmentation, and denying fair
use for compatibility.

I wonder if this was actually a clever strategy. Still
hoping for a ruling that it's not copyrightable anyway, so
getting fair use on this might not be the best result
(though it would be good result for Google)

[ Reply to This | # ]

But does it run on Android? The new Paradigm.
Authored by: argee on Thursday, May 24 2012 @ 11:27 AM EDT
Clearly, if things go Google's way, the tables will
reverse. It will be the Java boys that will have to
conform their Java programs to run on Android, or
their products will start to lose functionality and
marketability.

Far do the mighty fall.


---
--
argee

[ Reply to This | # ]

JSE programs can run on Android
Authored by: Anonymous on Thursday, May 24 2012 @ 11:55 AM EDT
Android consists of two main components:
  1. Linux Core
  2. Android Runtime
    1. Anrdoid apps are hosted applications (like J2EE apps but not exactly) and the developer does not directly code a main method (Is there a implied call to main by the Android runtime when a process is started?).

      At the Linux level the dalvikvm command is equivalent to the java command from the JRE. It is possible to run dalvik bytecode programs with a main method from the linux command line. See here:

      Da lvik VM Invocation

      It is possible for Google, OEM's, Carriers, and programmers with rooted devices to run any JSE program with main and using the 37 API's that has been converted to Dalvik bytecode on an Android device.

      [ Reply to This | # ]

I would love to see Google give an alternate way to write apps for Android..
Authored by: Anonymous on Thursday, May 24 2012 @ 12:13 PM EDT
I pushed off learning Java for so long.. and the only thing that actually made
me try was Android. This trial has made me question that decision. I know
Google has a C API for Android, but my understanding was that it is more for low
level libraries that need lots of control. Is it possible to write a full app
in C? Or possible to write in something other than Java without using a cross
compiler that spits out Java or Java bytecode?

[ Reply to This | # ]

What is meant by "compatible"?
Authored by: Anonymous on Thursday, May 24 2012 @ 12:50 PM EDT
All valid Java byte-code can be directly translated to a valid Android
byte-code. Therefore the two systems are compatible.

All this talk about not having implemented the complete API or differences in
the main() method are irrelevant.

[ Reply to This | # ]

Oracle wants to kill compatibility?
Authored by: Anonymous on Thursday, May 24 2012 @ 12:53 PM EDT
This case seems more about winning an argument than considering what they really
want or need from the outcome. If Oracle were to prevail in all of its
arguments, it would likely mean a migration away from Java. Sure, there'll be
some holdouts for legacy reasons, but any new development work would first have
to reconsider whether Java would be a good choice. Perhaps I am missing
something, but I don't know of too many languages with this type of problem.

[ Reply to This | # ]

serialization, deserialization and JSON
Authored by: IMANAL_TOO on Thursday, May 24 2012 @ 01:49 PM EDT
From microsoft.com/en- us/library/system.web.script.serial ization.javascriptseriali zer.aspx:
"Provides serialization and deserialization functionality for AJAX-enabled applications."
What are AJAX-enabled applications in this context? Do they have any bearing to what is fragmentation and what is not? Especially since Turing-complete languages probably can be translated on-the-fly with some speed penalty:
JSON (JavaScript Object Notation) is a lightweight data- interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

JSON is built on two structures:

- A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
- An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangeable with programming languages also be based on these structures.
To me it seems any language difference is not so relevant, if they are Turing-complete. But, here I'm in deep water, deeper than usual... :|


---
______
IMANAL


.

[ Reply to This | # ]

New signature for "Winter"
Authored by: Anonymous on Thursday, May 24 2012 @ 02:25 PM EDT
Always liked Winter's signature: "Some say the sun rises in the east, some
say it rises in the west; the truth lies probably somewhere in between."

I propose a new one: "Some say software is mathematics, some say it isn't;
the truth lies probably somewhere in between."

[ Reply to This | # ]

Interoperability Upstream vs Downstream dependencies
Authored by: Anonymous on Thursday, May 24 2012 @ 03:54 PM EDT
The JSE libraries use many techniques to get services from the host platform when running a JVM.

One technique is known as bridging. The JSE does not implement a feature itself but acquires the feature from the host platform.

Classes in java.awt.* depend on the underlying windowing system of the host platform. In particular, java.awt.Component is a bridge to an actual drawable surface from the host windowing system. Also in java.awt, button, checkbox, choice and all other classes descendent from Component are bridged to native window components, they are not implemented in Java - they are implemented in Windows, or Linux, or whatever.

Java adapts to the host platform it can not dictate to the host platform. Image Oracle / Sun telling Microsoft how they must implement the API for the Windows platform.

Android linux does not include a native windowing system (i.e) one that runs purely as a native process. This is a host operating feature system-level decision and does not need to consider the needs of the Java API.

Since java.awt depend on bridging to a native windowing system and android linux does not include a native windowing system there is no need to implement java.awt. Also it makes no sense to implement any packages that depend on java.awt: these include java.swing, java.applet and easily argued java.print.

Many Operating Systems can run without a WindowManager (a GUI) including all variations of UNIX (Solaris, AIX, ...), Linux, and Windows Server. Many datacenter servers running java programs do so without running a WindowManager and no java programs depending on awt, swing, applet or print will run on them.

Are all of the Fortune 100 companies in violation of their java licenses because they run servers without WindowsManagers and therefore can not run any of the GUI based demos described in Oracle brief, however, HelloWorld should run.

Some other bridges in the JSE (remember, where Java defines the interface and somebody else puts in the effort of actually building the code that works) include: JDBC (java.sql), Java Sound (java.sound.*), XML parsers, JNDI (javax.naming.*), Cryptography (java.crypto.*).

Is there any original SSO in any of these bridging interfaces, since many were designed to do exactly what Oracle is claiming that google is trying to do: Get to market by leveraging someone else's work!!

[ Reply to This | # ]

Oracle spouting more nonsense
Authored by: Anonymous on Thursday, May 24 2012 @ 04:30 PM EDT
In particular, under the Court’s construction, a reference could be symbolic as to some data and numeric as to other data. Indeed, so long as the reference is symbolic as to some data, then it “identifies data by a name other than the numeric memory location of the data” and the reference is a symbolic reference, regardless of whether it identifies other data by location.
References point to ONE thing. _ONE_ You can't put two different values in the same location in memory! It's either the numeric memory location of the data or it is not. Oracle is asking for jury instructions saying that up is down.

[ Reply to This | # ]

Oracle v. Google - Now Back to the Copyright Question and How Oracle Fragments Java
Authored by: Anonymous on Thursday, May 24 2012 @ 08:19 PM EDT
If you follow Oracle demonstration, JME is not compatible with JSE: There are API in JME which are not in JSE and not all the JSE API are in JME.

However see what Sun has written (2006) in the official CDC doc: With respect to APIs in the java.* packages, it is a subset of the Java 2 Platform, Standard Edition (J2SE), version 1.4.2. Applications written to these APIs in Personal Profile 1.1.2 are therefore upward-compatible to J2SE 1.4.2..

[ Reply to This | # ]

Oracle vs Google : The score so far
Authored by: Anonymous on Thursday, May 24 2012 @ 10:31 PM EDT
The dust hasn't settled yet, but when it does we will have a scenario something
like this.

Oracle has lost:
- several patents revoked by USPTO
- a lot of money on lawyers
- credibility and goodwill with many Java developers
Oracle has gained:
- ?
Google has lost:
- a lot of money on lawyers
- pocket change for infringing 9 lines of RangeCheck code
Google has gained:
- confidence that Android can be defended when necessary

And the winner is - the lawyers. Almost all the money that will change hands
will go to them.

[ Reply to This | # ]

  • MAD - Authored by: celtic_hackr on Thursday, May 24 2012 @ 11:53 PM EDT
    • not MAD - Authored by: Anonymous on Friday, May 25 2012 @ 04:58 AM EDT
      • not MAD - Authored by: Wol on Friday, May 25 2012 @ 09:59 AM EDT
        • not MAD - Authored by: Anonymous on Friday, May 25 2012 @ 09:52 PM EDT
    • Oracle tried for MAD.... - Authored by: Anonymous on Friday, May 25 2012 @ 06:11 PM EDT
How patents (don't) work
Authored by: cricketjeff on Friday, May 25 2012 @ 06:36 AM EDT
A very clever man invents the toggle wibbler, it is a device that society has
been crying out for, toggles can now be wibbled at a rate of 60 toggles a minute
rather than 60 minutes per toggle. He gets a patent and grants licences.

Another man sees the toggle wibbler and sees that by ungroobing the flange
werter toggles can be wibbled at a rate of 120 a minute, he gets a patent and
grants licences.

A third man sees the improved toggle wibbler and sees that a left handed bonk
knocker could get production up to 150 toggles a minute, he gets his patent and
grants licences, thus far all is working as it should but now a large toggle
wibbling company starts to feel concerned, people are making money from wibbling
and it isn't them so they pay an engineer to come up with their own machine. The
design cannot use the original patented technology so it is slow and
inefficient, it can only manage 30 toggles a minute, the bosses speak to a
clever lawyer who says
Rather than a toggle wibbler why do you not create a tiggle wobbler, this will
not be covered by the patent, further we can patent it ourselves and since we
are rich we can go to court and force all toggle wibbling companies to pay a
licence fee to us.
"But there is no such thing as tiggle wobbling""
"There will be after I write the patent"
"aren't patents supposed to reveal useful inventions to the world at
large?"
"Not the way I write them"
So now tiggle wobbling has been patented
Another large toggle wibbling concern is, well, concerned. They speak to their
engineers saying we need defensive patents, the engineers invent, lawyer weave
spells and taggle waggling, teggle wuggling and tyggle wyggling are patented,
but the patent office spots a pattern and they have to modify the final patent
to say "on Tuesdays"

Eventually a toggle wiggler is bought by a litigious lunatic who goes to court
and ...

---
There is nothing in life that doesn't look better after a good cup of tea.

[ Reply to This | # ]

The Copyright Question is moot...
Authored by: Anonymous on Friday, May 25 2012 @ 07:40 AM EDT
The Judge will follow the European Court's lead and decide that API's are not
copyrightable. He is NOT going to put US copyright law at odds with European
copyright law...

[ Reply to This | # ]

Oracle Java Programs run cross-platform on Andoid, RIM and Windows
Authored by: Anonymous on Friday, May 25 2012 @ 08:01 AM EDT
Oracle SQLite Mobile Client runs cross platform on:
  • Android 1.5 (based on Android/Harmony)
  • RIM 5.0 (based on JME)
  • Win32 (JRE 5.0)
  • Windows Mobile 2003 (using IBMJ9 or CtErne JDK 4.1)
  • Windows Mobile 5 (using IBMJ9 or CtErne JDK 4.1)
  • Windows Mobile 6 (using IBMJ9 or CtErne JDK 4.1)

The user guide is here: Oracle SQLite Mobile Client Guide

How large is the common java library shared by the different versions.

How does Android fragment Java again?

[ Reply to This | # ]

Fragmentation is a meaningless PR facde
Authored by: Anonymous on Friday, May 25 2012 @ 08:43 AM EDT
Anytime Oracle want they can implement J2(?)E on android, there is nothing
stopping them and then Java WORA will also include android.


Nothing Android has done in anyway affects the current java
environment/ecosystem for programmers.

If Oracle did port J2?E to Android, Java programmers would be happy, Android
programmers would also carry on just like they are, though I do wonder just how
much interest was generated in using Android NDK.

An API is a concept, an SSO of a concept is a just a bigger more complicated
concept, but a concept nonetheless.

Concept: A general idea derived or inferred from specific instances or
occurrences. The Spec, The Source, The Library, The Application are each
specific instances and are protected as such.

The concept is not protected. The Jury instructions were specific, concepts are
not covered.

It really shouldn't be that hard for Judge Alsup to have come to that
conclusion.

Software patents exist because the languages of technology and law are
incompatible and lawyers are able to twist the meaning to suit themselves. What
is needed is some plain speaking on the language and terms.

Start with concepts.

[ 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 )