Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Copyrighting Code & Interfaces: Ask The Right Questions

In May of 2014, a Federal Appeals Court determined that Google has, in fact, violated Oracle's copyright on the Java API. The Federal Appeals Court remanded the case back to a District Court, essentially indicating the decision was the right one. Google could now try to make another case based on fair use or other "exceptions" to copyright. But, unless the U.S. Supreme Court takes on the issue, the question of whether the Java API itself is copyrighted is settled.

The Solicitor General's office of the United States agreed with the ruling and recently issued a brief encouraging the Supreme Court to leave the case as it stands. Their opinion hinged on the API's classification as computer code:

Despite the inherently functional character of all computer code, the Copyright Act makes clear that such code can be copyrightable. Nothing about the declaring code at issue here materially distinguishes it from other computer code, and petitioner has identified no genuine conflict of authority concerning Section 102(b)'s applicability to circumstances like these.

A lot of folks have published arguments about why allowing copyright on an API is just plain wrong. Mike Godwin at The R Street Institute, for instance, argued that APIs are more like fashion or food. He attested that the API isn't "part of the code," per se, but rather something like a recipe used to develop a number of different versions of the same dish. Mike Masnick at TechDirt agreed that the API is not part of the code and hence isn't covered under copyright law. While these may be solid arguments, that doesn't necessarily mean that interfaces shouldn't be copyrightable.

As an example, late last year Cisco sued Arista for copyright infringement over the wholesale copying of the Cisco CLI in Arista products. Is this a valid use of copyright law, or not? Suppose a company comes up with a user interface design that makes data entry twice as fast for any particular task. The design can't rightly be hidden, nor can it be patented (unless it can be described as an algorithm or technique, which is a high hurdle to clear when dealing with user interfaces). The only option left is copyrighting the interface "as a whole" to protect the intellectual property represented by the research and work put into the design. Should the new interface design be copyrighted, or not?

Leaning on the "code/interface" distinction isn't going to allow either the Cisco CLI lawsuit, or the company that builds a more efficient user interface, to move forward with a copyright claim. The "interface is not code" line of argument doesn't really work across all cases.

How, then, should copyright apply? A simple question applied to all three cases might provide some clarity (if not a perfect answer).

  • Is the Cisco CLI innovative?
  • Is the new software interface in our example innovative?
  • Is the Java API innovative?

By focusing on innovation, rather than the code/interface distinction, each of these cases can be more easily answered. It doesn't matter which side you come down on for each of these three questions, the question itself provides a basis for discussion over innovation and where the inventor of a particular interface is adding value (or not). Using these grounds, it's possible to apply the old standard test of the patent system: Would someone "practiced in the art" find this new idea different, innovative, or something that few (or no other) people would think of?

Maybe the solution to this particular conundrum is to change the questions we're asking. Oversimplifying the problem and boiling it down to whether all APIs are software or not misses the point. Instead, we must protect the creation of new things and also allow innovators to adapt the best of the commonplace to create new and useful products.