BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Can APIs be Copyrighted?

by Alex Blewitt on Apr 23, 2012 |

The recent Oracle vs Google case, covered by InfoQ elsewhere, has brought around a significant change in the original complaint. The outcome of the trial has much wider ramifications to the technology industry than a licensing dispute over mobile phones.

Whilst the case was initially based on the assumption that Oracle's patents were valid – now all but demolished – Oracle has switched tack to claim that it is a copyright violation. At heart is the question of whether an API or even a computer language can be copyrightable.

The Android language is a subset of the Java language, and even compiles down to Java classes via the javac compiler (or other IDE based compiler). This output is then handed to the Android/Dalvik specific DX tool, which translates the output to Dalvik bytecode, for execution on Android's Dalvik VM.

The Java bytecode and Dalvik bytecode are completely different, with Java's bytecode and VM being stack-based and Dalvik's bytecode and VM being register based. At the VM level, the two systems are completely different.

However, the language for both Android and Java is – to most intents – the same. The Android toolchain even uses the same JavaC compiler as a front-end translation tool, although not necessarily as a final destination. As a result, the APIs that are used in Dalvik follow the same language as Java. In order to operate with the JavaC compiler, a specific subset of the Android APIs match with the Java APIs – for example, classes like java.lang.String.

Most of the implementation in the Android toolchain is based off of the (now-defunct) Apache Harmony project, which was a clean-room implementation of Java which shut down last year on the basis that Oracle would never allow it to run against the Testing Compatibility Kit without a field-of-use restriction for mobile space.

Oracle is now claiming that as designer of the Java APIs, not just its OpenJDK (GPL) implementation is covered by also every implementation ever of the Java APIs are covered by its copyright. Thus, any implementation of the Java APIs – whether they are called Java or not – are violations of Oracle's copyright.

SCO used the same tactic when alleging copyright of a massive scale of Linux against its codebase, despite the fact that most of these were the names of APIs. (That case essentially collapsed when it was ruled that SCO didn't own the copyrights in the first place.)

Florian Mueller of FOSS Patents thinks that it's a slam-dunk case that Google needed a license for Java, not the least of which was the now-famous Lindholm mail in which reports that an engineer's opinion is that they need a license to do what they're doing with Java:

What we've actually been asked to do (by Larry [Page] and Sergey [Brin]) is to investigate what technical alternatives exist to Java for Android and Chrome. We've been over a bunch of these, and think they all suck. We conclude that we need to negotiate a license for Java under the terms we need.

However, this doesn't necessarily state that APIs are covered by copyright, just that if they wanted to use Java as-is they would need a license. Oracle is now claiming even stronger that due to the effort involved in creating the APIs that they should own copyright on it as well. It's also worth noting that Florian is in a consulting relationship with Oracle:

That said, as a believer in transparency I would like to inform you that Oracle has very recently become a consulting client of mine. We intend to work together for the long haul on mostly competition-related topics including, for one example, FRAND licensing terms.

Until now, languages have been considered exempt from copyright. Only the ideas expressed in a specific way are copyrightable; so a specific English text (like Shakespeare's Hamlet) is copyrightable, but the English language itself isn't. If ownership of a language is copyrightable, then potentially Oracle is claiming copyright of every Java program ever written.

If the language isn't copyrightable, what about a specific set of APIs? In this case, Android and Java share 37 APIs (i.e. methods on classes like String and ClassLoader). It's also clearly the case that Android doesn't pass itself off as Java – unlike Microsoft's extensions in the late '90s – so doesn't need to be a superset. Microsoft was subsequently forced to change the name of its language to J+ to avoid any future incompatibility claims, but was allowed to continue if it didn't call itself Java.

Creating a good API certainly takes time, and it's a non-trivial effort (witness the ongoing design discussions about the Lambda project, for example). However, is the result of the API copyrightable in and of itself, particularly when it comes to alternative implementations? It is this question which Oracle and Google are divided over.

Google's argument that the method names and type signatures are not themselves copyrightable is based on an argument against a 'Mock implementation' which returns default answers such as 0 or "" for every method. This clearly wouldn't be the same as in Java; would that be considered as a copyrightable claim? If the names and types are not themselves sufficient for copyright protection, what is?

Oracle's argument is that since the API design takes time (and good APIs even longer) that the collection should be considered as a combined work, and thus is copyrightable. However, if this were ruled as true, it would have a significant impact in any programming language as APIs are used by client programs and – in some cases, implemented – by other programs. (Every Java JDBC driver which implemented the Connection interface, would be violating that copyright, since an implementation of an interface has a de facto copy of the API's signatures.)

Simon Phipps writes in InfoWorld that If Oracle wins, Everyone loses:

… flies in the face of the received wisdom of the software industry. It's so widely accepted that programming interfaces and languages are beyond the scope of copyright that very few cases have ever been brought to court. In those that have, the received wisdom has largely been upheld.

This is a good thing. Without it, the lives of programmers would be much more complex. Header files and function prototypes would all need licensing from their owners, so programming for any operating system would at best require attention to license compatibility and at worst would involve total control of the programming lifecycle by the platform vendor.

Even if Oracle wins, it's not clear that it will help its own customers. If they manage to get a ruling that decries APIs as copyrightable suddenly any APIs that are used in computer programming language might be asserted to be violations. This in turn will make developing software more expensive for everyone, not just in the Google and Oracle case. Phipps argues that this would only affect America:

This would be largely an American phenomenon. In Europe, there is continentwide law asserting that programming languages and interfaces are unlikely to be copyrightable, and even if they are, an exception written into the law allows copyright to be ignored if the purpose of infringing it is for interoperability. Any precedent set by an Oracle win would likely just harm the American technology industry and offer an advantage to its competitors.

Whatever the outcome of the trial, the result will have ripples in the technology industry. The case continues.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Takes time? by Ronald Miura

Well, designing a good language also takes time :)

Spin by Vic Cekvenich

I think this article is a bit of pro google spin.
To be balanced, here is the other side: www.oracle.com/us/corporate/features/opening-sl...

My POV is the patents are public, you can pull them up on www, yet you still need to license it.
Separate form patents, a second issue, is copyright. You can not take GPL code and just Apache re-license, only the creator can license it under other terms.
Is it similar to Geronimo vs JBOSS? That did not go to court.

As a programer that sometimes does open source, respect the license and don't remove author's attribution in the source code.
Java developers that knew Java before Anroid know who was first and that Andorid is Java under another name. Saying Sun sux is not relevant, they do suck, but they own Java IP.

Java & the Oracle-Google competition by John S Wolter

Everyone should be aware that a _good_ corporate lawyer(s) will allege anything. It is their job. They are paid advocates for their clients. It is the core of our legal system. We can debate this point forever, we the users of Java have other priorities.

I think this legal bickering is a fantastic opportunity. Java can be replaced if necessary with an open source alternative. The evaluation of the current alternatives would conclude, I think, that a major commitment to develop a new language is necessary.

Give this, innovators will be free to concentrate on innovation. Marketplace winners can come from real competition and not artificial intellectual property declarations.

The Open Source communities have matured to the point with _Google's_Open_Source_commitment_&_written_promise_, to make a major contribution to the development of a new and outstanding Java replacement. This could be accomplished in a relatively short period of time.

Java was first released in 1995, 17-years ago. Many new things have been learned from the wide breath of web, mobile, and other applications.

Take an example like Eiffel. Hunched away in the corners of programming languages it had at its outset a commitment to getting object-orientation right. We could also look to the features of Google's new DART, the ideas of Actors expressed in SCALA, scalable concurrency in Erlang,and there are so many new ideas. Uses from the smallest embedded system to planet wide applications have made Java obsolete.

Combine this new application understanding with new knowledge and there will be an explosion of new businesses from which we will all benefit.

Re: Java & the Oracle-Google competition by Serge Bureau

You have no clue my friend.

The language is nothing, all the libraries and the JVM and JIT are the important part.
Loosing 15 years of library design is unthinkable.

And please go back and read, Google already tried to have an alternative, there is none.

Google only has to pay it's due like everybody does

Re: Spin by Alex Blewitt

The patent issue is still outstanding, but the Apache code was developed by the members of the Apache Harmony project under the Apache license - code was not copied. However, to attempt an implementation of the Java libraries (which is what Apache was trying to do, under the agreement behind the JCP) requires that the same method names and argument types are used. Correlation does not imply copying.

Disclaimer: I implemented a bunch of the Pack200 code on the Apache Harmony project, although this is not one of the APIs used by Android.

Re: Spin by Serge Bureau

I disagree, a lot of thinking goes into API, think SWING for example.

Plus you have acces to all their Doc and design papers plus examples.
This is copy.

However if you want it to be public, you allow this.

A replicated Mona Lisa is a copy, the originality comes from the original (as the word imply)

Re: Java & the Oracle-Google competition by Chris Alexander

I agree with John. However, truth be told the under 30 crowd of engineers and architects have already begun to migrate to other languages. I only see 40-somethings like myself and my colleagues filling enterprise positions where Java has rooted itself. My son and his buddies (late teens/early 20s) are developing the next generation of non-enterprise, mobile and web-based apps without looking at Java and the pain of tweaking a VM. They have seen their Dad's and Uncle's pulling into the driveway too many nights with bloodshot eyes cursing structural and architectural demons swarming around "real world" Java implementations. Add the snail-like JCP and inherent malaise of a large corporation like Oracle who wants to exert control over the language for marketplace advantage (not for the sake of the language itself), you have all the classical signs of language and community decline. Let's revisit this thread in 10-15 years.

Re: Spin by Shi Kafune

it would have been so much better if IBM or Google had bought Sun

Re: Spin by Faisal Waris

It would be fair if Google had bought Sun. I think Google was in-part responsible for driving Sun into the ground by drying up Sun's $1 billion/year revenue stream from J2ME, by releasing Android.

Re: Spin by Ronald Miura

It would be fair if Google had bought Sun. I think Google was in-part responsible for driving Sun into the ground by drying up Sun's $1 billion/year revenue stream from J2ME, by releasing Android.


Java is still relevant to the mobile space only because Google created Android.

But I kind of agree that if Google had bought Sun back then, things would be much easier :)

Re: Java & the Oracle-Google competition by Rodrigo Lopes

The language is nothing!? Oh, the case is over. Google didn't copy jvm or jit just reimplemented from the scratch and copy the nothing (the Java language). Jit and VM are concepts replicated somehow (patent infringements can exist but not copyright). Maybe the court sue Google to pay by patent violations to an open source project. Maybe some millions. Google will be very happy, surely.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

11 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT