Copyright and APIs, Reflecting on Oracle vs Google

Yesterday’s Court Judgement in favor of Oracle in the Oracle v’s Google Java Lawsuit has caused a lot of debate online (CNET [Twice], FOOSPatents, Wired, Vox, GigaOm). Part of the coverage focused on the potential implications for Google. However, the deeper point is that there are collateral effects way beyond a single company.

The EFF has a brief published on why the negative effects of the ruling could be very serious.

It is always thought provoking watching debates unfold online, but a fair bit of the detail of the impact seem to have been lost – as has what should be done about it.

A Bad Decision But…

Given our involvement in APICommons and my (speaking in the first person) twitter feed it would be easy to conclude that we would be dead against Oracle’s winning in this ruling and declare them evil. However, the truth is more nuanced.

We’re generally against software patents at 3scale – they ultimately inhibit innovation and value creation. But given they and copyright law exist, it is understandable that someone who had put a very large amount of effort into something would seek and in some cases deserve reward. The API in question is the Java API which is one of the most detailed and complex APIs out there. Any reasonable engineer, architect or artist would want to be recognized and rewarded for this effort. While some will disagree with this, as such, we don’t see it as intrinsically wrong to either claim such a reward, nor for it to be granted.

However the problem is not the award in this case, it is the widespread uncertainty it creates on:

Exactly what is complex and elaborate enough to receive such protection?

In other words, it is unclear what the bar now is – how close does something have to be to infringe? How complex must the individual work be to warrant protection? What level of similarity constitutes infringement?

The clear and present danger is that even simple interface building blocks could be at risk of copyright claims. If this starts to arise, it may kill API innovation stone dead. In the vast majority of cases these claims would be completely false and unjustified – there are many common patterns which are used over and over again. New designs are often clear and obvious in their design. Worse, it does not require actual lawsuits, just the threat of or fear of lawsuits.

This is Way Worse than Software Patents

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 (all we have are the courts).

• There is no notion of what is “obvious”.

There is also little notion of what “is” copied. Taking the twitter API for example, which of the following would qualify as a copyright violation:

• Replacing the parameter names one for one?

• Reversing the order of presentation of the methods/resources?

• Adding a single different param to each call?

• Changing the path structure?

• What about all of the above?

In written prose, many of these things would easily render text unreadable or at least clearly different.

Not only is “different” less clear, more importantly, the notion of what is obvious is undefined, since it does not exist in copyright law. A tome large enough of obvious stuff is still subject to copyright – no matter that it might be completely useless. Given this, while we might accept something as complex and extensive as the Java API is worthy of protection, it becomes very hard to know where to draw the line.

Chilling Effect and Forced Divergence

Since it would be hard to determine what a violation would be and what is “obvious”, the danger is that due this one ruling, threats are generated to many small snippets or elements of API Design. Much like the web, API Design often relies on some common patterns being re-used.

In fact, it is very common advice to say “stick to convention”, “don’t be different for no reason” – this is because it helps App developers everywhere to use APIs in which they recognize common structures.

This best practice has always been self policing: there is tacit approval of some level of reuse of good ideas, but copying an entire API outright is frowned upon and called out.

While the Oracle/Google ruling is about a single large API in its entirety, it may well leave the door open for question marks about parts of APIs and APIs which are less extensive – what will the bar be?

In turn this results in uncertainty for API designers and perhaps even a tendency to artificially seek to differentiate designs:

This is extremely bad for API Providers and Developers alike

It is also nearly impossible to know if there are similar APIs out in the wild when designing a new one.

The overall result could be like copyrighting many short, popular, common phrases (in this case method signatures) in a language which leads to the ultimate destruction of our ability to express sensible interfaces. No right minded person would support this – it would be a true Tragedy of the Commons – destroying the language of the Web.

In a worst case scenario, API Design will require skilled copyright lawyers – a horrendous outcome for everybody (probably even the lawyers themselves).

Oracle v’s Google isn’t the Problem

Although this particular legal result brings the problem to the fore and we would be celebrating if the result had gone the other way (we hope it still does), in truth: It is likely that some particular complex or specific designs may end up being restricted, and likely even deserve to be so.

The problem is rather the lack of clarity of what happens to smaller, less complex API definitions and what falls under the notion of obvious.

In the realm of ordinary (and software) patents, the realm of the obvious is vast – it is hard to run into something which is protected (not as hard as it ought to be sometimes but sufficiently hard that you don’t need to worry overly in the day to day). However, in the world of copyright, this is not the case.

Part of the Solution – Explicit Declarations for Reuse

There is some way to run in the Oracle / Google case and it may ultimately be overturned (or at least permitted under fair use), but it is simply a fact that copyright matters will now be more important for APIs.

To help us, at least part of the solution is for people that do wish to share their API Designs to have the means to be more explicit about this. In other words, to declare that a particular design is available for re-use. Here is the presentation we gave with Kin Lane at Defrag in 2013:

The resulting APICommons project is online here. Over time the hope is that more and more interfaces would become sharable and part of common usage. This process helps both reduce overhead for API designers and fosters convergence of interfaces (better for App developers).

We’ve seen a number of APIs released in the Commons and there are more in the pipe, but it’s fair to say it’s early in the process.

As part of the twitter debate yesterday, Mike Amundsen asked if 3scale’s APIs were in the commons and they are (we’ve stated it in the past) – however we also have not done our homework and made the files / manifests properly available. This shows how, even with good intent taking a step like this can get lost. We’ll be rectifying this very shortly.

However, API Commons isn’t likely the solution for everyone and they only cover cases where people explicitly donate their interfaces for re-use. However, it or initiatives like it, are a start in the right direction for some cases.

API Royalty

An interesting question is what would make sense for those APIs that are clearly outstanding in design and themselves relatively complex, but perhaps not as complex as the Java API. To name out a few members of the API Royalty:

What happens, for example, in the next iteration of one of these APIs, when a company wishes to introduce a pattern which has already been used elsewhere? Gridlock.

We believe these companies succeed because of the powerful package of benefits they provide – service, support, data, the core of their infrastructures themselves. So while the API Design is certainly a differentiator, even if it were replicated, they would still win.

In certain cases, they may even be stronger if they donated they APIs to the API Commons (or some other similar means of declaring opened) – and hence spread good design as well as educate more developers on how to use their style of APIs. However this is understandably a tough decision to make.

Perhaps we should also find additional ways to reward those which create great API Design – API Design Awards – perhaps something to add to APIStrat.

Policing Ourselves

It is easy to pessimistic following yesterday’s news and the fact that copyright will now play a bigger role in API Design. Especially when it lacks effectively all the machinery that would be needed to make it actually work (e.g. a bar, a clear notion of obvious, a process for submitting to an authority).

However, it is a reality we will have to deal with to some extent. The best chance we have is to acknowledge the reality and consider what can be done at the community level – the API Community, even the Web as a whole. To a large extent it is in the control of individual companies and individual how to apply the findings of the news.

At the very least the following maxims should be things to consider living by. If these become widely adopted, we’d at least have a shot at preserving strong forward motion without the need for courts:

• Call out and Rebuff Outright Copying of APIs without permission: this is bad behavior nobody wants to see. Even without copyright law, nobody would wants to see lock, stock and barrel copying of APIs without permission. It is unethical and reflects extremely badly on those doing it. Call out the behavior, avoid using those APIs, as soon as alternatives are available – switch.

• Call out and Rebuff attacks based on trivial copyright claims: conversely, be equally vocal against companies or individuals that try to make trivial claims against others for parts of API Design which are obvious, simple and/or partial. This includes threatening behavior using copyright reasons, cease-and-desist letters, lawsuits etc. It is hard to know where the bar is between 1 & 2, but we believe “we know it when we see it” will serve the community well in most cases. Let us not reward copyright bullies. Call out the behavior, stop using those APIs where possible.

• Genuinely reward openness: where there is a choice of APIs, choose those which openly share their API Design for re-use (by APICommons or some other means) so that it can be re-used. This is not only future proofing your own application, it is supporting open shared interfaces. It’s important to recognize not all companies are in a position to completely open their API Design, but where there are choices – vote with your feet.

These rules of the road won’t prevent every case, nor will it always be obvious what is outright copying of all/most of an API, what is “fair” reuse. However, they could go a long way towards fueling openness from the ground up.

Summary

APIs have an enormous potential for progress in the world, however a very large part of that rests on the convergence of interfaces and not their divergence. Copyright claims, or even the threat of them puts this convergence at huge risk and could lead to an enormous amount of wasted work.

We’re convinced that open interfaces are critical for the growth of the Web and the API Economy – both of which are critical to many aspects of human development. Taking away the basic building blocks of those interfaces and stopping the propagation of best practice would be a huge tragedy.

Reward those that do the right thing, not the wrong thing – reward openness and we’re confident the open Web will will win through, court judgements or not.