APIs (application programming interfaces) are the glue that holds the digital world together. The defining characteristic of the fourth industrial revolution – after steam, electricity and computing, the transformative power of the digital innovation – is connectedness, and APIs are a large part of what makes the connections. This is the background to recent high profile cases in the U.S. and Europe that have battled over whether copyright arises in APIs and what it covers and doesn’t cover.

An API is the hooks and handshakes associated with particular software that let other software connect to and communicate with it. As an interface it is a set of rules or conventions that must be complied with for information to be exchanged and processed.  It lets application programmers use functions of the computer and operating system without having to track all the details directly and a consistent API allows the programmer to write an application on one computer with confidence that it will run on another computer even if the hardware is different.

APIs are increasingly designed to enhance the customer experience by making it easier to connect – to access, search and share information. They are ubiquitous: APIs allow a user to log-in to iPhone or Android Apps using Facebook credentials; share articles using icon short cuts that directly connect with Twitter, LinkedIn, Facebook or Tumblr; share the latest CandyCrush score with friends on Facebook; access/share information on restaurant reviews with Google Maps; cut and paste text from MS Word to MS Excel; search for flights using an aggregator service rather than each airline’s website; or save games to a Dropbox Cloud. They also allow your Fitbit to communicate with your smart phone and your fridge to tell you when you’ve run out of milk.

Much like every handshake is unique, APIs differ according to the requirements of the operating system/application/hardware that they enable connections with – it may be just a document providing technical interface specifications or it may consist of an extensive kit of routines, protocols and tools to assist application program development.

As you can see from the list, APIs have a myriad of uses and are key components of how we use technology today. They will become increasingly prevalent as the interconnectedness of the fourth industrial revolution gathers pace. With that in mind, how APIs are viewed from a legal perspective becomes increasingly important as businesses seek to leverage APIs to enhance their market position. We look briefly at the U.S. and European legal positions below and then suggest some guidelines to consider when developing an API development and use strategy.

In a long running saga, Oracle sued Google in 2010 for copyright infringement for Google’s copying of certain parts of 37 Java APIs when developing its Android platform. The case raised two important copyright questions: first, were the Java APIs protected by copyright? and second, if they were, was Google’s unlicensed use of them permissible under the U.S. doctrine of fair use?

Two U.S. courts reached differing conclusions on the first question. At first instance, the trial judge found in 2012 that the Java APIs were not eligible for copyright protection.  This was because although anyone is free to write his or her code to carry out the same function or method used in other software, U.S. law does not allow copyright to attach to written expression where there is only one way to write something; and under Java’s rules, the specification to carry out a particular function could only be expressed in one way, so the APIs were not protected.

That finding was overturned in 2014 when the appeals court held that the Java APIs were in fact protected by copyright because the “declaring code and the structure, sequence, and organization of the API packages are entitled to copyright”. The case was sent back to the district court where, on 23 May 2016, the jury found that Google’s use of the Java APIs amounted to fair use and so was non-infringing.  Oracle has been reported as planning to appeal, so the U.S. saga may not be over yet.

In Europe, the Software Directive (2009/24/EC) states that ideas and principles underlying any element of a computer program, including those underlying its interfaces, are not protected by copyright. Although the Court of Justice of the European Union (“CJEU”) has not ruled on the specific question of whether or not copyright attaches to APIs, in 2012 in SAS Institute, Inc. v World Programming Limited (C-406/10), it was asked to interpret the Software Directive in a case where WPL had developed a competing product with similar functionality to SAS’s product.

WPL’s product permitted users to use the SAS programming language to execute commands and perform functions in WPL’s software with the same effects and outputs as if they had used SAS’s software. WPL did not have access to the source code or object code of the SAS system. Instead it lawfully acquired copies from SAS and copied the functionality by writing its own code. WPL argued that these activities were not copyright infringement. The CJEU agreed, finding that there was no copyright to infringe: “neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program”.

It noted, however, that that principle of non-eligibility could not preclude the possibility that the SAS programming language and the format of the data files could be protected by copyright if they met the copyright originality standard as the author’s own intellectual creation.  Although not specifically at issue, the judgment has been widely publicised as stating that the accepted EU position appears to be that APIs are not protected by copyright because they are functional in nature.

So, what does this mean for software developers and what is recommended best practice for developing an API strategy? At the moment, the European and U.S. rules differ.  APIs also vary widely – from specification document to elaborate software toolbox – so that the line between function and expression may fall differently for different APIs. For these reasons, we suggest the following as a practical way forward to manage API legal risk by assessing APIs case by case basis within the framework of a structured, organisation-wide approach:

• Bring together a group of all relevant stakeholders – software development, business, legal, etc;
• At the high level, articulate the organisation’s goals for the APIs it develops/licenses/uses
• Consider carefully and case by case the API’s purpose and functions:
  • what is the API’s rationale/methodology?
  • who will it be shared with internally/externally?
• Consider carefully and case by case API development options:
  • can the required code be written from scratch?
  • is already written code available under acceptable (e.g. permissive) license terms?
  • does the owner of the software/platform/hardware with which the API needs to connect require use of its own code for APIs? Is it available on acceptable inbound licence terms?
  • how frequently (if at all) will the API be re-written? How long and how will it be supported?
  • can clean teams be used to reduce infringement risk?
• Get to the facts:
  • what/how much code has been/is to be copied?
  • when/for how long is it copied (e.g. just at runtime?)
  • Is that copying effectively unavoidable?
  • what would be the alternative?
• Remember copyright protects documentation and preparatory design work as well as software;
• Don’t forget contract or other intellectual property (e.g. patent, confidentiality) aspects
• Prepare and apply API outbound license terms for external use in appropriate cases.

Deirdre Moynihan,
Kemp IT Law, London,
July, 2016
deirdre.moynihan@kempitlaw.com