I am a technology evangelist, an investor, a commentator and a business adviser. I am the director of Diversity Limited, a business that is a vehicle for my work in investment, advice and consultancy. Diversity has holdings in manufacturing, property and technology companies and undertakes advisory work. For my complete disclosure statement, click here. I have a background across various industries, owning businesses in the manufacturing, property and technology sectors and make my day to day living consulting to technology vendors and customers. I cover the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. My areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

The Patentability Of APIs - In One Move The US Judiciary Harms Innovation

Last week a US federal appeals court ruled that GoogleGoogle must pay OracleOracle for its use of the Java API in Android. Beyond the specifics of the case, the ruling sets something of a precedent that means software companies can copyright their APIs. In doing so, it creates major consequences for both innovation and the efficient interoperability between software.

While Oracle’s rationale for the case was articulated as being an intent to avoid fragmentation of Java, by copyrighting APIs as a class, there is likely to be an unintended consequence in terms of a proliferation of convoluted APIs as developers try and limit the extent of their legal exposure – it’s an example of work creation for no reason other than risk mitigation.

It’s also risky in that it means vendors can use APIs as a way to avoid competition, one can only imagine the number of trivial combinations that will become locked up within broader API design – APIs will become more complex, integration will become more time consuming, and innovators will have to focus on the legal aspects to the detriment of their products. How far do developers need to code away from a particular API to ensure that they won’t be deemed to be infringing on copyright?

The decision raises, once again, the tragedy of the API commons, a topic I wrote about last year. As I said at the time:

Unlike the original Tragedy of the Commons, where self interest depletes a common resource, the API Tragedy of the Commons is a situation where the amazing proliferation of APIs has caused issues around both copyright and the duplication of effort and resource. The former was highlighted in the Oracle vs Googledispute, which, at its heart, looked at the copyright-ability of an API. In terms of the latter, huge amounts of code is written, rewritten and duplicated as people create similar APIs in different setting. Specifically the main issues in this area are that:

Many APIs provide similar or related functionality but use slightly different Interface patterns, conventions in data models, or otherwise differ in ways often not important for delivery of the API’s functionality. This requires fresh code implementations for each and every new API by consumers

Reuse of existing API Interface specifications and data models is often a legal grey area since there is no clear means for organizations to signal that such specifications are copyright free and available for reuse

For APIs which may be re-used, there are rarely uniform service descriptions in machine readable formats available

It also strongly vindicates the viewpoint of a number of individuals and companies that attempted to set up a framework whereby APIs could be wrapped within a Creative Commons license to be reusable. The “API Commons” creates a movement where Creative Commons licenses are used so that anybody who wishes to, can declare their API specs to be both copyright free and reusable by anyone else. In plain English, the objective of the program is to “Provide a simple and transparent mechanism for the copyright free sharing and collaborative design of API specifications, interfaces and data models”. Obviously in one fell swoop this solves the issues around API copyright and duplication, if people take up the proposal it would lead to a huge reduction in code that needs to be written – as the total number of APIs that exists increases, these benefits multiply rapidly.

In a detailed post looking at the ramifications of the decision, 3Scale, one of the vendors behind the API Commons, pointed out why this decision is even worse than the patentability of APIs:

On the surface, the problem is similar to the one that occurs in software patents – trivial methods may get patented and these mean everybody from this point on needs to find ugly workarounds for obvious functions.

However with API Interfaces and copyright the problem is strikingly worse – because this is copyright law and not patent law. This means:

There is no requirement to register a design for copyright

There is no cost or effort required

There is no independent authority to judge what meets a certain bar by means of standard process

There is no notion of what is “obvious”

All of this is particularly interesting moving into the week of the OpenStack summit. OpenStack us, after all, an open source initiative that relies on broad adoption of a standard API. Ever since the inception of OpenStack many commentators have called on the initiative to adopt what is the de facto industry standard, Amazon Web Services’ (AWS) APIs. That’s a move that has long been opposed by many in the community. Interestingly the third party cloud vendor Eucalyptus has adopted the AWS API, but it has done so via an AWS license, given the Oracle/Google decision, it is interesting to ponder what the situation would have been for OpenStack if it had decided to follow the advice and use the AWS API – some might say their decision to remain stubborn and go it alone was a prescient one.

There’s is still water to pass under the bridge with regards this particular decision – but as an indication into the thinking of the courts, it is indeed a worrying precedent.

Post Your Comment

Post Your Reply

Forbes writers have the ability to call out member comments they find particularly interesting. Called-out comments are highlighted across the Forbes network. You'll be notified if your comment is called out.