Saturday, August 21, 2010

The complete story behind Oracle vs Google

The blogosphere has been actively dissecting Oracle's lawsuit against Google. And for the most part, Google is coming across as a champion of Open Source, whereas Oracle is being painted as the villain. In fact some websites have even compared Oracle's lawsuit against Google to be similar to SCO's lawsuit against Linux.

However, there is a very very important point that has been lost in all the confusion. While today Google looks like the hurt party and Oracle looks like the aggressor in the eyes of the Open Source Community, I think over time, as the dust settles, Oracle will turn out to be the friend of the Open Source Community.

The real issue behind this suit, and something almost no one has looked at so far, is the legal enforceablity of the GPL. The GPL - or GNU public license, is the foundation of the entire Open Source movement. This is what ensures that coders at large can contribute to a project publicly, and still be assured that no private party can take advantage of the public nature of the project by extending it in a proprietary manner. For instance, if thousands of developers spend time and energy on improving Linux, and someone adds a few extra features to Linux and sells it (without contributing those features back to the open source community), then the entire Open Source movement would be destroyed. It would be easy for someone to add a few extra features to an Open Source project, and sell it as a proprietary project - taking advantage, without making any contributions. To protect against this, the GPL insists that any derivative work that is built upon a GPL project must also be contributed back to the public domain.

The GPL is only one of the licensing mechanisms available in the Open Source community. The other popular ones are LGPL or the Limited GNU Public License, and the Apache License. Apache license is the most flexible license, allowing proprietary extensions, with no requirement to contribute these extensions back to the Open Source community. LGPL is somewhere in between the Apache license and the GPL license.

It is upto each Open Source project to decide whether to go public under the GPL, the LGPL or the Apache License. Anyone who uses an Open Source project implicitly and explicitly agrees to abide by the terms of the license governing that project.

Linux has been released under the GPL license. This is the reason why RedHat is expected to release all their work done with Linux back to the OpenSource community. And this is the reason CentOS can quickly be compiled to offer binary level compatibility with RedHat Linux, for free. RedHat effectively can only charge money for Support and Services, because the exact same copy of the software is available as CentOS.

Because of these differences between the various licenses, there are also software projects, where different versions of the projects can be used with different licenses. For instance, Java offers a Free Open Source license under the GPL, together with a license SOLD by Sun to whoever does not wish to use the GPL. This is not a deviation from the concept of Open Source - it is one of the pillars of the concept of Open Source.

When it comes to regular JAVA, Sun released it under the GPL, with something called a CLASSPATH exception. That means, All changes to the Java Virtual Machine, the Java Programming language, etc would have to be contributed back to the Open Source community, whereas external modules that execute in the virtual machine by virtue of being available on the CLASSPATH can be retained as proprietary code. For mobile Java however, this CLASSPATH exception was not mentioned, so it was released under the full GPL. The objective was not to ask private app developers to contribute their code to the Open Source community, but to ensure that any changes to vital parts of the mobile device would have to be contributed back to the Open Source community. So any changes like a different dialer, or Messaging system, etc would have to be contributed back to the Open Source community.

For whatever reasons, Google chose not to go with the GPL verion - and because they were not making any money from Android, they could also not go ahead with a paid license from Sun. Also, Sun's implementation of the Virtual Machine was not ideal for a mobile environment. So Google came up with DALVIK - a new virtual machine specifically for Android. DALVIK would effectively run Java code, in a different virtual machine, with slight modifications. These modifications meant that SWING, and other Java libraries would not be available under Android. Any Java projects that did not use SWING, and the other non-supported libraries could easily be converted to the DEX format, but all Java classes that needed functionality from SWING that was not supported in DALVIK could not be executed. This issue per se was not a big issue, because even if SWING and other modules were not included in Android by default, they could have been added on later by the user. So this per se was not a deal breaker in terms of compliance with the Java licensing options.

In addition to this, the DALVIK VM was different from the JAVA VM in other ways. Under Java, multiple copies of the VM would be run as multiple processes - whereas, under DALVIK, multiple copies of the VM could be run as multiple threads (this is a simple explanation - the actual details are more complicated than just threads vs processes). Those who are familiar with processes and threads are aware that threads are a lot more efficient compared to processes. Under a regular desktop environment, this difference in efficiency would not have been required, but under the constraints of a mobile device, this difference in efficiency would make a massive difference. Under GPL, Google would have been required to contribute this change back to Java, but because they did not go with the GPL, they had no requirement to do so. If this was the only issue, Google can even now comply with the terms of the GPL, or even get a paid license from Sun/Oracle. However, there are other issues because of which the simple options are not available any more.

DALVIK had another important change compared to the Java VM - and that was that DALVIK allowed applications to use Registers. The Java VM on the other hand could not allow usage of the registers - because for Java, the Write-Once-Run-Anywhere paradigm was paramount. Since Register architecture and availability varies significantly from one platform to the other, the Java VM abstracted Registers - so that code written on one platform could execute exactly the same in any platform. It is this feature of DALVIK that is the deal breaker - there is no way Sun would have allowed Android to break the Write-Once-Run-Anywhere paradigm.

Years ago, Microsoft got a license from Sun to create a JVM, and but they violated the terms of the license by creating the Java Native Interface - which was a mechanism for Java applications to get a performance boost by directly accessing Windows SDK underneath. However, JNI was a Windows-only implementation, and violated the Write-Once-Run-Anywhere paradigm. It is this violation that forced Sun to go after Microsoft, and which forced Microsoft to cough up a billion dollars in damages.

So there is absolutely no way Sun would allow Google/Android to compromise Java in such a manner. It is this violation that prevents Google from coming to a settlement with Oracle even today. And it is likely that it is this issue that could be the reason why Google ultimately loses this lawsuit. I think there is sufficient documentation at Google that would come out in the discovery process, which would make it abundantly clear that Google was well aware of all these issues, and still chose to do what it did, because that was the only way to get Android applications up to a level of performance where it would be viable.

Google had 2 choices - either not use Java at all, and come up with a totally new development environment, or to modify Java in a way that was not allowed under the existing Java licenses to make it a viable choice for the development environment. Google has absolutely no experience in platform creation - so the first option was not an easy one. They chose to go with the second option. This has now come back to hurt them.

The only real defence option that Google could have had, was that DALVIK was a clean room implementation, and did not use anything at all from Java. However, even this option is not really available, because there are far too many ex-Sun employees in the Android project who would definitely have had in depth knowledge of everything related to Java.

With the background now clear, there are some more things to be cleared up. Is Oracle the villain as the Open Source community paints them to be, or is Google the villain. I think the best way to understand this, is using a hypothetical analogy. Assume Red Hat violates the terms of the Linux GPL, and makes some proprietary changes to the Linux Kernel which are not contributed back to the Open Source community. Would the Open Source community be ok with this violation of the GPL? Or, lets take another example that would be even more realistic. Apple took an Open Source project called WebKit, and adopted it as the engine for Safari. Over time, Apple has contributed so much to the project that it has come to be seen almost as Apple's WebKit. 3 years back, when Mobile Safari was launched, it was dramatically different from all the other mobile browsers - what if Apple had decided back then that the changes in WebKit that made Mobile Safari possible gave Apple a tremendous headstart, and it would be advantageous to not contribute those changes back to the WebKit project. The entire OpenSource community would have cried that Apple took advantage of Open Source developers contributions without adhering to the licensing terms. Google has done something very similar with Java, and in addition, they have tremendously hurt Java as a platform.

Will Oracle be able to win this case in court? In my opinion, the answer is an emphatic yes. In fact, Google does not even have a leg to stand on, in this case. They cannot use a clean room defence, they cannot claim that DALVIK is sufficiently different from Java that the suit has no merit, they cannot claim that this was not intentional, they cannot claim that they did not know this would harm the Java platform.

If Google does lose, what are the implications. The monetary damages alone would be stunning. Back in the late 1990's, when Sun fought against Microsoft, they managed to get a billion dollar payout. However, we have to remember that Java not just survived but thrived after the Microsoft case got resolved. The situation now is completely the opposite - after the launch of Android, Java has been sidelined completely from the Mobile space. Effectively, Android was the death knell for Java. With this background, I am certain that Google will be looking at a figure way higher than what Microsoft faced. In fact, the facts of the case are so completely against Google that I would be surprised if this case even came up in court.

But despite however high the monetary damages are, it will be the non-monetary damages that would hurt Google even more. Android just cannot afford this kind of confusion at this point in its lifecycle. Already, Android is finding it difficult to compete with iOS for developer interest, because the Android user base is not ready to pay for apps and piracy is a big problem in the Android Marketplace, because it is not a curated store.

If Google does lose, it faces several nasty scenarios. They could be forced to remove DALVIK from Android and come up with a brand new development framework. Or they could be asked to pay a licensing fee for every installation of Android - which would be painful, especially considering they are giving away Android for free. Considering Windows Phone 7 is going to be launched soon, this sort of confusion is the last thing Google wanted. Microsoft could turn out to be a beneficiary of Oracle's attack on Google. Apple would also benefit because the iOS platform would look even more attractive to developers and consumers.

In more ways than one, it looks like Android is turning out to be a massive mistake for Google. Android ended up preventing Google from selling targeted ads for the iOS platform, and now this!

No comments: