To reasonably knowledgeable observers, it was clear even before the Oracle v. Google trial started that this litigation is much more about copyright than patents. After the patent verdict was rendered on Wednesday, the fight over the most important decision to be made during this trial -- Judge Alsup's forthcoming ruling on the copyrightability of the 37 asserted Java APIs -- continued. On Wednesday and Thursday, Oracle and Google filed two documents each in response to Judge Alsup's questions (discussed here and here) and to each other's pleadings.
Judge Alsup's recent questions relate to Google's claim that two Ninth Circuit decisions, Sega v. Accolade and Sony v. Connectix, render all APIs non-copyrightable. Google simply conflates copyrightability and "fair use" as I explained in this recent post. But those are, and always will be, two separate steps (to be precise, "fair use" is part of the infringement analysis, which is a subsequent step to the copyrightability analysis, even though Judge Alsup made a case management decision to postpone the decision on what is still, logically, the first step).
Not only do the parties disagree on whether compatibility has a bearing on copyrightability (again, it does not) but on the meaning of the word "compatibility" and the related term "interoperability".
In its Wednesday brief, Oracle provided the court with an analysis of why programs written for Java don't run on Android, and vice versa, and said that "Google is a source of incompatibility, not interoperability". Apart from the fact that Java object code doesn't run on Android and uses a different entry point, differences in how Google implemented its classes affect even -- with one minor and only potential exception -- the demos and samples that come with JDK5:
"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 platform. These demos and samples are contained in the JDK5 archives found in the directory licenseebundles/jdk1.5.0 of [Trial Exhibit] 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. [...] 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. [...] 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. [...] 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. [...]
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."
So Android is 100% incompatible at the level of executable files, but still highly incompatible for complete programs since even small demo files apparently tend to use functionality that Google didn't implement, or implemented in incompatible ways.
Google, however, says:
"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."
Instead, Google describes as "the salient question for compatibility" whether "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". For Google, Oracle's compatibility requirement "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. [...] 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".
Google's implied definition focuses on learning curve questions (familiarity vs. having to learn a new thing) and on a "reuse" concept that is presumably very vague, especially in light of the tests Oracle made with those JDK5 sample programs.
Google talks about compatibility rather than interoperability, the term Judge Alsup used when he asked his questions. If properly used, those two terms are synonyms as far as computer software is concerned. But if someone wants to engage in heavy-duty twisting and turning, the term "compatibility" appears more useful for that purpose because it may appear more vague. Two persons or two cultures can be compatible, not interoperable. But again, the context here is clear, and two pieces of computer software that are compatible must be interoperable.
Google's broad and vague notion of "compatibility" is inconsistent with the definitions found in dictionaries, with the technical facts of the Sega and Sony cases it so much likes to cite, and notably with Google's own definition of compatibility in connection with Android. In a claim construction dispute, there would be no doubt that Google's proposed concept of compatibility can only be rejected because it doesn't have any remotely reasonable basis.
TheFreeDictionary provides the following definitions of the word "compatible" in connection with technology in general or computer software in particular:
American Heritage Dictionary: "Capable of orderly, efficient integration and operation with other elements in a system with no modification or conversion required"
Collins English Dictionary: "(Engineering / General Engineering) (of pieces of machinery, computer equipment, etc.) capable of being used together without special modification or adaptation a PC-compatible disc"
Both definitions stress that compatible software must run without modification, adaptation, conversion etc. -- but Oracle's analysis shows that even small sample programs don't run without (at least) this kind of effort.
In the Sega and Sony cases, video games ran on a platform without modifications needed. In Sega, the purpose was to develop games that ran on the Genesis platform. In Sony, the PlayStation platform was emulated in order to make existing games run. This was executable-level compatibility. No modification, adaptation, or conversion -- otherwise they would also have run into copyright issues with third-party games written for the PlayStation that they made run.
Google argues that Connectix only implemented "37 of the 242 functions implemented in the Sony BIOS", but that was all that Connectix needed do to make 100% of all games (at least all the ones it tested) run.
I recently took a firm position that Sony was about binary interfaces only. In their pleadings this week, Oracle and Google have quoted from Connectix's opening appellate brief (Google even attached the entire brief as an exhibit). There were actually two kinds of interfaces that Connectix analyzed. Most of the work related to emulation of the PlayStation hardware platform. That effort "dwarfed" in Connectix's words the effort to also emulate the BIOS (Basic Input/Output System). The BIOS-hardware interface was clearly binary. The interface between games and the BIOS was "disassembled" and somehow Connectix "deduced" the functionality of certain BIOS functions by looking at their names. Neither Oracle nor Google presented evidence for those names actually being used to make function calls. The fact that Connectix had to create a particular table of entry points for BIOS calls suggests that they were not since the order of those entry points for the functions wouldn't matter for calls that use names. At any rate, Oracle stresses that C interfaces are structurally much simpler than Java interfaces. Also, the district court's decision on the Sony case noted that "Sony BIOS consists of a combination of C source code and R3000 micro-processor assembly language".
What undermines the credibility of Google's proposed definition of "compatibility" more than anything else is Google's own position on compatibility in connection with Android. Here's a quote from the official Android Compatibility Definition:
"Provide a consistent application and hardware environment to application developers. Without a strong compatibility standard, devices can vary so greatly that developers must design different versions of their applications for different devices. The compatibility program provides a precise definition of what developers can expect from a compatible device in terms of APIs and capabilities. Developers can use this information to make good design decisions, and be confident that their apps will run well on any compatible device."
Android's concept of compatibility is less absolute than Java's. But the passage quoted above states the first goal of the Android compatibility program, and clearly says that there shouldn't be a need to "design different versions of [one's] applications for different devices". By almost every little JDK5 sample program would fail to run on Android even if some smaller modifications are made -- and there would be need for different versions.
I've said it before: "compatibility" (by whatever definition) belongs to the "fair use" analysis. In Oracle v. Google, a majority of the jury was apparently confused by the concept of "transformative use" (I criticized the judge's proposed instructions on this concept even before the jury deliberations began). Ultimately, the jury was hung because some of its more rational members, including its foreman, didn't agree with Google. "Fair use" will have to be decided again, and according to Sega, a case Google cites all the time, this could also be done by an appeals court as a matter of law after a trial court has established the relevant facts. If Judge Alsup rules in favor of copyrightability, Google will probably appeal, and then we will see whether a retrial on "fair use" will take place before or after an appellate decision. If Oracle appeals, it will presumably ask for a judgment as a matter of law on "fair use". So there are different scenarios in which we'll have to talk about Android/Java "compatibility" again. But for now, the key issue is copyrightability, and Sega and Sony aren't really helpful in that regard. Even if they were, they relate to real compatibility and interoperability, not to source code reuse or to what programmers are familiar with.
If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.
Share with other professionals via LinkedIn:
