Oracle v. Google and the Dangerous Implications of Treating APIs as Copyrightable

There has been no lack of ink spilled on the legal battle between Oracle and Google surrounding Google’s use of Java APIs in its Android OS. And no wonder, what with testimony by both Larrys (Page and Ellison), claims of damages up to $1 billion, and rampant speculation that a ruling in Oracle’s favor could change the way we all use the Internet. Today, we got our first taste of where this all might be heading: the jury came back with a finding that, assuming APIs are subject to copyright, Google has infringed at least some of Oracle’s. But significant outstanding questions remain, including whether copyright can in fact apply (the judge alone will decide this) and whether Google made a legal fair use of those APIs (we believe it did).

What’s really at stake here? This first stage of the trial concerns whether Oracle can claim a copyright on Java’s APIs and, if so, whether Google infringes those copyrights. (In 2010, Oracle bought Sun Microsystems, which developed Java.) When it implemented the Android OS, Google wrote its own version of Java. But in order to allow developers to write their own programs for Android, Google relied on Java’s APIs. (For non-developers out there, APIs (Application Programming Interfaces) are specifications that allow programs to communicate with each other. So when you read an article online, and click on the icon to share that article via Twitter, for example, you are using a Twitter API that the site’s developer got directly from Twitter.)

Here’s the problem: Treating APIs as copyrightable would have a profound negative impact on interoperability, and, therefore, innovation. APIs are ubiquitous and fundamental to all kinds of program development. It is safe to say that all software developers use APIs to make their software work with other software. For example, the developers of an application like Firefox use APIs to make their application work with various OSes by asking the OS to do things like make network connections, open files, and display windows on the screen. Allowing a party to assert control over APIs means that a party can determine who can make compatible and interoperable software, an idea that is anathema to those who create the software we rely on everyday. Put clearly, the developer of a platform should not be able to control add-on software development for that platform.

Take, for example, a free and open source project like Samba, which runs the shared folders and network drives in millions of organizations. If Samba could be held to have infringed the Microsoft’s copyright in its SMB protocol and API, with which it inter-operates, it could find itself on the hook for astronomical damages or facing an injunction requiring that it stop providing its API and related services, leaving users to fend for themselves.

Another example is the AOL instant messaging program, which used a proprietary API. AOL tried to prevent people from making alternative IM programs that could speak to AOL’s users.  Despite that, others successfully built their own implementations of the API from the client’s side.  If copyright had given AOL a weapon to prevent interoperability by its competitors, the outcome for the public would have been unfortunate.

Setting aside the practical consequences, there’s a perfectly good legal reason not to treat APIs as copyrightable material: they are purely functional. The law is already clear that copyright cannot cover programming languages, which are merely mediums for creation (instead, copyright may potentially cover what one creatively writes in that language).  Indeed, the European Court of Justice came to just that conclusion last week. (Ironically enough, when Sun Microsystems was an independent company, one of its lawyers wrote amicus briefs arguing that interoperability concerns should limit copyright protection for computer programs.)

Improvidently granting copyright protection to functional APIs would allow companies to dangerously hold up important interoperability functionality that developers and users rely on everyday.  Let’s hope the judge agrees.