Oracle v Google

Oracle is suing Google for copyright violation because Google created a compatible implementation of Java in Google's Android operating system. Very little actual copying has been shown, so the case hinges on whether the structure, sequence and organization of the Java APIs can be copyrighted. What?! That decision would cripple competition in the software industry and create problems for all software engineers.

APIs are how software applications interface with other systems. It's a very loosely defined word and includes everything from Java-style packages to hardware BIOS to network services. The only purpose of an API is to provide the method of operation for an application to use the features of another system. Methods of operation are not copyrightable! Everyone in the software industry has assumed that APIs are not copyrightable. There have also been high profile legal cases such as Lotus v Borland that have reinforced the understanding that APIs are not copyrightable.

Testimony in Oracle v Google has told us that developing an API is hard, creative work. This is untrue. It conflates a system's API with the ideas embodied in the system. Developing those ideas can be extremely hard, creative work, but once the ideas exist, an API can be generated mechanically by simply following engineering practice. For example, the Unix operating system implemented a completely novel process management system. The API for process management comes directly from that idea combined with engineering conventions such as using numbers for error codes. Unix uses the words "fork" and "exec" to help make the API easier for people to understand. The words are not meaningful to a computer, so "clone" and "load" would have functioned equally well as an API. Frequently the words to use are obvious because the ideas are well known outside the system. Mathematics, cryptography, databases and networking all have standard terminology that show up in APIs. In rare cases, such as the Unix example, the choices of words are creative and establish new vocabulary for software engineers. I don't think any of the contested Java APIs fall into this category, but what if some do? Is it worth protecting this?

An API is built once and then used many, many times by application software engineers. Applications are so dependent on APIs that lock-in is a commonly discussed problem. If just one API becomes unavailable, unsupported or unstable, it can cripple an entire application. There are currently three common approaches to this problem:

1. accept the risk;
2. only use APIs available from multiple sources;
3. write wrapper APIs to insulate the application from other APIs.

In the first case, copyrights on APIs have no effect. (Of course if an application is composed of systems with custom APIs, copyright infringement could now apply to those custom APIs, so "no effect" only applies to small, simple applications.)

In the second case, copyrights on APIs would restrict competition to provide only incompatible APIs. If multiple systems provide competing functionality, an application programmer could not switch without rewriting portions of the application. Application programmers are also hurt because the first API to market can grab the most common words for an idea and force others to use poorer choices. It's unclear whether anyone can write "lang.math.max" anymore if "java.lang.math.max" is copyrighted, so competition may be restricted even across language and system domains.

In the third case, copyrights on APIs would create patent-like minefields for software engineers because they would have to show cleanroom conditions if a wrapper API has similar structure, sequence and organization as someone else's API. The current common approach of re-implementing an API already in use for another system will definitely not fly. Willful infringement for patents is easily prevented by not reading patents. Cleanroom conditions forces software engineers to not read software!

Wouldn't it be strange if Oracle won a decision that means the original Oracle database infringed IBM's System R database API? Or if Oracle Linux infringed Novell's Unix API? Or if Sun's WABI infringed Microsoft's Win32 API? Or if Sun's NeWS infringed Adobe's Display PostScript API?

As a software engineer, this case is impossible to accept. The world has gone crazy. Mathematicians must have felt similarly in 1897 when Indiana's legislature was debating pi. Unlike that circus, Oracle v Google will have a decision. Tune in next week to find out if software competition still exists. Crazy.