Tags: Google »»»» Oracle »»»» Sun Microsystems »»»» Java »»»» Fair Use »»»» Java SE »»»» Copyright »»»» US Supreme Court
Today, the US Supreme Court settled, in Google's favor, an important part of the long-running lawsuit between Oracle and Google over the latter's use of the Java SE API in Android. The ruling determined that while indeed Oracle had a valid copyright over the Java API, that Google's use of that API falls under Fair Use. The result negates Oracle's ability to win damages from Google, but more importantly validates programmers freedom to reuse API definitions. An Oracle win in this case would have had a chilling effect on programmer freedom.
The case dates back 15 years ago, to decisions made when Sun Microsystems still existed. In 2005, Google acquired the Android platform and set about making it a top-notch platform for developing smart phones. In 2007, Apple introduced the iPhone, causing Google to do a deep rethink of Android, which is not important to todays discussion. Instead, our focus has to be that Android implemented the Java SE API, on a mobile device, but did not get a Java license from Sun Microsystems.
Oracle's lawsuit against Google made claims that Android infringed both patents and copyrights owned by Oracle. The real point, of course, is that Google is not paying license fee's to Oracle.
Today's ruling settles a 10+ year lawsuit in Google's favor. But even more importantly, the Supreme Court decision strongly supports the act of duplicating an API under the Fair Use doctrine. Software engineers frequently implement the API of a 3rd party product -- I've done this twice in my career -- and it would have been very chilling to the software industry had Oracle won this lawsuit.
Applying fair use to reimplement an API starts with a separation between API method definitions and the implementation. According to the Supreme Court decision in the Oracle versus Google case, duplicating API definitions is fair use, and duplicating the implementation code is not fair use.
As a former insider to the Java SE team, with over 10 years working in that team, I have more than a few opinions about this case. The first of which is - what in the bleeping heck was Oracle thinking? I don't remember Google ever making claims that Android is Java Compatible. I remember, when Google first announced Android, carefully going over their website and noting that they carefully did not use the Java trademarks. There is a fine line of distinction about this because the tool Sun Microsystems used to enforce Java Compatibility was to control use of the Java trademarks.
Compatibility with Java, and using the Java Trademarks
Over the years there have been several software platforms that supported running Java code, but which were not certified as Java Compatible. That was always fine, so long as there were no claims made of Java Compatibility, and no use of the Java Trademarks.
Sun Microsystems always intended there to be multiple compatible Java implementations from multiple vendors. The implementations were not required to use the source code supplied by Sun Microsystems. Instead, the technical measure of compatibility was whether the Java implementation passed the relevant Java TCK's. The TCK's are the conformance tests which carefully check each API method, each interface, to verify compatibility with the specification.
Once a Java implementation passes the TCK, and once the implementor signs the license agreement, the implementor was free to use the Java trademarks, and free to claim Java compatibility.
In other words, Sun enforced the Java ecosystem by controlling use of the trademarks. Any organization was free to develop software that implemented the Java API's. The only time Sun Microsystems cared is if that organization used the Java trademarks on an incompatible implementation.
This even applied to the OpenJDK, the open source software project from which the official Java SE builds is created. Different parts of the OpenJDK are licensed under either the GPLv2 or GPLv2 with a linking exception developed by the Classpath Project. But, look carefully at all material related to the OpenJDK project, and you'll find nowhere are the Java trademarks used, and nowhere does it claim Java compatibility.
The OpenJDK is a software project from which a compatible Java implementation can be built. The OpenJDK is used by many 3rd party companies, for example packages are available through Linux package management systems. But if the 3rd party company wants to use the Java trademarks, it must pass the TCK on their build, and sign the license agreement.
Android and the Open Source Model
In the Supreme Court opinion, it is described that Google envisioned Android as a fully open source platform that any developer could use. That would incentivize more device developers to use Android, ensuring a large ecosystem of Android products. Indeed, that's been the result. Android used the Java programming language, and the Java SE API's, because of developer familiarity with those tools.
In August 2010, Oracle filed a lawsuit against Google claiming infringement of patents and copyrights. Remember that Oracle purchased the assets of Sun Microsystems in mid-2009, after Sun vaporized in the midst of the 2009 financial crisis.
It's worth pondering what choices the Android could have made. They could have developed a new programming language, new compiler tools, new class libraries, and so forth. That would have ensured no possibility of copyright infringement. But, the Android team chose the existing language.
Next, the Android team could have licensed Java SE from Sun Microsystems. The Supreme Court opinion describes how Google did start discussions with Sun Microsystems, but the negotiations failed because of Sun's "interoperability model." An Android founder, probably Andy Rubin, is quoted saying: "[t]he whole idea about open source is to have very, very few restrictions on what people can do with it." There are two possible meanings to that statement:
- There is another aspect to Android which can never be Java SE compatible. That's the use of the Dalvik virtual machine. The Java SE TCK tests whether the virtual machine is compatible. What I understand about Dalvik is that it cannot be a Java SE compatible virtual machine.
- The requirement to pass the TCK and sign license agreements with Sun Microsystems or Oracle would place unacceptable limitations on the developers Google was courting to use Android in their products.
Google's plan to successfully build a large Android ecosystem involved developers having full freedom to reuse Android for anything. Sun's licensing system around Java was designed with two purposes, the first being to ensure compatibility from one Java implementation to another. The second was ensuring the flow of license payments. The two sets of business goals were probably the core incompatibility between Google and Sun.
And, of course, the Open Source model relies on eliminating restrictions on reuse. I remember a Classpath Project member explaining to me an example, that if a software license had a clause prohibiting use in nuclear weapons development, that would be a field of use restriction. We can easily imagine an altruistically minded software developer aghast at nuclear weapons putting such a restriction into the software license, but that would prohibit it from being an open source license.
But, let's get back to the Google versus Oracle case which claimed that Google violated both patents and copyrights.
According to the Supreme Court filing, after a six week trial in court, a jury rejected Oracle's patent claims, and it found limited copyright infringement. Oracle later dropped the patent claims from the case. The jury was deadlocked over whether Google's use of Java SE amounted to fair use.
The latter point is very important to all software developers of all programming platforms. The Supreme Court decision goes on for many pages describing the fine distinction between the API definition, and the code implementing the API.
To understand what that means the Court asks us to consider a method call on java.lang.Math.max. This method takes two integers, and determines the larger of the two. There is a formal definition of the API in the Java SE source code. That definition is of two parts, one being the textual description of the behavior, the arguments to the method, the results, and any exceptions that might be thrown. There is also an implementation in the Java SE source code.
Reimplementing API's developed by others
Every software development platform has a long list of API methods or functions. The platform documentation will describe each method/function or other interface to the platform. Therefore it's possible for a 3rd party to independently implement that API based on the documentation, and sometimes software engineers are tasked with doing exactly that.
For example, before working in the Java SE team at Sun Microsystems, I worked for Mainsoft. Mainsoft's primary product in the mid 1990's, MainWin, was an implementation of the WIN32 and MFC API's for Unix/X11 systems. With MainWin, software developers could recompile their Windows applications on Unix to reach new markets. A number of large applications, like CAD systems, ran on Unix using MainWin. The initial versions of MainWin were a clean-room WIN32 implementation based solely on reading the documentation. We got a long way with that implementation, but by 1996 we had licensed the Windows source code and had started integrating some of Windows into MainWin.
The point is that sort of story happens all the time in the software industry. For example there are open source implementations of parts of the AWS platform, and many other software products.
How can Fair Use be applied to software platforms
The Supreme Court opinion described the Fair Use doctrine as a tool for fostering creativity. Specifically, the question is whether a work that in part copies another is adding something new, or whether the new thing is transformative. For example, when Andy Warhol created paintings of Campbell Soup cans, the court ruled that "parody can be transformative because comments on the original or criticizes it," and that "parody needs to mimic an original to make its point." The last two sentences of this article are also an example of fair use, because snippets from the Supreme Court ruling were quoted here to serve the commentary written in this article.
In Android, Google copied parts of the Java SE API precisely. It did that so that Java programmers could easily transition to writing Android applications. One aspect the Court describes as transformative is that Android brings the Java SE API to a new niche, that of smart phones and other limited power mobile devices.
The quantity of code Google copied is large, but that was a tiny fraction of the entire Java SE sources. Let's take a trivial example that the Court held up as its example, the implementation of the java.lang.Math.max method.
We can check out the OpenJDK source tree:
$ git clone https://github.com/openjdk/jdk.git
Cloning into 'jdk'...
remote: Enumerating objects: 1276, done.
remote: Counting objects: 100% (1276/1276), done.
remote: Compressing objects: 100% (685/685), done.
remote: Total 1150945 (delta 673), reused 926 (delta 544), pack-reused 1149669
Receiving objects: 100% (1150945/1150945), 910.53 MiB | 2.38 MiB/s, done.
Resolving deltas: 100% (863702/863702), done.
Updating files: 100% (67014/67014), done.
Then, inside that directory the corresponding source file is this:
$ ls src/java.base/share/classes/java/lang/Math.java
src/java.base/share/classes/java/lang/Math.java
Then inside that source file you'll find this method implementation:
package java.lang;
public final class Math {
...
@IntrinsicCandidate
public static int max(int a, int b) {
return (a >= b) ? a : b;
}
...
}
The Court drew a distinction between the declaring and the implementing code. The implementation in this case, return (a >= b) ? a : b;, is trivial and is the obvious implementation.
The package statement says this code is part of the java.lang package, and the public final class statement says this code defines the java.lang.Math class. Then within this class is a method defined with this signature:
@IntrinsicCandidate public static int max(int a, int b);
What Google copied was the structure of source files, package definitions, class definitions, and method definitions. The method implementations were not copied, only the definitions.
Summary
Google duplicated the package, class, and method definitions, of the Java SE platform. Android developers then created an implementation that ran so well on mobile devices that the Android ecosystem is a significant challenge to Apple's iPhone ecosystem. Good on them.
