The Federal Circuit Blows It Again in Oracle v. Google

Today, the U.S. Court of Appeals for the Federal Circuit (“CAFC”) issued a decision reversing the jury’s fair use verdict in the long running copyright infringement litigation between Oracle and Google. The CAFC found that Google’s replication of elements of the Java Application Programming Interface (“API”) in the Android API was not a fair use, as a matter of law. (A timeline of this eight year litigation, and a summary of the complex facts,^[1] is available here.) This is CAFC’s second ruling in this case; in 2014, the same CAFC panel held that the Java declaring code copied by Google was protectable expression. Today’s decision is as flawed as the 2014 ruling.

This post will focus on the CAFC’s central substantive error: its holding that Google’s use was not transformative.^[2] The CAFC correctly observed that in examining the first fair use factor, the purpose and character of the use, it must consider whether the new work is transformative or simply supplants the original. Citing the Supreme Court’s decision in Campbell v. Acuff-Rose, the CAFC noted that a use is transformative if it “adds something new, with a further purpose or different character, altering the first with new expression, meaning, or message.” The Supreme Court added that the question is “whether the new work merely supersedes the objects of the original creation…or instead adds something new.”

The CAFC found that Google’s use was not transformative largely because “the purpose of the API packages in Android is the same as the purpose of the packages in the Java platform.” The CAFC added that Google did not alter “the expressive content or message of the original work.” In the view of the CAFC, “the fact that Google created exact copies of the declaring code and SSO [structure, sequence and organization] and used those copies for the same purpose as the original material seriously weakens the claimed fair use.”

The problem with this analysis is that it means that virtually no use of a functional work such as a computer program could ever be transformative. The copied elements invariably would perform the same function in the new work; these elements were designed to perform a specific function. The categorically non-transformative nature of the use of functional works, in turn, makes a fair use finding less likely for a functional work than for a fictional work, contrary to Supreme Court precedent. The only use of the API that the CAFC suggests would have been a fair use is “if it had copied the APIs for some other purpose—such as teaching how to design an API….”

Ninth Circuit fair use decisions involving computer programs—e.g., Sega v. Accolade and Sony v. Connectix—indicate that a far more nuanced transformative use analysis is required when dealing with functional works such as software. Otherwise, copyright could restrain legitimate competition. The CAFC, however, relied on cases involving news programs, biographies, street art, and comedy routines.

Additionally, the CAFC dismissed Google’s argument that its use of the Java declarations in Android was transformative because Android operated in a new context: smartphones. The CAFC noted that some smartphones used the Java API before Android entered the market. The court overlooked the evidence that Android, unlike Java, was designed to operate on smartphones, and its features were optimized to function in that confined environment. When dealing with functional works, a court should treat optimization to function in a different environment as a new context.

Google included Java declaring code in Android for the purpose of attracting Java programmers to its new platform. When the case was before the CAFC in 2014, the panel made it clear that it did not believe this was a legitimate objective, and this hostility colored its decision that the declaring code was protectable expression. This same hostility is manifest in its conclusion that Google’s use was non-transformative.

The panel also displays hostility to Google’s objective of making Android attractive to Java programmers in its discussion of the third fair use factor, the amount and substantiality of the portion used. The panel noted that “there is no inherent right to copy in order to capitalize on the popularity of the copyrighted work or to meet the expectations of intended customers. Taking those aspects of the copyrighted material that were familiar to software developers to create a similar work designed to be popular with those same developers is not fair use.” In support of this analysis, the CAFC cited a case involving the copying of elements of Dr. Seuss’s The Cat in the Hat. The CAFC’s use of the words “popular” and “popularity” completely misrepresents the extent of a programmer’s investment in developing expertise in a programming language like Java. Further, it minimizes the degree to which the shortage of skilled programmers acts as a barrier to entry in the software market. In order to participate in the software market, a new entrant must attract programmers from other firms. Attracting programmers is particularly challenging if the programmers must learn a completely new set of programming conventions to operate in the new entrant’s programming environment.

The CAFC appeared to recognize this when it referred to Google’s explanation to the jury of “the importance of the APIs to the developers it wished to attract.” It quoted Google’s expert testifying that “it was sound business practice for Google to leverage the existing community of developers, minimizing the amount of new material and maximizing existing knowledge.” “Maximizing existing knowledge” does not sound like “capitalizing on popularity.” To the contrary, it suggests that the elements Google used were not protectable expression to begin with.

The only positive aspect of the panel’s discussion of the third factor is its emphasis that the ruling did not reach interoperability. The CAFC reiterated its 2014 finding that Google did not seek to foster any inter-system consistency between its platform and Java. Indeed, the panel stated that “Google specifically designed Android to be incompatible with the Java platform and not allow for interoperability with Java programs.” The panel observed that Google did not rely on any interoperability arguments on appeal. Thus, the panel did not disturb its 2014 holding that the desire to achieve interoperability “may be relevant to a fair use analysis.”

Google probably will petition the Supreme Court to hear the case. The Supreme Court denied Google’s cert petition from the 2014 decision, but it may have relied on the Solicitor General’s advice not to hear the case before a decision on Google’s fair use defense. Now that the CAFC has ruled on fair use, the Supreme Court might agree to hear the case. It could consider the CAFC’s 2014 ruling that the declarations were protected expression, as well as today’s fair use ruling.

—

^[1] Believing that Java programmers would want a core set of functionalities in Android that would be callable by the same headers or declarations used in the Java API, Google replicated the declarations for 6000 subroutines contained in 37 of the Java “packages.” However, for each of these subroutines, Google wrote its own implementing code. Moreover, Google created the declarations and bodies for the tens of thousands of subroutines in the 131 other Android API packages. Ultimately, the Android API replicated only 0.4% of the Java API code.

^[2] The CAFC also erred by not according sufficient deference to the jury’s verdict.