Blog

- May 17, 2014

After the shock wave following the recent legal decision at Federal level on the Java copyright case between Oracle and Google, I decided to read the 69 pages of the court decision and extract the most interesting quotes, from a Java technologist point of view.

 

US Court - Oracle vs Google

Quote 1 – Scope

This copyright dispute involves 37 packages of computer source code. The parties have often referred to these groups of computer programs, individually or collectively, as “application programming interfaces,” or API packages, but it is their content, not their name, that matters.”

Quote 2 – On patents

The jury found no patent infringement, and the patent claims are not at issue in this appeal.

Quote 3 – Java definition

The Java platform includes the “Java development kit (JDK), javac compiler, tools and utilities, runtime programs, class libraries (API packages), and the Java virtual machine.

Quote 4 – API analogy with a books library

The parties have not disputed the district court’s analogy: Oracle’s collection of API packages is like a library, each package is like a bookshelf in the library, each class is like a book on the shelf, and each method is like a how-to chapter in a book.

Quote 5 – Core Java packages

The district court found, and Oracle concedes to some extent, that three of those packages—java.lang, java.io, and java.util—were “core” packages, meaning that programmers using the Java language had to use them “in order to make any worthwhile use of the language.”

Quote 6 – Two types of source code

Every package consists of two types of source code— what the parties call (1) declaring code; and (2) implementing code. Declaring code is the expression that identifies the prewritten function and is sometimes referred to as the “declaration” or “header.” As the district court explained, the “main point is that this header line of code introduces the method body and specifies very precisely the inputs, name and other functionality.”

Quote 7 – Android history with Java

Google acquired Android, Inc. in 2005 as part of a plan to develop a smartphone platform. Later that same year, Google and Sun began discussing the possibility of Google “taking a license to use and to adapt the entire Java platform for mobile devices.” Copyrightability Decision, 872 F. Supp. 2d at 978. They also discussed a “possible co-development partnership deal with Sun under which Java technology would become an open-source part of the Android platform, adapted for mobile devices.” Id. The parties negotiated for months but were unable to reach an agreement. The point of contention between the parties was Google’s refusal to make the implementation of its programs compatible with the Java virtual machine or interoperable with other Java programs. Because Sun/Oracle found that position to be anathema to the “write once, run anywhere” philosophy, it did not grant Google a license to use the Java API packages.

When the parties’ negotiations reached an impasse, Google decided to use the Java programming language to design its own virtual machine—the Dalvik virtual machine (“Dalvik VM”)—and “to write its own implementations for the functions in the Java API that were key to mobile devices.” Id. Google developed the Android platform, which grew to include 168 API packages—37 of which correspond to the Java API packages at issue in this appeal.

Quote 8 – SSO and the 37 Java packages at issue

With respect to the 37 packages at issue, “Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java.” Id. To achieve this result, Google copied the declaring source code from the 37 Java API packages verbatim, inserting that code into parts of its Android software. In doing so, Google copied the elaborately organized taxonomy of all the names of methods, classes, interfaces, and packages— the “overall system of organized names—covering 37 packages, with over six hundred classes, with over six thousand methods.” Copyrightability Decision, 872 F. Supp. 2d at 999. The parties and district court referred to this taxonomy of expressions as the “structure, sequence, and organization” or “SSO” of the 37 packages. It is undisputed, however, that Google wrote its own implementing code, except with respect to: (1) the rangeCheck function, which consisted of nine lines of code; and (2) eight decompiled security files.

Quote 9 – Android incompatibility with Java

Although Android uses the Java programming language, it is undisputed that Android is not generally Java compatible. As Oracle explains, “Google ultimately designed Android to be incompatible with the Java platform, so that apps written for one will not work on the other.”

Quote 10 – Java interoperability and command structure

According to Google, however, the district court correctly determined that: (1) there was only one way to write the Java method declarations and remain “interoperable” with Java; and (2) the organization and structure of the 37 Java API packages is a “command structure” excluded from copyright protection under Section 102(b). Google also argues that, if we reverse the district court’s copyrightability determination, we should direct the district court to retry its fair use defense.

Quote 11 – Decision on copyrightability

The court also erred by importing fair use principles, including interoperability concerns, into its copyrightability analysis. For the reasons that follow, we conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages are entitled to copyright protection.

Quote 12 – Java API design was a creative process

The testimony at trial revealed that designing the Java API packages was a creative process and that the Sun/Oracle developers had a vast range of options for the structure and organization. In its copyrightability decision, the district court specifically found that the API packages are both creative and original, and Google concedes on appeal that the originality requirements are met.

Quote 13 – Is an API just an idea and the implementation its expression?

In its analysis, the court identified the method declaration as the idea and found that the implementation is the expression. Id. (“The method specification is the idea. The method implementation is the expression. No one may monopolize the idea.”) (emphases in original). The court explained that, under the rules of Java, a programmer must use the identical “declaration or method header lines” to “declare a method specifying the same functionality.”

Quote 14 – Two years to write the core Java packages

it took years to write some of the Java packages and that Sun/Oracle developers had to “wrestle with what functions to include in the package, which to put in other packages, and which to omit entirely”).

Quote 15 – Interoperability doesn’t relate to copyrightability, but to fair user

Oracle also argues that the district court erred in invoking interoperability in its copyrightability analysis. Specifically, Oracle argues that Google’s interoperability arguments are only relevant, if at all, to fair use—not to the question of whether the API packages are copyrightable. We agree.

Quote 16 – Java interoperability was not the real aim of Google with Android

Google maintains on appeal that its use of the “Java class and method names and declarations was ‘the only and essential means’ of achieving a degree of interoperability with existing programs written in the [Java language].” Appellee Br. 49. Indeed, given the record evidence that Google designed Android so that it would not be compatible with the Java platform, or the JVM specifically, we find Google’s interoperability argument confusing. While Google repeatedly cites to the district court’s finding that Google had to copy the packages so that an app written in Java could run on Android, it cites to no evidence in the record that any such app exists and points to no Java apps that either pre-dated or post-dated Android that could run on the Android platform.

Quote 17 – Google wanted to capitalize on trained Java developers

The compatibility Google sought to foster was not with Oracle’s Java platform or with the JVM central to that platform. Instead, Google wanted to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue. The district court agreed, finding that, as to the 37 Java API packages, “Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java.”

Quote 18 – Irrelevant argument of Java as an industry standard

Google was free to develop its own API packages and to “lobby” programmers to adopt them. Instead, it chose to copy Oracle’s declaring code and the SSO to capitalize on the preexisting community of programmers who were accustomed to using the Java API packages. That desire has nothing to do with copyrightability. For these reasons, we find that Google’s industry standard argument has no bearing on the copyrightability of Oracle’s work.

Quote 19 – Fair use  factors

“Section 107 requires a case-by-case determination whether a particular use is fair, and the statute notes four nonexclusive factors to be considered.” […] Those factors are: (1) “the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;” (2) “the nature of the copyrighted work;” (3) “the amount and substantiality of the portion used in relation to the copyrighted work as a whole;” and (4) “the effect of the use upon the potential market for or value of the copyrighted work.”

Quote 19 – Fair use defense from Google

Google contends, however, that, although it admittedly copied portions of the API packages and did so for what were purely commercial purposes, a reasonable juror still could find that: (1) Google’s use was transformative; (2) the Java API packages are entitled only to weak protection; (3) Google’s use was necessary to work within a language that had become an industry standard; and (4) the market impact on Oracle was not substantial.

Quote 20 – New trial on fair use question

On balance, we find that due respect for the limit of our appellate function requires that we remand the fair use question for a new trial. First, although it is undisputed that Google’s use of the API packages is commercial, the parties disagree on whether its use is “transformative.”

Quote 21 – Google transformative argument and Oracle’s defense

Google argues that it is, because it wrote its own implementing code, created its own virtual machine, and incorporated the packages into a smartphone platform. For its part, Oracle maintains that Google’s use is not transformative because: (1) “[t]he same code in Android . . . enables programmers to invoke the same pre-programmed functions in exactly the same way;” and (2) Google’s use of the declaring code and packages does not serve a different function from Java.

Quote 22 – Inability to decide on fair use

While Google overstates what activities can be deemed transformative under a correct application of the law, we cannot say that there are no material facts in dispute on the question of whether Google’s use is “transformative,” even under a correct reading of the law. As such, we are unable to resolve this issue on appeal.

Quote 23 – Importance of Java core packages for fair use retrial

We find this particularly true with respect to those core packages which it seems may be necessary for anyone to copy if they are to write programs in the Java language. And, it may be that others of the packages were similarly essential components of any Java language-based program. So far, that type of filtration analysis has not occurred.

Additional references