Oracle v. Google and API copyrightability

No readers like this yet.
Two government buildings

Opensource.com

As has been widely reported, the district court in the Oracle v. Google case has issued an order holding that the "structure, sequence and organization" (SSO) of 37 J2SE 5.0 API packages is not copyrightable. Oracle is expected to appeal.

The API packages at issue, comprising over 600 classes and over 6,000 methods, form part of the 166-package class library bundled with Sun's J2SE 5.0 JDK and JRE products. The accused 37 of the 168 packages in the Android Froyo platform's Dalvik class library substantially replicate the namespace hierarchy, class declarations, and method declarations of these J2SE packages, and provide equivalent functionality. Oracle claimed that this replication was copyright infringement, despite the fact that Google's implementations of the classes and methods were independently developed. From a source code perspective, 97 percent of the corresponding 37 API packages in the two platforms was dissimilar.

No US court had previously examined the copyrightability of APIs, let alone the SSO of a set of APIs. As was true of the recent SAS v. WPL case in the EU, the issues here principally involved the distinction between copyrightable expresson and noncopyrightable idea. Section 102(b) of the 1976 Copyright Act codifies this distinction, stating that copyright does not "extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery".

In asserting an SSO infringement theory, Oracle was drawing on a line of cases that had recognized a residual copyright interest in software where there was no literal copying of source or object code. As the court explained, judicial support for nonliteral software copyright infringement theories peaked in the 1980s. Since then, courts have been more cautious, mindful of 102(b) and the need to prevent extension of patent-like monopolies to the copyright sphere.

The holding

There were two parts to the court's holding. First, the court addressed Java platform APIs on an individual level. The court held that anyone could replicate the functionality of the API classes and methods, using identical declarations, so long as the implementations did not copy from the original version. The court made much of the fact that Java's syntactic rules mandated use of identical declarations (modulo class and method names) in order to develop an independent implementation that would provide the same functionality as the original. Under the merger doctrine, where there is only one way of expressing a given idea, no one can claim copyright ownership of such expression. While it was not necessary to replicate the names used in the API packages, names are themselves not copyrightable. Despite the emphasis on Java syntax, the court's reasoning seems applicable to APIs generally, as well as to typical varieties of the technically distinct category of web services APIs.

The court then addressed the copyrightability of the 37 API packages as a whole. Oracle claimed that it was copyright infringement to group the various packages, classes and methods in the same taxonomic manner as the J2SE class library. Nothing in the Java language dictated any particular organization in order to provide equivalent functionality. However, the court considered the J2SE organization to be a noncopyrightable utilitarian "command structure" for carrying out specified functions. Moreover, interoperability considerations suggested that the 37 API packages as a whole were a 102(b) "system" or "method of operation". Essentially, the court concluded that it was necessary for Google to provide the same "command system" with the same taxonomic organization, names and functional specifications in order for some of the massive amounts of existing third-party Java code to be easily portable to Android, since such existing code assumed the availability of common Java platform APIs.

Relevance for open source

It is an interesting peripheral fact that both Oracle and Google release versions of the relevant class library codebases to the public under open source licenses. Source code for the Dalvik class library, which is based on a subset of the late Apache Harmony project, is available under the Apache License 2.0. Oracle has continued Sun's post-2006 practice of releasing source code for versions of the Java SE class library under GPLv2 with the Classpath Exception, as part of the OpenJDK project. The Classpath Exception, which transforms GPLv2 into an MPL-like weak copyleft license, was adapted from the license for the GNU Classpath project. GNU Classpath (which remains in active development) and Apache Harmony, both of which aimed to produce complete independent implementations of core Java class libraries, are legacies of years of tension between the free software developer community and Sun over the latter's efforts to maintain control over Java, one lasting effect of which was a cultural isolation of the open source Java ecosystem.

The issue of API copyrightability has deeper historical resonance. Much of the history of free software has been characterized by efforts to develop replacements for elements of dominant or popular proprietary platforms, systems and protocols. This is seen not only in the various free JVM and Java compiler and runtime projects, but also in the earlier efforts to develop unencumbered clones of Unix (GNU, late versions of BSD and their descendants, and Linux). "Interoperability" in the sense meant in the Oracle v. Google order may be seen as an objective of many such projects.

During the late 1980s and early 1990s, pivotal years for the development of free alternatives to proprietary Unix, the free software developer subculture was aware and fearful of judicial recognition of nonliteral infringement theories in software copyright cases. While the influential Richard Stallman was prominent in calling attention to the dangers of "interface copyright", his critics  accused him of advancing a theory similar to interface copyright in his interpretation of the GPL as applied to software libraries. (The introduction of the LGPL was, in part, a product of this conflict.) But both pro-copyleft and anti-copyleft camps were united by a basic belief that law should not be used to prevent the development of unencumbered interface-compatible reimplementations of proprietary software. The Oracle v. Google decision on API copyrightability, which one suspects validates the policy intuitions of most developers, is well within the spirit of that belief.

Richard Fontana
Richard is Senior Commercial Counsel on the Products and Technologies team in Red Hat's legal department. Most of his work focuses on open source-related legal issues.

12 Comments

Oracle lost the patent phase of the trial. Oracle lost the copyright phase of the trial. Google's supporters, including me, are celebrating Google's victory.

There is another victory here for open source that is not so obvious but may be even more important than the two listed above. When Oracle sued Google Oracle not only failed to obtain any money but they lost the majority of the patents that they used in this case. This puts those companies who are contemplating attacking open source with software patents on notice (again) that by doing so they are risking losing their software patents. Lawyers may not have a clue about prior art which does not appear in the patent records but the open source community sure does.

---------------------------------
Steve Stites

Yet another loss. Oracle has been ordered to pay Google's legal fees which amount to about $300,000.

http://androidcommunity.com/oracle-loses-again-ordered-to-pay-googles-le...

------------------------------
Steve Stites

The problem is not the copyrightability of the API but the fact that Google advertized programmers trying to convince them that the Google-made implementation was fully compatible with the JDK/JRE specs.

Google has created a compatibility nghtmare that costs a lot to application developers and defames the name of the Java platforms. We MUST say that the Android SDK is definitely NOT compatible with the Java JDK.

The abuse made by Google is in saying that the development would be the same. Google broke the contract offered in Java "Develop once, deploy anywhere".

As long as Google will not satisfy the compatibility test, or will reject bug reports related to its own implementation in the Adroid DSK, Google should not abuse the names and should instead use its own package names.

The Android platform is definitely not compatible. Applications have to be redeveloped and retested specifically for Android, the test on other mobile platforms certified (e.g. Nokia) are not enough.

Google lies to developers and to customers of devices running Android. It even created its own compatibility test, just as a commercial tactic to create another non-open marketplace for mobile applications.

So the copyright abuse is really in the abusive use of the Java reference name for too long. We know that Google lied to everyone (even to the court) and decided to abuse the name, just to refuse to open its own new proprietary platform.

Remember this : Android is definitely NOT open, much less than Java.

Google did not even want to get a licence in order to be able to integrate its specification in the Open platform to ensure the compatibility contract "develop once, deploy anywhere".

So Android applications now can no longer be deployed on Java platforms (mobiles, set tob boxes, TVs, media center appliances), and Java applications can no longer be deployed on Android devices. Google has created its own **closed** platform when insisting that it would be compatible with Java.

Do you really defend Google's closed platform here ? And the breach not really in terms of copyright but in trademarks and on Google's Android developer sites ?

If Oracle provided the TCK with an acceptable terms of use, then google would just implement java se or me. What oracle cares about is only to keep control and get the money.

Oracle gets much less control than what Google does with Android (which is all about controling the Google Apps Store and monetize it MUCH more than what Oracle does with really open licences).
But Google did not want any one of the available licences for Java (oncluding those that come at no cost).
Google wanted to promote its own new standard, and broke the interoperability, rejecting also the ISO standard specifications, rejecting the GPL principles.
Just compare the licence now wanted by Google for using its Andoid SDK : it is FAR WORSE for everybody than any available licences proposed by Oracle for Java.
The whole problem is there: Google had the choice, including with open licences. And rejected it. It wanted to get things outside of those licences as if it was a property thing.

But the main problem for everyone is that Google broke the interoperabiity, and REFUSED to adapt its SDK to cooperate with the open Java community. Who's more open ? Certainly not Google. What was asked to Google was to participate to the community if he wanted to influence the content of the JDK but also get official long term support for his propose extensions.

And The community could have had a voice to tune what Google proposed, to make sure that Java would remain portable and not limited to Android. There's absolutely NO community voice n the Android SDK. All is proprietary and decided by Google alone, that then forces all developers to follow his OWN decisions in the Android SDK. And force all developers to redevelop their apps for Android, testing them explicitly for Android.

Google has even failed to make Android portable with itself ! The upward upgradability which is a clear advantage of the Java platform is no longer true in Android alone.

I insist: the Android platform is a CLOSED platform because NOBODY else than Google can support it and because Google constantly includes new barriers including across its versions, forcin even the Androif developers to get new trainings, rebuild their apps, ultil Google will finaly vampirize those apps by creating its own version that will be the only one maintained across versions.

Effectively Google plays now the same closed game that Microsoft used in Windows (much less problematic today, Winphones are almost out of the market), then by Apple (with IOS).

Java was designed to work on all platforms. But now even Google blocks a compliant Java VM from running on Android devices (because it would mean that the same apps that may run on iPhones and Nokia could run on Android without changes) : this would mean that Google would no longer have controls on the contents available on mobile devices, meaning more competition between content providers and no more dependency with smartphone builders.

No more need to wait indefinitely for a firmware update by the OSM manufacturer. The VM would run correctly, would upgrade seemlessly, and applications would still work on these updated VMs. This is simply impossible with proprietary OSes like Android (and iOS, WinPhone)and on other devices (directly on your HDTV, or in your settop box, with a much wider market of apps working everywhere on all our screens).

I insist: the problem is not the copyrightability of an API but what kind of services this API is suppose to be used for. Google promises all sorts of things (including copying the documentation of the JDK from Oracle/Sun, and most of its Java source code), but fails in every other aspects. the Android VM is NOT working like Java. This means that Goofle lied even to customers and developers by republishing the JDK documentation WORD FOR WORD, but refusing to make the Android VM working as promissed in this copy. This is a clear defamation of the work made by Oracle/Sun and its open community to specify it and make it interoperable under clear design patterns.

Google did not even needed to reject Java to develop its own application market (now renamed Google Play, because Apple won against Google that called its Appstore like what Apple did for his iPhones/iOS platform).

Do you only know that Java works in open licences ? Including independant distributions where many core classes have been rewritten differently (including critical ones such as those involved in performance such as Security classes, 2D/3D rendering, audio/video codecs, and interoperability classes with lots of services like XML, HTML, CSS, web services, and high wuality mathematical packages (that DON'T run correctly on Android which produces wrong results, something that has never happened since several decenials in Java !)

"The problem is not the copyrightability of the API but the fact that Google advertized programmers trying to convince them that the Google-made implementation was fully compatible with the JDK/JRE specs.
Really? Can you provide a link?

Google has created a compatibility nghtmare that costs a lot to application developers and defames the name of the Java platforms.
How does this 'cost' developer? How does a product called 'android' defame a separate product called 'java'? That's like saying the Microsoft's impmentation of SQL defames MySQL's implementations. Droid and Java are two separate implementaions of similar concepts as are MS-SQL and mySQL-SQL...

"Android SDK is definitely NOT compatible with the Java JDK"
Where is the expectation that they would be?

The abuse made by Google is in saying that the development would be the same.
Can you point to a reference where Google stated that developing java on a Sun E10K would be the same as developing in Android for a cellphone? Really? REALLY?

Google broke the contract offered in Java "Develop once, deploy anywhere".
I want to see a copy of this contract. RODA doesn't exist in Oracle's implementation java (lookup "headless" sometime, or their implmentation of serial communications). You seem to be stuck on this idea that java and android are the same. Wheras they are only similar.

"As long as Google will not satisfy the compatibility test, or will reject bug reports related to its own implementation in the Adroid DSK, Google should not abuse the names and should instead use its own package names.
So no one else can have a 'System' class or an IO class? I don't think sun was particularly original with coming up with those names.

"The Android platform is definitely not compatible. Applications have to be redeveloped and retested specifically for Android, the test on other mobile platforms certified (e.g. Nokia) are not enough.
Welcome to the real world of software developement and configuration management. This is why my company is still using a 12 year old version of Windows - and java compatibility is not going to fix that either.
And why I have to have 4 versions of Oracle's jInitiator on my pc to run Oracle e-business.

Google lies to developers and to customers of devices running Android. It even created its own compatibility test, just as a commercial tactic to create another non-open marketplace for mobile applications.

What did they say that was a lie? Anyway, I believe that there are more aps for Android than for any other mobile platform, so I am not sure delopers are having a hard adopting the Android platform. Btw: Where is it written the Google MUST provide and 'open' platform?

"We know that Google lied to everyone (even to the court) and decided to abuse the name, just to refuse to open its own new proprietary platform.
We know that they lied? I wasn't there, so how would I know that? Were they sight for contempt? What "lies"? Show us the attribution of you claims?

Remember this : Android is definitely NOT open, much less than Java.
Is it supposed to be open? So what if it isn't? I don't know what point you are trying to make. Do you think that Oracle ERP, webcenter, or iFiles is 'open'?

Google did not even want to get a licence in order to be able to integrate its specification in the Open platform to ensure the compatibility contract "develop once, deploy anywhere".
Why would Google want their smart phone os to be run on TV tuners, DVR's, Camcorders, Torque Wrench Controlers, etc? Who says they have to? Who would expect that they would? One of my biggest beef with software vendors is how 'generalized' their enterprise software is - I end up paying to have the needs of asprin factories addressed in my software for running a CNC mill. A cell phone OS should work best on a cell phone.

So Android applications now can no longer be deployed on Java platforms (mobiles, set tob boxes, TVs, media center appliances), and Java applications can no longer be deployed on Android devices. Google has created its own **closed** platform when insisting that it would be compatible with Java.
You mean they did the same as Apple, RIM & Microsoft? Shame on them. And yet they are far and away the most popular OS, go figure.

Do you really defend Google's closed platform here ? And the breach not really in terms of copyright but in trademarks and on Google's Android developer sites ?

Listen, you have to defend them. You cannot have freedom only for some people (open source or nothing). If Google, or anyone for that matter want's to create software who are we to critisize? We're not foced to use it. The Open source community should be left alone to inovate, and so should comercial industry.
Google, as far as I can tell, is not bent on a campaign of stamping out the competition. Google is not extorting licencing fees from unsuspecting users, Google's search engine does not pop-up in my Explorrer window every time I mis-type a URL or path.
I am not a google slappy-fan, I actually don't even have an Android phone, but having dealt with Oracle's products and their people, I really don't find much sympathy for them in any of their misfortunes

The whole point of APIs is vendor's try to provide a tool that locks developers into their technology. Saying that Google is closed while Oracle is open forgets that Oracle takes over companies just to force Oracle down the throats of their customers at an ever increasing price. Thinking that Oracle is not going to do that to Java is naive.

Does this API judgement mean we can clone O/S interfaces (kernel calls and libraries) with impunity?

Modulo of course, avoiding patented solutions in implementations.

<em>Does this API judgement mean we can clone O/S interfaces (kernel calls and libraries) with impunity?</em>

The decision includes it its motivation the fact that the "copied" API is that of a programming language, and that using the same API structure, calls, etc. (which are nevertheless implemented differently) is technically necessary for trying to achieve interoperability, .i.e.: writing Java programs that have a chance to work on both platforms, and that this is not a violation of copyright.

Extending this reasoning to OS interfaces requires a next step, but that is not such a big step IMHO.

It would be no problem if the API implemented did really perform the same thing, with the same security levels and paradigms. The Andoid version violate several of these paradigms, notably they don't throw the documented exceptions (they could throw derived exceptions), but often silently return a default value without signaling anything to the application. When exceptions are expected to check the security of some applicationso that the exception handler will give an alternate execution path that is expected and only capable to produce the correct result, or when applications are not prepared to receive siliently a NULL default value so that now they fail by generating fatal errors when attempting to reference them, this is a severe problem.

Given that these Android API are different, they should definitely not use the same class names (or should be in separate replacement packages, allowing then application developers to create support classes for either platforms and easier testing to be compatible to both oin a single unified code).

This is not possible. The Android implementation is not an independant implementation, it breaks all Java programming paradigms : write once, deploy everywhere, with an upward compatibility that the Java promissed.

And here it is definitely not a question of bugs (that could be identified, and should be corrected, allowing also the development of temporary workarounds if the platform is clearly identifiable, using a custom classloader that will solve or workround some known bugs in specific versions)

If Google had particopated to the normal developement of the Java platform, it would benefit from all bug corrections that will now affect both platforms independantly and that will add up to more bugs for all applications and all users. This is a loss of time, when everything was open on the Java platform (including for corrections that were documented in one place accessible to everyone).

The GNU classpath for example complies to the Java platform, even if it still does not support everything. It has its uses and limitations that are now documented in the JDK, and that also allows the Java platform to develop new standard libraries in upper layers that solve common problems that are hard to solve cleanly between the implementations. These addons then can be optimized and be prefered to solve all these problems, including using "hidden" workaround as part of their internal implementation, without affecting the blackbox API.

An in fact, most of the implementations that are now part of the standard JVM distributions have been contributed by the Java community, The decision to choose one impelmentation to another was a long process where each API was scrutinized with the best current practices and knowledges collected by the community (all these researches and developments are easily accessible to everyone, including the history : there's nothing like this in Android where its platform and its evolution is discussed secretely by a few mysterious people).

Hello Philippe,

I am not a Java programmer (I prefer other languages), so I can't comment on the problems you mention, and I am not discussing that they may be real technical issues for the Java programming community. I share with you the idea that if something is called "Java" it should behave as "Java" is supposed to. If it does not, it is a bug, or an implementation mistake, and not counterfeiting a copyright. Also note that it is much easier to do a consistent implementation, running everywhere in almost the same manner, avoiding much of the problems you mention, if you are the only one implementing something.

In relation to this news, and the intellectual property concerns it addresses, I believe this is a great decision and precedent created for open source projects, whether it is for implementing another Java, or any other programming language as free software.

There has been a similar decision recently in Europe by the Court of Justice of the European Union in Case C-406/10 SAS Institute Inc. v World Programming Ltd, 2 May 2012 about a programming language for statistical analysis.

http://curia.europa.eu/jcms/upload/docs/application/pdf/2012-05/cp120053...

And I can only be happy that such type of decisions are shared elsewhere in the world.

Reading the decision of the judge of the US District Court for Northern California, you can see that the court has made a real effort to understand what is a programming language, what is an API, in order to apply legal principles on what can be protected through copyright, and what can't.

That's a remarkable work that this American judge has done.

Java was cobbled together from existing technology. There was nothing new about when it came out. A close examination would show Oracle is vulnerable to the same accusations it is leveling.

Released under the Creative Commons CC0 1.0 Universal Public Domain Dedication.