The Android Case

Google set off a hell of a chain of events this week. The trigger was the announcement of the Android platform under the auspices of The Open Handset Alliance. Android is interesting technically, but especially because it takes an unprecedented approach to Java that could split the platform itself. Let’s look at the Android case from all sides.

The technical side

Android is an open-source stack for running applications aimed at mobile devices. It has three basic layers: an operating system, middleware for running applications, and core system applications.

Archive image in The Android Case, figure 1

The foundation is version 2.6 of the Linux kernel. I hope it runs better on that mobile hardware than on my laptop. ;-) It provides the layer for accessing hardware.
On top of the kernel sits a wall of C libraries providing basic services and interfaces to higher layers. The basic services include a 2D and 3D library with acceleration support, an embedded relational database, a web browser, and a library for working with audio and video formats. Next to them is the runtime, a virtual machine and a set of basic system APIs.
One floor up is the application framework, which provides basic APIs for things like building a user interface or sharing data among applications. It can also serve as a service registry, where individual services register so others can use them.
At the very top are the core applications, such as an email client, a map, and contacts.

So far we’ve talked in abstract terms about APIs, libraries and a virtual machine. Let’s look more closely. The virtual machine is called Dalvik and is specifically tuned for mobile devices with the smallest possible memory footprint in mind. Every application runs in its own process in its own VM instance. All the blue boxes in the diagram are written in a language that is compiled into an intermediate format for the VM to interpret.

The political side

A note: I’m not a lawyer.

An alert reader will have noticed the parallel with the Java programming language and the Java Virtual Machine, or JVM. But Android is neither Java nor a JVM, nor is it J2ME or J2SE. The reason is simple: Android’s license. Apart from the kernel, which uses GPL v2, Android is released under the Apache Software License, or ASL. That’s the sticking point.

The key parts that might have been used from the Java platform are all under GPL v2. Sun knows what it’s doing. Mobile devices are one of the few areas where Java makes it money, so it made sense to keep certain things under control. But Google found a clever way around it. It has Dalvik VM in place of a JVM. Dalvik handles the Dalvik Executable format (.dex), a slightly modified form of the bytecode produced by a standard Java compiler.

Developers therefore write code in an ordinary Java development environment. Before running the application on Android, they call a special converter to turn the bytecode into Dalvik format. Another interesting point is that the core Android API contains classes familiar to any Java developer, such as java.lang.Object. Take a closer look and you’ll find that some libraries are missing, including the GUI libraries Swing and AWT.

It’s worth asking how Android can take the Java API, pull out what it needs and put it under another license. It can do so because of the classpath exception to the Core API. The exception exists so programs using this API don’t have to be released under GPL v2 and so other open-source implementations of Java can use another kind of open-source license.

Roumen’s interpretation:

But Google doesn’t use Sun’s code at all. It uses code from the Harmony project, so it doesn’t matter what license Sun’s Java SE or Java ME API source code is under. Also, the classpath exception only means that applications using OpenJDK don’t have to be licensed under GPL v2. It doesn’t allow Java implementations derived from OpenJDK to choose a license. In fact, Java implementations derived from OpenJDK MUST be licensed under GPL v2.

In other words, Google has no right to take Sun’s Java API, extract what it wants and publish it under a different license, as you say. It can certainly use the Harmony project’s code if it keeps the license, which it did. The classpath exception doesn’t exist to allow Java implementations under another type of open-source license. Java implementations under other open-source licenses existed long before OpenJDK was licensed under GPL v2 with the classpath exception, including Harmony and GCJ. No license can prevent this, although other protections apply: copyright for the source so nobody copies Sun’s code, trademarks for the Java name and logo, and patents on individual principles. Sun doesn’t abuse those patents as a matter of principle and merely collects them to defend itself against litigious companies. Other implementations that aren’t based on OpenJDK can’t call themselves “Java” because of the trademark. That’s why Google isn’t entitled to use the trademark for Android. OpenJDK allows derivatives only under GPL v2, and the classpath exception has nothing to do with other Java implementations.

That’s exactly what Google took advantage of. It used the source from the Harmonyproject, already under the ASL, instead of Sun’s original source. It’s interesting to ask why Google chose the ASL for Android. Google probably decided the ASL makes it easy to mix open- and closed-source projects. The following article discusses that in some detail: Why Google chose the Apache Software License over GPLv2 for Android.

The social side

Android took only what suited it from Java: the syntax and part of the API. That could set a dangerous precedent. History could repeat itself, as with Microsoft’s Java, and we could end up with something that looks like Java but really isn’t. It would be bad if Java split. With Android, there’s a particular danger because of its potential reach across a huge share of mobile devices. It will be interesting to see how Sun responds. So far it hasn’t made an official statement.

The technical side

The political side

The social side

Related articles

Related CZ Podcast episodes