The Supreme Court has ruled that Google’s use of Java APIs owned by Oracle is fair use. The lawsuit against Google, which began in August 2010, is now finally over. Since it’s been banging around for over a decade, we’ll recap the major developments:
In 2010, Oracle sued Google claiming that the latter had infringed on Oracle’s Java copyright by copying some 37 Java APIs (Application Programming Interfaces) totaling ~11,500 lines of code without permission. Previously, APIs had been thought to be exempt from copyright claims because they constituted functional elements of code rather than expressive statements. You can’t copyright a merely functional product or document. Copyright doesn’t protect lists and directories such as the phone book, for example. Oracle defeated Google on this point, and the new Supreme Court ruling declined to consider whether that holding was rightfully arrived at. SCOTUS, at this point, is assuming that APIs can be copyrighted, but Oracle still doesn’t win any monetary damages. Google’s actions are fair use, according to SCOTUS, for four reasons:
First, it finds Google’s copying of APIs to be instrumental in allowing programmers to call prewritten bits of code rather than directly modifying how the computer executes data:
As part of an interface, the copied lines are inherently bound together with uncopyrightable ideas (the overall organization of the API) and the creation of new creative expression (the code independently written by Google). Unlike many other computer programs, the value of the copied lines is in significant part derived from the investment of users (here computer programmers) who have learned the API’s system.
The justices recognize, in other words, that APIs serve a different functional purpose than other types of code, and that much of the value of the copied lines is derived from how so many programmers have learned them rather than in the inherently creative work by Oracle or Sun.
Second, Google’s work is transformative. SCOTUS holds that Google “copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language” and that it wished to create a new type of computing platform for a new type of hardware device (Android and smartphones, respectively).
Third, Google copied just 11,500 lines of code out of 2.86 million lines of code within the Java API. Those 11,500 lines of code constitute a tiny fraction of the larger whole and were not copied for any reason of beauty or creativity, but because they enabled other programmers to program for smartphones.
Fourth, Google’s copying of the affected lines of code did not allow Android to serve as a replacement for Java SE. The Supreme Court also held that the Java SE copyright holder (Oracle) “would benefit from the reimplementation of its interface into a different market.”
Finally, the Supreme Court notes that enforcing copyright as Oracle requests would risk “causing creativity-related harms to the public.” The prospect of strictly enforced copyright on APIs after decades of APIs being considered fair use is not a pleasant one. Not every company has Google’s pockets to fight a case like this for over a decade.
Image by Alexander Pohl/NurPhoto via Getty Images.
The Decision
The Court decided the case 6-2 in favor of Google, with the opinion written by Justice Breyer. Justice Barrett, who was confirmed to the court after it heard the case, did not take part in the decision. Justice Breyer walks through how Google’s copied API calls function within Android and gives a human-readable description of how various types of code interact within a single software environment. Breyer notes that Google’s implementing code, which defines how any given operation should be carried out, is entirely distinct from Oracle’s Java code.
Breyer’s evaluation of market effects depending on whether this case was decided for Oracle or Google is rather interesting. He notes that Sun had repeatedly failed to break into mobile and that Sun’s former CEO had testified that Sun’s failure had nothing to do with Android’s success and that Google’s work to bring Java to Android enabled fundamentally new and different devices than any that had run Sun’s Java SE.
Justice Breyer allows that enforcing copyright against Google would earn Oracle a great deal of money but questions “why and how Oracle might have become entitled to this money,” before holding that “We have no reason to believe that the Copyright Act seeks to protect third parties’ investment in [programmers] learning how to operate a created work,” meaning that Oracle doesn’t get to profit from owning Java simply because Java became popular. Finally, he notes that awarding Oracle the damages it wants in this case:
would make of the Sun Java API’s declaring code a lock limiting the future creativity of new programs. Oracle alone would hold the key. The result could well prove highly profitable to Oracle (or other firms holding a copyright in computer interfaces). But those profits could well flow from creative improvements, new applications, and new uses developed by users who have learned to work with that interface. To that extent, the lock would interfere with, not further, copyright’s basic creativity objectives.
Refusing to rule on the question of whether APIs should be copyrightable means there are still potential lawsuits on the issue waiting to be filed. Refusing to grant Oracle’s likely request for hundreds of millions to billions of dollars in licensing fees (Oracle has previously submitted reports claiming damages in excess of $9B) establishes that such arguments should be viewed with skepticism by the lower courts guided by this ruling in the future. Decisions must be made with an eye towards fostering creativity rather than stifling it and questions of fair use should be considered in this context.
I was surprised at how strong this opinion was and how well Justice Breyer understood the underlying issues. The decision explains meaningful differences in various types of programming code and describes which parts of code are more creative and which are not. It acknowledges that existing copyright law is difficult to cleanly map to programming code because it contains both creative and merely functional elements in the same piece of work. It discusses the historical purpose of copyright law and discusses how allowing a third party to control program development by weaponizing API copyrights could be detrimental to the long-term health of the software industry.
All too often, laws and rulings that impact technology are made by people with no understanding of how said technology works. This is a happy exception.
Now Read:
0 Commentaires