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.