Oracle v Google could drive a new era of open-source APIs

The question of whether APIs are copyrightable has a huge bearing on implementers and users of those APIs. Today, the US Court of Appeals for the Federal Circuit released its decision in the Oracle v Google case around (1) whether a set of 37 Java API packages were copyrightable and (2) whether Google infringed those copyrights in Android and its Dalvik VM. It said that APIs are definitely copyrightable, but it called for a new trial on whether Google’s actions qualified as fair use. Also on the bright side, copyright (unlike patent) isn’t solely owned by the Federal Circuit, so this isn’t a nationally binding decision. That allows for other circuit courts to disagree, leaving more room for a potential appeal to the Supreme Court.

One specific point the court made was (p. 39):

It is undisputed that—other than perhaps as to the three core packages—Google did not need to copy the structure, sequence, and organization of the Java API packages to write programs in the Java language.

And it elsewhere went on to discuss Google’s use of those APIs as clear techniques to subordinate developers familiar with them rather than something that was necessary to write Java.

But most importantly, the appeals court sent the question of whether Google’s actions constituted fair use (i.e., they infringed but it wasn’t enough to count) back to the lower court for a new trial. The court said (p. 61):

We find this [function and interoperability as part of a fair use defense] 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.

What are the implications?

APIs may be copyrightable as a consequence of this decision, but that leaves a lot of gray area in terms of how they can be used, while opening up a whole new arena of how their licensing affects API re-implementers as well as consumers.

Before you make any decisions based on this news and what you think it means to you, I’d advise asking a lawyer, because I’m not one. I will, however, run through a series of questions raised by this decision that need answers.

Sam Ramji also pointed to the EFF’s filing for this case as a useful summary of some of the impacts of copyrightable APIs in areas such as Unix, network protocols, and the cloud.

For API consumption

It’s less concerning for those who are only consuming an API, because in many cases these users are already subject to terms of service that may already satisfy the API provider’s desires. One implication of this ruling is that if APIs are copyrightable, however, then the license applying to the rest of the software also applies to the API as an integral component of the software.

Since I’m not a lawyer, I can’t speak specifically to any legal precedent for code that uses an API, as far as whether it’s considered a derivative work (subject to copyright) [LWN writeup], a transformational work (fair use exception to copyright), a separate work with no copyright relationship at all, etc. However, lawyers such as Larry Rosen seem to lean toward the idea that implementing programs against a library API is not creating a derivative work.

If all software using APIs were derivative work of the providers, it would create very interesting situations of asymmetric power for Microsoft Windows and other OS providers as well as for web APIs. The provider would be able to exert license control over every consumer of the API, and it could go so far as to individually curate (i.e., pick and choose) users of its APIs. This would dramatically shift the balance of power toward the API provider and away from individual developers, particularly in the non-web case because of the popularity of ToS, API keys, and additional restrictions in the latter.

For API compatibility

Even if the new trial holds up fair use as a defense, the biggest problem for the rest of us is that fair use applies on an individual level. In other words, every single time an API is copied, it’s sufficiently different from every other time that the owners of the original API could sue for infringement and you’d have to hire lawyers for a fair-use defense.

This judgment greatly changes the risk assessment for whether to support any given API. It may not end up going to trial, but even the legal effort and expense alone will create significant difficulty for many startups and open-source projects. This will have a serious chilling effect on the creation and growth of new implementations because of greatly increased switching costs for whatever API users are currently doing. Low barriers to entry may encourage more users to move through the funnel, but the flip side of the coin is that increased barriers to exit will similarly discourage developers and other customers who see it as a form of lock-in. People are much more willing to invest time and money when they perceive that their effort is portable than when it’s tied to a single proprietary platform.

This is going to create a lot of difficulty for everyone reimplementing S3 APIs, for example, such as OpenStack and others, with the exception of Eucalyptus because of its Amazon partnership.

A new opportunity to go beyond open APIs to open-source APIs

The “open API” movement has thus far been rather amorphous in terms of structure and definition. But generally, open APIs are perceived to use open protocols and formats including REST, JSON, and (less popular these days) XML. In other words, it’s open in terms of the standards used, and not necessarily open in terms of anyone’s ability to register for it.

This ruling creates an opportunity for API providers to put their APIs under open-source licenses, be it permissive or copyleft. This can apply, particularly with permissive licenses, even if the non-API components of the source code are proprietary. That would provide users with the comfort of knowing that they have the freedom to leave, which lowers resistance to initially commit to a technology, precisely because the API is open source and so it could be reimplemented elsewhere. Unfortunately, it also means that the idea of “open APIs” will become even cloudier because it add open source into an already confusing mixture of usage.

If nothing changes legally, we may end up with the equivalent of FRAND patent terms in copyright licenses as well, along with additional usage of standards bodies to support them. Unfortunately FRAND does not always mean open-source friendly, so we may see some of the same battles all over again with copyrights as we saw with patents.

Disclosures: I am not a lawyer. Google and Oracle are not clients, but Sun was. Microsoft and Eucalyptus have been clients. The OpenStack Foundation is not, but a variety of OpenStack vendors are.