Over the past couple of years, Oracle has been seeking $8.8 billion in damages for Google’s use of Java in Android. If you’ve taken a look at any tech websites or the finance section of a newspaper in the past couple of years, then there’s a good chance you already know that.

But let’s hold on for a second. Java is a programming language, and not an API. So what exactly does any of this have to do with APIs? In general cases of Oracle seeking back payment for Java SE, not a whole lot.

In this specific case, however, Siri Mårtensson of Delphi Law Firm describes how Google actually “used part of the Java API in Android. Oracle saw this as an infringement of their API.” Right off the bat, a big question springs to mind – was this dishonest, perhaps even unlawful, behavior on the part of Google or a failure on Oracle’s part to properly outline the terms of use of this API?

And most importantly, given this precedent, is there a need for all API developers to look at ways to protect their APIs from potential misuse? Below we’ll look at legal strategy, patents and copyright protection, as well as options providers have regarding open sourcing.

Google vs Oracle: Tracking the Case

Before we get onto the legal implications of this case ruling for API providers, let’s first look at a few facts that are key to the case as outlined by Mårtensson’s presentation:

• In May 2012, the District Court rules that APIs can’t be copyrighted as they refer to a method or function, and are not eligible for copyright protection. Oracle appeals immediately.
• In May 2014, the Appeals Court rules that the “structure, sequence and organization” of an API can be copyrighted. The case is remanded back to District Court.
• In May 2016, the District Court found that Google’s use of Java API in Android falls under the heading of fair use. Oracle attempts to appeal, but the appeal is denied.

Since last year’s ruling could have major repercussions in the API space, it seemed like the right time to take a closer look at the current legal landscape of building and working with APIs.

You Made This? I Made This

There’s a humorous meme online that refers to those on the web who present original content (OC) as if it’s their own — this will ring all too true to those who have encountered reposters in their online lives.

Because they can be used to offer detailed information and statistics, often giving them the power to mimic the behavior of other apps, it’s easy to see the potential for misusing APIs. It isn’t difficult, for example, to imagine someone paying to use a powerful API, reverse engineering and re-skinning the front end of its parent app and presenting it as a new product.

This is hugely problematic in that they may not necessarily violate the terms of use of the API…if the API developer has even bothered to define these terms in any meaningful way. In other cases of infringement, a cease and desist/lawsuit threat would usually be enough to deter the copycat. Unfortunately, that might not be so simple when it comes to APIs.

APIs And Non-Tech Juries

Cases that are brought to trial may, as in the case of Google Vs Oracle, involve a jury. APIs may be gathering steam thanks to the Internet of Things and other consumer facing products, but it’s still fair to say that the majority of the general public have little idea how APIs actually work. As such, how can the laymen be relied on to dictate the outcome of cases that hinge on the minute technical workings of APIs?

Mårtensson highlights the efforts of Astrachan to clarify this for the jury in this case as follows:

“It’s just like how computer users are accustomed to using Control-P or Command-P as the “print” function on a computer. What would happen if all of a sudden, Control-P or Command-P meant ‘Paste’? If the API changes, then users of that file menu wouldn’t be able to accomplish tasks.”

It’s a decent analogy to explain the role of APIs and declaring code, but still could leave members of the general public who don’t even know where to find the Control or Command buttons on their keyboard confused.

The Fair Use Problem

The current standing of the Google Vs Oracle case has an important set of repercussions for both software developers who create APIs and those who consume them. A Wired article in 2014 neatly sums up the issues for API producers as follows:

“When a company contemplates whether to open up its capabilities and embrace new opportunities, it’ll have to think: am I going to be copying, inadvertently perhaps, someone else’s API? Must I come up with some strange and unique way that developers will need to call my service, to avoid being sued once I get successful?”

But there’s another issue here, in that developers who are cagey about their IP being copied may decide to shutter APIs or even neglect to open them up to external parties in the first place. Fair use is a very loose term, and there’s simply no guarantee that API developers can rely on it to get services that they see as copycats shut down – an article for Chemical Innovation highlights exactly how tricky the principles of fair use can be.

Routes for API Legal Protection

So what are the options for API developers looking to protect their creations? There are a couple of different routes, and the really good news is that one of them requires almost no extra effort.

1. Patents
Mårtensson states that “method patents are actually quite rare in Sweden. In fact, patents for software at all are very rare. In the US, it’s much easier to obtain a patent for software.” That’s not to say, however, that they are the right choice for everyone.

To move ahead with patenting software or an API, you’ll need to speak to a patent lawyer and file the appropriate paperwork. That process can be expensive and time consuming, and there’s no guarantee that the patent will be approved unless it demonstrates sufficient:

• Utility, i.e. has a reproducible technical effect
• Novelty, i.e. not known/published before the patent application
• Inventiveness, i.e. substantive differences from the status quo and not obvious to a skilled person

2. Copyright protection

This is the more likely route for software, including APIs. But Mårtensson offers the reminder that “it’s important for you to know that it’s always the format that is protected. An idea, function or a method can never be subject to copyright. You need to write something down, it needs to be physical.”

Copyright arises automatically at the time of creation via the person who actually writes down the code, but in most cases the right is handed over to the company if it’s written by a full-time employee. Of course, this is a little more complicated in the startup world where several co-founders and contractors may be working on code simultaneously. Mårtensson clarifies one particular situation, stating that “if you contract an engineer outside of your company, then you need to have an agreement saying that you as a company require the rights to the code.”

Copyright can be broken down to both an economic right – the “exclusive right to decide how the work may be presented, distributed and displayed. And if the work is used by others then the author has a right to economic compensation” – and the moral right, which gives the right to be named as the author of the work. It also limits “how others may modify, develop further, transfer and lease” the work.

The fact that copyrights are generated automatically – and using the © mark isn’t even mandatory to be covered by them – is likely to be a real source of comfort to developers who are much more at home fiddling with the nuts and bolts of APIs than they are with legal precedents.

While it certainly can be beneficial to lay out the terms and conditions of using your API, the bottom line is that many APIs are (at least some extent) legally protected as soon as their code is written.

3. Open sourcing
Mårtensson hints at the appeal of open source in her talk when she encourages API developers to consider how their API adds value; is it the function(s) that the API allows or something else?

For example, if you have an API that can do some really cool things then you might want to charge for its use. If it’s more of an expansion for your core chargeable product, and requires a license for the latter, you may consider making it open source and letting people run wild with it to encourage more potential customers.

An open source license like the MIT license places very few restrictions on using, modifying and redistributing copies of software but there are plenty of other options that may be more suitable such as:

• Apache License 2.0
• BSD 3-Clause “New” or “Revised” license
• BSD 2-Clause “Simplified” or “FreeBSD” license
• GNU General Public License (GPL)
• GNU Library or “Lesser” General Public License (LGPL)
• Mozilla Public License 2.0

Apache 2.0, for example, takes a similarly liberal approach as MIT but has a few caveats relating to redistribution. There’s a very useful, if quite dense, guide to the ins and outs of open source licenses on Wikipedia.

Open source can certainly be a viable business model – Git, Drupal, Python, even Wikipedia are just a few iconic open source projects – but it requires a slightly different approach to traditional “paid for” products. Your core offering might end up being a service that’s parallel to your API, or even the provision of your services as a consultant to help people build their own projects.

It’s no surprise that open sourcing is popular in the API space, as it effectively establishes you as the landlord of many different services that are built on the back on your product. That opens up your options when thinking about monetization further down the line.

Final Thoughts:

One observation worth making is that Google and Oracle are both very large companies – this case is Goliath Vs Goliath. In most cases, it would be more likely that a company willing to steal an API is a scrappy startup while companies that have reached the stage of offering a thriving public facing API library will be larger and more established. Mårtensson acknowledges the legal cost of taking a matter like this to trial could be an inhibitor for small businesses:

“to end up having a lawsuit from a bigger company saying you are infringing our API or our rights can take a very long time, a lot of money, time and effort spent. Even if you end up ‘being right’ in the end, it’s still a big risk.”

In many cases, the threat of a lawsuit alone will be enough to deter smaller companies from facing a protracted legal battle. Of course, the flipside of this is that smaller companies must pay close attention to the ways in which they use APIs to avoid facing legal action.

Is Google Vs Oracle the last case we’ll see relating to the, perceived or otherwise, theft of APIs? Absolutely not. There’s still a lot of grey area; this case isn’t as clear cut as it could have been – in cases where there is obvious market harm, it’s more likely both that cases would be resolved quickly and that it would be decided in favor of the defendant.

We must also remember that the case is somewhat unique in that it deals with a Java API that’s part of the programming language, and thus the software’s behavior itself, rather than an open API on the web. We’re glad to say that the nature of the web API space has historically been very inclusive and open – here’s hoping that the ongoing threat of legal battles doesn’t change that!