Viewpoint: Google and Oracle's Java clash must be resolved

The Google-Oracle trial has been one of the most closely watched legal wrangles in the history of the technology industry.

One of the remarkable things about the case is the deep divisions that it exposed in the developer community.

This has certainly been the case within the London Java Community (LJC), a broad organisation with about 2,500 members, covering a diverse set of viewpoints within London's Java ecosystem.

Java underpins a good chunk of today's software and IT around the globe. In purely commercial terms it is a foundation of a multi-billion pound global industry, and by many measures, is the most popular programming environment in the world.

This case therefore has the potential to affect a large number of people and businesses.

One point of view is that strong compatibility requirements provide a firm foundation for innovation.

Without them Java risks turning into a family of loosely related languages, which increases risk for everyone who deploys technology based on the Java ecosystem.

From this angle, Oracle had no choice but to try to prevent Google from fragmenting the platform.

An opposing view was that Google's Android represented a significant innovation, and has unlocked an entirely new market, which Oracle unfairly tried to stifle.

Copyright clash

The dispute had run for years and relatively late in the day it took a somewhat surprising turn when Oracle tried to claim that the APIs that constitute the Java libraries were protected by copyright.

Oracle's chief executive had sought about $1bn (£630m) in compensation

The implication was that Google were not legally entitled to produce an implementation of those interfaces.

This development represented a major escalation of the case.

If APIs were held to be copyrightable, this would have repercussions across the entire tech industry.

Many developers were concerned that this decision could lead to a chilling effect on the production of software, opening the door to a torrent of lawsuits - affecting firms of all sizes.

On the other hand, if APIs are not copyrightable, then this would allow significant freedom for companies to implement clones of existing technologies, without requiring full compatibility.

This could allow substantial innovation, but also has the risk that technology standards could be undermined.

The resulting externalities of increased testing costs and compatibility risk would be passed on to firms who want to deploy technology stacks covered by such a decision.

EU ruling

Whilst both possible decisions have risks and downsides associated with them, the continued lack of clarity is also a serious concern for both developers and consumers of software.

We feel that the issue of whether APIs are copyrightable is sufficiently far-reaching that it should be addressed as a point of law in its own right.

In this case, the European Union has made its position clear - on this side of the pond APIs are not copyrightable, and developers may produce a so-called "clean room" implementation of an API without running foul of copyright law.

Google's chief executive does not believe Oracle should be compensated for the use of its APIs

It remains to be seen how the US will tackle this issue.

It seems almost inevitable that the US courts will need to reach a position on the copyrightability of APIs.

Unresolved

This dispute is set to continue to dominate the tech press for quite some time to come.

The uncertainty with which developers have been living for some time is not going to go away, especially with regard to the API copyright question.

Google and Oracle appear to be dealing with a portion of the copyright issue (in terms of discussing damages). However, the ongoing worry for developers is now whether this case is really done or not.

Oracle of course has the right to appeal and so this chapter may not be closed yet.

<italic>Ben Evans is chief executive of JClarity - a Java-based software development company - and represents the London Java Community on the Java Community Process Executive Committee which develops standard technical specifications for the programming language.</italic>