Author:Menell, Peter S.
Position:Continuation of III. Copyright Protection for Computer Software 2.0: The Oracle Wave B. The Oracle v. Google Litigation 5. 2016 Fair Use Trial ii. Google's Case in Chief through V. Conclusion, with appendices and footnotes, p. 398-490 - Application program interface - Special Issue: Software Interface Copyright

Google called Joshua Bloch, the former Sun employee who became Google's "Java guru." Bloch played a significant role in developing Java APIs and authored EFFECTIVE JAVA, (493) a book about writing Java code. Bloch explained the goals of API design (to make them concise and difficult to misuse) and Sun's desire to make them widely available. He discussed differences in writing APIs for mobile, as opposed to desktop, environments. Drawing on Bloch's writings, Oracle focused its cross-examination on the creativity involved in designing APIs. He acknowledged that writing good APIs is difficult.

Google played video deposition excerpts of Donald Smith, a designated Oracle representative, (494) in which Smith stated the Java programming language and the Java APIs were defined together under the same specification and hence were inseparable. He further testified that there were more than ten million Java developers and Oracle's Java division was growing and profitable. In a later segment of the deposition, Smith walked back his earlier testimony that the Java language and APIs were inseparable.

Google next called Simon Phipps, who was previously Sun's Chief Open Source Officer and was also President of the Open Source Initiative until 2015. (495) Phipps testified that Sun had not taken actions to stop other projects that used Java APIs such as GNU Classpath and Apache Harmony.

Google then called Daniel Bornstein, a key member of the Android development team, to discuss APIs and the Android team's approach to using Java declarations and APIs. Bornstein considered Java declarations "A-OK to use." He explained that Google used a lot of open source software, including Apache Harmony "core libraries," to build Android. He noted that no other product offered the functionality, such as running multiple applications simultaneously on a smartphone, that Google sought to develop. On cross-examination, Hurst questioned Bornstein about Google's efforts to purge java-related terms from the Android code. Bornstein made light of the suggestion that this indicated that Sun owned the APIs. On re-direct, Bornstein explained that he was not a lawyer and had called for scrubbing the "J-word" (Java) from Android code to avoid trademark concerns. (496)

Google completed its direct fair use case with Professor Owen Astrachan, Professor of the Practice of Computer Science at Duke University. (497) Professor Astrachan provided clear and measured testimony about API design, the distinction between declaring and implementing code, and the importance of consistent functional labels in programming. (498) He explained that Android is not fully compatible with Java SE because the SE platform is designed for desktop or laptop computers whereas Android is designed for mobile devices. Google designed Android to make use of 37 well-known Java APIs. Since Java is the most widely used computer program in the world, "[d]evelopers would expect that if you're going to be using the Java programming language, you'd have access to a rich suite of APIs, to write whatever program you're going to write." Professor Astrachan illustrated that the Java API labels (declarations) are functional and descriptive--discussing java.net (network classes); java.io (input/out), java.sql (accessing and processing data stored in a data source, usually a relational database), java.security (classes and interfaces for the security framework), and java.util (various collections of functions, including date and time and internationalization). (499) He explained the GNU Classpath implementation of Java APIs and the clean room process. He further noted that Sun had reimplemented the Linux APIs in its Solaris platform.

On cross-examination, Hurst pressed Professor Astrachan on the creativity involved in designing APIs. While agreeing that designing a good API is difficult, Astrachan observed that the difficulty was "not exactly" the same as that encountered by painters or musicians. (500) He acknowledged that the Java language did not require the selection of the particular 37 Java APIs that Google incorporated in Android, but that it was necessary to meet developer expectations.

iii. Oracle's Case in Chief

By the time that Google completed its case, Oracle had used much of its allotted time cross-examining Google's witnesses. Oracle opened its case in chief with Oracle co-CEO, Safra Catz. (501) She explained that Oracle acquired Sun to ensure the stability and reliability of Java, on which many of Oracle's software products were built. She testified that "Java was the single most important asset Oracle ever acquired. " (502) She denied that Oracle sought to pursue a copyright infringement lawsuit against Google. Catz explained the importance of intellectual property protection to support Oracle's $5.5 billion annual investment in research and development. She discussed how Android's forking of Java code had undermined Oracle's licensing strategy. On cross-examination, Catz acknowledged that Sun had licensed "significant elements" of Java technology as open source, which could reduce the ability to appropriate revenue from users.

Oracle next called two other company executives. (503) Edward Screven, Oracle's chief corporate architect, reinforced Catz's testimony regarding Oracle's motivation for acquiring Sun. He also explained that the Apache Harmony license required that the Apache license meet the Java Technology Compatibility Kit ("TCK") test suite and hence was not equivalent to Android's use. (504) He testified that Android was the only unlicensed use of Apache Harmony.

Oracle next called Mark Reinhold, Oracle's chief architect for Java SE, in what may have been the most significant testimony in the case. Reinhold noted that the APIs for the Java ME (Micro Edition, for feature phones) contain the same structure, sequence, and organization as those of Java SE (for desktop computers). Drawing on Oracle's Federal Circuit strategy, Reinhold testified that "the Java API Package is like a book series" as the Harry Potter series flashed on the courtroom presentation screen. He developed the following syllogism:

Package = Book

Class = Chapter

Method = Paragraph

Reinhold explained that Google's copying of the Java API declaring code is:

[L]ike using the titles of the books, the headings of each chapter, and the title sentences of each paragraph as well as the connections between the characters. Three books later, there are all these deep connections. It's intensely creative. Like writing a book, you have to keep a lot of stuff in your head, and the end result is rich and complex. A lot of it is about figuring out what structures you want. (505) Reinhold dismissed Van Nest's analogy of Java APIs to labels on a filing cabinet as "laughably simplistic."

On cross-examination, Google pressed Reinhold on the incompatibility across Java various platforms, getting him to acknowledge that Java ME would not pass the Java SE compatibility test. Reinhold also acknowledged that Java SE did not scale down for smaller devices, implicitly acknowledging that Android provided an innovative new platform.

Oracle then called Douglas Schmidt, Professor of Computer Science at Vanderbilt University, as an expert witness. (506) Professor Schmidt presented a visual software map illustrating the interconnectedness of the APIs at issue. He testified that Google used the 37 Java APIs in the same way that Sun designed them for the Java platform. He corroborated Reinhold's testimony that the APIs at issue were "creative" and "substantial." He presented test results showing that Android failed if any of the Java APIs or the declaring code were removed. Schmidt put into context Google's claim that the Java declaratory code represented less than one-tenth of one percent of Android's fifteen million lines of code by illustrating that more than sixty percent of the Android code was copied from third-parties. Furthermore, of the twenty-three percent of the Android code that Google wrote, nine percent were blank or comment lines. On cross-examination, Professor Schmidt acknowledged that he was not familiar with the meaning of "free and open" source software when he began preparing his testimony.

Oracle completed its fair use case with testimony about the economic impacts of Android's release. (507) Neil Civjan, Sun's head of global sales, testified that there were 2.6 billion Java-enabled mobile phones at the peak (85% of the global marketplace). That number fell precipitously after the introduction of Android's phones and its freely licensed operating system. Civjan noted that Java licensees did not see why they should license the Java ME platform when they could get Android, which was essentially Java and Linux, for free. He characterized the effect on Sun's licensing business as "devastating."

Alan Brenner, Sun's Senior Vice President of client systems from 1997 until 2007, corroborated Civjan's testimony and testified that Sun had persuaded a Korean research institute to take a Java license rather than use the GNU Classpath project. Brenner rebutted Jonathan Schwartz's testimony that Sun accepted other implementations of the Java platform. On cross-examination, Brenner acknowledged that Java licensing revenue was in decline before Android launched.

Oracle called Stefano Mazzocchi, a Google engineer who was one of the original Apache Harmony developers, to rebut Google's argument that Sun acceded to others' use of the Java APIs. (508) Apache Harmony obtained a license, subject to restrictions, on its use of the Java platform. Following the announcement of Oracle's acquisition of Sun in 2009, Mazzocchi emailed members of the Apache listserv with his concerns about Java's future: "What is Oracle going to do about Android's ripping off some of (now) their IP and getting away with it?" (509) In an earlier Email, Mazzocchi expressed the view that copyright protected the Java APIs:

But what I was missing is the...

To continue reading