There is a case between Google and Oracle over the use of Java and it's standard library on the Google Android operating system. From this article:

To recap: Oracle accused Google of copying some of its Java computer code when it wrote Android. Android itself wasn't the issue. Android is different than Java. But Google wanted developers who work with Java, a popular language for web apps, to jump to Android. So it incorporated Java's application programming interfaces (APIs) into Android. This allowed them to quickly convert their apps to Android and it meant that the millions of programmers trained on Java would be familiar with Android, too.

Oracle sued claiming that the APIs were copyrighted. But the judge ruled that APIs are not subject to copyright laws

On Friday, an appellate court just overturned that loss, and said APIs are subject to copyright.

If many popular APIs become subject to copyright laws and owned by the organizations that created them, how might this affect the projects that develop software applications that use these APIs, and how might it affect the Open Source industry at large?

  • 1
    law.stackexchange.com may be better suited for this question
    – Martijn
    Commented Jul 2, 2015 at 11:14
  • The relevance I see to Open Source is that currently, with APIs not copywritable, anyone can create an open source version of proprietary software that can be switched to seamlessly. Copywritable APIs would remove this possibility, creating a significant barrier to switching to open source. Commented Jul 4, 2015 at 15:28
  • 2
    Meta question about this
    – Zizouz212
    Commented Jul 4, 2015 at 17:06
  • 1
    I'm actually still trying to figure out why people thought they weren't. Licenses like the GPL have always made me think that code was implicitly copyrighted, and when thinking about languages like Perl 6 where even the Grammar has an API... how could it not be copyrightable? Commented Aug 1, 2015 at 19:56
  • Aren't Java APIs developed by the JCP (Java community process)? How come that Oracle can claim rights on these APIs? Or are we talking about stuff that was developed outside of that process? Commented Sep 7, 2018 at 14:37

4 Answers 4


Just to make it clear, the Appeals court's May 9th, 2014 decision in Oracle vs Google made it clear that the structure, sequence and organization (SSO) of the 37 API interfaces Google had copied (in order to make existing software that was based on the copyrighted Oracle JDK work with Android) was subject to copyright. This is not new case law, but follows from Whelan v. Jaslow (1986).

Google could have adopted the API of the open source OpenJDK for Android, but choose not to do so, probably because most of the software that exists for mobile units assumes that Oracle JDK is available.

It should also be noted that this case has not been finally decided (what has been finally decided is that an API is still protected by copyright).

If we look at the actual decision that Oracle America, Inc. v. Google Inc., 750 F. 3d 1339 - Court of Appeals, Federal Circuit 2014, we see that the jury could not agree on Google's fair use defence:

Because the jury deadlocked on fair use, we remand for further consideration of Google's fair use defense in light of this decision.

The "fair use" decision was passed on for the Supreme Court to decide, and the Supreme Court decided to return this decision to the Federal Circuit Court in San Francisco, where Google will get a new chance to argue that its use of the API will be allowed as fair use.

If I were a betting man, I would put my money on Oracle in this upcoming trial. While I think "fair use" will apply in most uses of a protected API by free software, Google choose to incorporate the copyrighted API of the Oracle JDK in a commercial product. Commercial use is seldom considered fair use. Google's decision to use Oracle JDK also made Android interoperable with the proprietary Oracle JDK instead of the open source OpenJDK. While use to create interoperability is often considered fair use, Google choose to create interoperability with a proprietary product in a situation when a free alternative existed.

So much for background about this ongoing litigation.

Going back to the actual question, which seems to be about whether the Appeals court's May 9th, 2014 decision about API's being protected by copyright is going to cause adverse effects for innovation and interoperability for free software.

Personally, I think these fears are unwarranted. As already pointed out by bmargulies:

Many common APIs are explicitly licensed permissively.

The Oracle API, however, was not licensed permissively, and Google choose to not comply with the licensing terms. That is rare situation and will probably not impact much of free software development.

The obvious impact of Oracle v. Google is that developers (including open source developers) need to consider the licensing of APIs, and either accept the legal hazard that follows from using a proprietary APIs without permission, or to make sure they have permission (either through the API license, or by asking the owner for an explicit permission to use the API).

  • What was the difference between interop with the proprietary Oracle JDK and interop with OpenJDK when the Android team chose Apache Hatmony? (Today I believe those products are entirely interoperable, and I thought they were then as well.)
    – Alex Nauda
    Commented May 27, 2016 at 10:48
  • Apache aimed for interoperability. Not so with Dalvik. Google left off, most notably, Swing. Analogy: after-market muffler. The original muffler has a copyright. competitor examines the car and reverse engineers the widget (API, or, in this case, the muffler) to fit the car. For the purpose of interoperability they are allowed to break/work around copyright. Or so goes my understanding. Pls correct! So...if you re-implement an exact duplicate of an existing API for the purpose of interoperability you should be fine, provided that you reverse engineered.
    – Thufir
    Commented Dec 29, 2016 at 15:52

The impact is simple to state and impossible to quantify. Open source implementations that include copies of copyrighted APIs may constitute infringement. This is not a common case. Many common APIs are explicitly licensed permissively. So, for example, an API published under the GPL could preclude a GPL-incompatible implementation unless the copyright holder dual-licensed.

Also, typing 'implements X' where 'X' is some API included in the JDK/JRE is not what this is about.

  • 1
    this makes me want to go looking for a proprietary API that was copied from open source... Commented Aug 3, 2015 at 17:40

TL;DR version: read the bulleted list at the end.

A few things to mention before starting:

" Google used Copyrighted Oracle JDK API and then switched to Open Source OpenJDK API " is fake news.

To understand it you need to consider what an API is.

API is like a standard of calling like the phone book: a name and a phone number table. Only one way to write it to be right. You cannot change the phone number of a name or change the name of a phone number but you can emit some entries.

So the API of Oracle JDK , OpenJDK and Apache Harmony are the same. All are one copyrighted API bunch, always called the Java API. even though every implementation of these has a different license. Oracle JDK adds performance tools not APIs.

The real news is that Google is moving from open-source Apache Harmony implementation to open-source OpenJDK implementation. Both are as Oracle JDK implementations use the same Java API.

To make it clear code can be classified to API and Implementation. The API is a declaration. The implementations can differ, but all must adhere to the same API.

Unlike Natural languages, All current programming languages force declaration code to be strictly the same to declare the same concept. No way to write API code to adhere to a specification except only one. Google could not write the API any other way to declare the API for Java. Only one!

This is the first trial to mention that APIs are copyrightable. No law or trial to mention this before.

The API is common to a platform, Even Kotlin is using the Java API.

So why did the trial start? Let's go back and check Sun's profit model. There is Java SE for computers, and Java ME for Mobiles. Java SE is a one-piece take it or leave it. they refuse to let any vendor fragment it. You want to Implement Java SE, then implement it all, apply for a license, which checks you implemented it all correctly. Microsoft changed the API before. Sun won the case against them and killed Microsoft Java. That is why C# arose later.

The other option is Java ME, a superset of a subset of Java SE. Mobile companies license this from Sun, with no reference implementation, most of APIs are optional, leading to fragmentation. The most successful vendor was Nokia Symbian and Blackberry. But they were falling after Apple iOS.

Google was negotiating Dalvik ( or a pre-Dalvik as Dalvik appeared in Android 2.2)which removes some parts that are not implementable on a touch phone as Swing ( GUI window , e.g, Multiple Windows each with a close button is never nice on a small touch screen). This license does not match Java Se nor Java ME. But they canceled the negotiation.

The main objection of Sun that this fragments the Java SE, by removing some APIs and adding some API. Steering committees of Java can not control what was added or removed from Java SE.

Java SE back then did not have optional components. Ideas of Java SE Core and removing Swing from the Java runtime were not there.

Now, back to the impact on open source:

  • The first impact of Oracle vs Google is the same as Sun vs Microsoft: If you have projects big enough, then create a new language with a new Platform: C# with .Net or Dart with Flutter. Kotlin (most probably) is not a legal solution as it is in the same platform with same API.
  • Drop backward Compatibility with a debated in court product ( Microsoft Java and Android compatibility in
    Fuchsia) or negotiate legally or wait for the next case in court.
  • Open Source does not mean copyleft. The news are fake. The copyrighted API are shared between the open source OpenJDK and Apache harmony and the proprietary Oracle JDk.
  • For small entities that needs to re-implement a language or a platform API, you need a legal promise not to get sued (Mono got one for re-implementing .Net) or you need to use a language that no one owns (C++ or Javascript).
  • Do not believe newspaper in technical legal details. They do not read programming books nor legal case files.

APIs under copyright would be similar to software under copyright: you just can't use them as freely.

In software, if you have a piece of proprietary software, you're not allowed to redistribute, reverse engineer, modify, develop from, etc etc. If this applied to APIs, you simply wouldn't be able to use the API to do anything.

It also sort of depends what kind of API you're talking about. If you have an API in the Stack Exchange API sense - a set of URLs you can request data from - you may still be able to use these. Putting a website on the internet implies a right to view it; making data available at a URL implies a right to see that data. You probably wouldn't be able to make use of it in a product though.

If you're talking about an API as in the Java development API, then it suddenly becomes very hard for Java developers to write software, because they can't use the API without express permission from the copyright holder (Oracle).

Essentially, the implication of the case is that if companies want to, they can prevent people copying/using their APIs by applying copyright.

  • actually just because the url exists does not mean you have the right to use it, see things like hacking is illegal. Just because you can access a resource does not mean it is legal to do so. Also this isn't about using APIs, it's about copying them. Commented Aug 3, 2015 at 17:39
  • @xenoterracide Unless explicitly specified otherwise in related work or in law, the existence of an unprotected URL (i.e. no 403 returns, etc) implies you are allowed to visit that URL. Also, the same principles apply to use and copying: if you're not allowed to use it, you're usually not allowed to copy it.
    – ArtOfCode
    Commented Aug 3, 2015 at 17:59
  • yeah but being allowed to use it, doesn't mean you're allowed to copy it. and just because someone forgot to protect their site... well... I'm just saying you should be careful about telling people what they can do just because they "can" get access to something. Just because a site was vulnerable to heartbleed doesn't make using the exploit legal. Hey that login url was unprotected, and you said I could attempt to login... so I did... just while I was doing that I was also getting your memory to dump... but it was possible... Commented Aug 3, 2015 at 18:05
  • @xenoterracide That comes under "explicitly stated in law", as I said in my last comment. And I haven't said that being allowed to use something means you can copy it.
    – ArtOfCode
    Commented Aug 3, 2015 at 18:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.