Should APIs be free from copyright?

In November, the Electronic Frontier Foundation (EFF) filed a brief with the Supreme Court asking the justices to reverse a decision involving Google and Oracle that, if it stands, would have profound consequences for software development and technology innovation.

Here’s why: In 2005, Google acquired Android Inc. to get a foothold in mobile devices. Google believed the best way to lure developers to Android was to leverage Java, the most popular programming language in the world.

So Google tried to set up a partnership with Sun Microsystems Inc., the steward of Java at the time. But they could not come to agreement because Sun was opposed to Google’s vision of Java code that didn’t “run anywhere,” as Sun’s cross-platform pledge promises.

Instead, Google appropriated a portion of the original Java API specification – actually 37 packages or groupings of related functionality – for Android. Google also added many more of its own packages and built a new JVM (Java Virtual Machine) implementation specific to mobile devices called Dalvik (which has since evolved to Android Runtime) for all the packages.

The goal was to ease the learning curve for existing Java developers by providing them with familiar APIs supplemented with Android-specific APIs. Altogether the packages represent the building blocks for Android applications.

A lot has happened since then. Oracle bought Sun, and Android became a force in the mobile development landscape. In 2010, Oracle sued Google for infringing on its patent and copyright claims on the Java language. Oracle’s case had several dimensions, but on the key one of APIs, the district court ruled in 2012 that the 37 Oracle-defined API packages Google uses in Android, along with the structure, sequence and organization (SSO) of their implementation, are not subject to copyright.

Oracle appealed. Then the Federal Circuit Court of Appeals reversed the district court’s decision. Though acknowledging Google did not copy the implementation of the 37 packages, the court accepted Oracle’s argument that copying the APIs verbatim meant Google could not help but “paraphrase” the SSO of Oracle’s code using its own algorithms.

Though the SSO paradigm has its critics in legal and technology circles, the Circuit Court afforded Oracle SSO copyright protection. Therefore, Google infringed Oracle’s copyright, the courts decided.

This brings us to the amicus brief filed by the EFF in November, which counts among its signatories five Turing Award winners, four National Medal of Technology winners and designers of technologies like C++, IBM S/360, Java, JavaScript, Python, TCP/IP, and Unix. The Supreme Court’s response will have profound consequences going forward.

Consequences

The signatories are absolutely right to assert that APIs must be free from copyright to promote competition and innovation. No API designer can possibly know all the ways someone might want to use it. To erect barriers to creativity is to stifle producers and confuse consumers.

For example, you are probably familiar with this interface: 

A long time ago, someone was clever enough to devise an intuitive interface for devices like 8-track players where simple geometric shapes became synonymous with well-defined functions such as pause, play and record.

That icon designer never foresaw the ubiquity among different implementations of that interface, with analogous functions on devices ranging from cassette players to YouTube to Blu-ray to iTunes.

If the interface weren’t freely available, producers would have to devise new ways to express the same functionality – stifling competition as they fight for mindshare over interfaces.

Meanwhile, consumers would suffer from lack of competition and would likely be confused by the myriad interfaces available. It is also absurd to suggest that the mere use of these established symbols dictates that the implementations among the disparate devices have the same SSO.

To return to programming, consider the situation of an experienced Java developer, who is aware that Java has a class called String with a method called length. He or she can use the functionality to evaluate the validity of a password in a web application built with Spring MVC or Play Framework.

But the ubiquity of the Java APIs allows much more than that. The same developer can use this functionality to build a text analytic with Hadoop. He or she can also use this functionality to evaluate the validity of a password in an Android application without caring that the underlying implementation differs from Oracle’s or OpenJDK’s. In fact the single developer can build three completely different applications.

This case will probably not have a huge impact in the short term. Android developers will not have to learn an original Google language like Dart or new ways to find the length of a string.

But who knows what could happen down the road? Besides, the principle transcends Java and Android as copyrightable APIs would stifle innovation, reduce the availability of developers across disciplines and confuse everyone unnecessarily.

Let’s see if the Supreme Court does the right thing.