This Thursday, the U.S. Court of Appeals for the Federal Circuit (CAFC) will hold oral arguments in the fair use phase of the long running litigation between Oracle and Google concerning Google’s replication of some elements of the Java application programming interfaces (APIs) in the Android API. This post will review how we got to this point and anticipate some of the misleading arguments Oracle probably will make in its effort to overturn the jury’s fair use verdict.
2005—Google acquires Android and decides to use Sun Microsystem’s Java as the programming environment for Android. (Both parties agree that programming languages such as Java do not fall within the scope of copyright protection. The case concerns the protectability of certain program elements written in Java, discussed below.)
2007—Google begins distributing Android. The Android API replicates some of the headers in the Java API.
2010—In January, Oracle acquires the assets of Sun Microsystems, including the copyright in the Java API. In August, Oracle sues Google for infringing the copyright in the Java API.
2012—Judge Alsup (who is now presiding over the trade secret infringement litigation between Waymo and Uber) finds that the structure, sequence, and organization (SSO) of the headers in the Java API replicated by Google are not within the scope of copyright protection.
2015—The U.S. Supreme Court denies Google’s cert. petition. The case goes back to the district court.
2017—Oracle files its brief on appeal in March; Google responds in May. Amici file briefs in support of both parties (see DisCo discussion here and here). The oral argument before the CAFC is on Thursday.
Oracle’s Likely Misleading Arguments
The central issue on appeal is whether a reasonable jury could have concluded that Google’s use of the Java API headers was fair. (Section 107 of the Copyright Act provides that “the fair use of a copyrighted work…is not an infringement of copyright.”) Based on Oracle’s briefs, Oracle is likely to appeal more to emotion than to reason, and to mischaracterize the facts and their legal significance.
(1) “Google copied the most expressively valuable portions of the Java APIs to steal Oracle’s customers.”
The facts of the case are technically complicated. Oracle has used this to its advantage throughout the litigation to exaggerate the amount and the creativity of what Google copied. (The purpose and character of a use and the amount and substantiality of the portion used are among the factors courts consider when assessing fair use.)
An API is a set of pre-written subroutines for basic functions that a programmer can use to save time when writing new applications. APIs have been developed in many programming environments, including Java. The Java subroutines are called “methods.” Each method has a piece of code in a “header” that identifies the function and parameters of the method; and lines of code in a “body” that implements the function. The methods are organized in “classes” and the classes in turn are organized into “packages.” The Java API contained 166 packages comprising tens of thousands of methods.
Google realized that none of the available operating systems would function efficiently and effectively in the smartphone environment. (Apple certainly wasn’t going to license its iPhone operating system to Google.) Thus, it had to create a new operating system and a new set of APIs. At the same time, it wanted to make it easy for the worldwide community of Java programmers to write programs in this new environment. Google pursued a joint venture with Sun, but the companies could not reach an agreement. This forced Google to create its own API, with 168 packages. Believing that Java programmers would want a core set of functionalities in Android that would be callable by the same headers used in the Java API, Google replicated the headers (and their SSO) for the 6000 methods contained in 37 of the Java packages. However, for each of these methods, Google wrote its own body—its own implementing code. Moreover, Google created the headers and bodies for the tens of thousands of methods in the 131 other Android API packages. Ultimately, the Android API replicated only 0.4% of the Java API code. These headers comprise just 0.08% of the Android API code.
The jury could reasonably have concluded that Google only took a small portion—measured both quantitatively and qualitatively—of the Java API. It also reasonably concluded that the purpose of the use—facilitating the migration of Java programmers to Android—was legitimate.
(2) “Google acted in bad faith by copying material it knew was protected by copyright.”
Because fair use is an “equitable rule of reason,” courts look at whether the defendant acted in good faith. (The defendant’s good faith reflects on the purpose and character of the use.) Oracle likely will point to internal emails suggesting that Google employees believed that they needed a license to use the headers as evidence of bad faith. But it is up to lawyers, not engineers, to make legal judgments as to what program elements are protected by copyright. Sun executives certainly did not seem to regard Android negatively. The CEO applauded Android’s use of Java when it was launched. And based on the controlling case law in California when Google developed Android, it would have been perfectly reasonable for Google’s lawyers to conclude that copyright did not protect the Java headers’ SSO. Indeed, the district court itself initially concluded that copyright did not protect the Java headers’ SSO. If the district court found that Google’s activities did not infringe copyright, how could they have been in bad faith?
(3) “The Android API is not ‘transformative’ because it performs the same function as the Java API.”
In evaluating the purpose and character of the use, courts consider whether the use is transformative—whether it performs a different function from the original work. But courts also consider whether the use recontextualizes the work. The jury reasonably could have found that Android was transformative because 99.92% of the Android API was original and was optimized to operate in smartphones, unlike the Java API designed for desktops and servers.
(4) “The district court improperly excluded evidence concerning Google’s plans for using Android in laptops and desktops, not just in smartphones.”
Oracle was well aware that Google planned to release an Android emulator for laptops and desktops, and one of Oracle’s witnesses actually testified about it. Moreover, it was not legal error for the district court to decide that the trial should be confined to the fairness of Google’s use of the Java headers in the smartphone market. The district court made clear that Oracle was free to bring a separate lawsuit concerning the use of the headers in other devices. The district court believed that the case was complicated enough as it was, and did not want to overwhelm the jury.
(5) “It is unfair for a wealthy corporation like Google to profit from copying the Java API headers without compensating Oracle.”
In evaluating this overarching unfairness point, the jury could reasonably have been persuaded by the fact that Oracle did not create the Java API; that the actual creator of the Java API—Sun Microsystems—did not object to the use of the Java API headers in Android; and that Android is a highly original platform that serves a completely different market from the one served by the Java API. Moreover, in that new market–the smartphone market–Android offered a counterweight to what was then the market leader: Apple. The fierce competition between Android and the iPhone has served the ultimate goal of copyright, which the Supreme Court has described as “enriching the general public through access to creative works.”
In sum, there was ample evidence supporting the jury’s fair use finding and the CAFC should not overturn it.