Could a lawsuit derail Android? Understanding Oracle’s threat to Google

oracle-android-hanging-in-effigy

The major patent and copyright infringement case between Google and Oracle over technology included in Android looks like it may be going to trial, just not anytime soon. Judge William Alsup issued his preliminary trial plan to both sides Wednesday, noting that the trial is not going to get started in 2011—and everyone involved had better get prepared for a long-drawn out proceeding rather than a quick summary trial. Judge Alsup outlined plans for a three-phase jury trial—phase one to cover copyright claims, phase two to cover patent claims, and a third phase for all remaining issues. The judge noted that the court needs lead time for prepare, and that includes jury selection and preparation for the lengthy disruptions jurors can expect to face. And still, no trial date has been set.

What’s at stake in the fight between Oracle and Google, and what impact could it have on the future of Android?

It’s all about Java

The crux of Oracle’s case against Google has to do with Java technology, which became Oracle’s property when it acquired Sun Microsystems back in early 2010. In the 1990s, Sun developed Java as a “write once, run anywhere” technology that was supposed to provide a way for developers to write applications for any platform (Windows, Mac, Linux, whatever) so long as those platforms had a Java virtual machine. In simple terms, a virtual machine is a software program that simulates a computer and operating system. Software for a virtual machine doesn’t need to know anything about the actual hardware it’s running on, so long as the virtual machine provides access to all necessary capabilities. Sun developed the original Java virtual machine, but more importantly, solidified the specifications for virtual machines that could run Java applications. Other people could, and did, make their own Java virtual machines, either based on Sun’s work or starting from scratch.

The appeal was obvious: Instead of having to write and maintain different versions of apps for every different platform, you’d write one app, and it’d run anywhere, thanks to Java.

The reality turned out a bit different. For one thing, Java apps almost always feel wrong on the desktop. They don’t follow the conventions of the host operating system, meaning users have to struggle to manage windows, controls, and even files. In the early days, Java apps performed slowly compared to native apps, thanks to the overhead of the virtual machines.

What’s more, the early days of Java were significantly muddied by Microsoft. Microsoft signed a licensing deal with Sun for Java technology, then proceeded to integrate its own changes into the Java language and virtual machine so it ran differently, and, in Microsoft’s view, better, on Windows. Eventually, apps for Microsoft’s version of Java didn’t run anywhere but on Windows. So much for write once, run anywhere. Sun sued (and eventually settled with) Microsoft to terminate the license agreement and prevent Microsoft from advertising their apps as Java-compatible, but the damage was done. By that point, many desktop app developers were significantly put off from Java technology, although there are exceptions like OpenOffice, which continues to rely on Java.

However, Java survived and actually thrived in two other areas: server applications and mobile. For server apps, the look and feel of a desktop application doesn’t matter: Users are only connecting to it with a Web browser, database client, or other front end that can be native to their platform. Making portions of the server-side code using Java enabled middleware and enterprise software developers to quickly deploy their systems to a number of platforms: Unix, Solaris, BSD — heck, even Windows. This server-side aspect was one of the main reasons Oracle was interested in acquiring Sun in the first place, since Oracle’s primarily business is enterprise software. Similarly, as mobile phones and other devices began to offer more significant processing power and memory, Java became a viable solution for bringing software to those devices. Sun designed the Java Platform, Micro Edition (or J2ME) specifically for things like phones, set-top boxes, and standalone devices, and it was a huge success. Some industry estimates place the number of mobile devices with J2ME over 2.5 billion, and although J2ME isn’t in today’s leading smartphones, it continues to roll out in Symbian and other devices worldwide.

How Java is (and isn’t) in Android

As Google worked to develop Android, it realized that if it wanted to foster a broad ecosystem of device makers, it needed to provide a way to effectively write code for Android devices that would work on a wide variety of possible architectures. That lead Google directly to the idea of virtual machines, and just as quickly to Java.

However, instead of licensing Java technology from Sun (this was all taking place before Oracle’s acquisition) Google decided to make its own virtual machine with characteristics useful to mobile devices: Dalvik. Google’s Dan Bornstein decided to start over from scratch, rather than starting from an existing Java VM. According to Google, Dalvik is a clean-room design of a Java virtual engine, created by reverse engineering the behavior of Java VMs without using any of Sun’s (now Oracle’s) copyrighted or patented technology. And, indeed, Dalvik exhibits several characteristics that make it distinct from other Java VMs. For one thing, it uses a register-based architecture rather than a stack design (meaning, it can run using fewer instructions with the tradeoff of somewhat larger code). Dalvik is also designed to run on resource-constrained mobile devices, and converts most Java class files to its own instruction set, which can then be further optimized on a device-by-device basis depending on profile information.

As Android got to market, Google offered an Android Native Development Kit that enabled developers to create Android software components using C and C++. Many developers use that native development kit for their apps (or parts of them), particularly for apps that can leverage multi-core processors, and high-performance game technologies. However, mainstream Android development using the standard Android SDK relies on Dalvik. In other words, with the exception of some device-specific apps and leading-edge games that only run on a handful of Android devices, the vast majority of Android software depends on the Dalvik engine.

Why Oracle wants a cut of Google’ cash

Oracle claims that, instead of being a wholly independent clean-room implementation of a Java VM, Google knowingly, repeatedly, and directly infringed on both copyrights and patents related to Java technology. In total, Oracle claimed Dalvik violates seven U.S. patents (numbers 6,125,447, 6,192,476, 5,966,702, 7,426,720, RE38,104, 6,910,205, and 6,061,520) as well as a series of copyright violations that includes literal file copying (totaling a dozen files, including eight that were decompiled) along with 37 instances of API specifications. The API specs are ways that programmers interact with the Dalvik virtual machine that are essentially identical to the way programmers would interact with Oracle’s Java platform.

lg-thrill-4g-frontThe case filings from both sides have been updated since the initial suit was filed, and Judge Alsup has issued preliminary rulings on motions from both sides. Oracle is currently seeking between $900 million and $1.4 billion for the patent infringement alone, and wants an additional 15 percent of mobile advertising revenues generated by the entire Android platform. Last year, Google said the mobile ad revenue generated from Android was worth about $1 billion a year, which would put Oracle in line for an additional $150 million a year, assuming Android experienced no market growth at all. Of course, Android has grown during the last year, which could make a 15 percent claim on Android ad revenues worth mammoth amounts of cash.

So far, Google has had almost no success getting Oracle’s copyright violation claims set aside before the case goes to trial. The judge has only agreed with Google that the names of classes, methods, and files aren’t copyrightable: All the rest of Oracle’s copyright violation claims stand.

Google has been seeing more success in its efforts to get Oracle’s patents ruled invalid. Oracle initially asserted 132 claims of violation against seven Java patents, and re-examination by the U.S. Patent and Trademark Office has, so far, whittled that down to 26. Of those 26, 11 are “mirrors,” meaning only 15 of the remaining claims are unique. The patent re-examination process is not complete, and final rulings on the validity of patents and whether they’ve been violated are notoriously divergent from initial rulings. (They also tend to be appealed and re-appealed over a period of years, making the process even longer.) However, even if all of Oracle’s existing claims don’t hold up, it seems likely that a few will. In particular, Google’s challenge to Oracle’s ‘520 patent seems likely to fail.

What happens to Android?

Google has indicated that it is willing to sit down with Oracle and try to work out a settlement, and the companies have had conferences to try to work out their differences. However, so far the companies don’t appear to be anywhere near an agreement.

In that sense, Judge Alsup’s decision to postpone a trial until 2012 is a victory for Google. The decision removes immediate pressure of a jury trial targeting both patent and copyright claims, and gives the patent re-examination process more time to run. The longer it takes the case to get to trial, the greater the chances that more of Oracle’s patent claims may be declared invalid before being presented to a jury.

However, a delay going to trial also lets Oracle’s legal action continue to linger as a cloud over the Android platform, which is already being encumbered by Microsoft playing hardball with Android licensees as well as Apple taking on HTC for patent infringement. (And let’s not forget: Steve Jobs now-famously called Android a “stolen product” and vowed to destroy it, although only time will tell if a post-Jobs Apple is still willing to go thermonuclear over Android.)

Google may tout Android as “free and open,” but if Oracle wins, it’s going to be paying Oracle for nearly every Android device on the market. Google could end up to making a large initial payment to Oracle to cover infringement up to the date of the ruling, then (worst case) handing over a significant chunk of the revenue it earns off the Android platform to Oracle in perpetuity.

Can Google change Android to dodge Oracle?

At a technical level, Google could, in theory, wiggle out of its battle with Oracle by stepping away from the Dalvik virtual machine. However, any version of Android without Dalvik would either:

  • require a new virtual machine compatible with Dalvik executable files, or
  • be incompatible with the vast majority of Android software.

Either option would entail a significant software development process at Google, and while we don’t know for sure, there’s no indication the company has started down either road.

The first option would essentially be Google’s second run at creating a Java virtual machine from scratch that didn’t infringe on Oracle copyrights. However, maintaining compatibility with Dalvik’s executables (so existing Android software could run) could well wind up infringing the same patents Google is fighting now. In other words, Google might wind up running very fast only to find itself in the same place.

The second option could get out from under Oracle’s patent and copyright hammer, but would make the fragmentation of today’s Android ecosystem look trivial. Today, most Android software works on a particular version of the platform (or newer), with some apps limited to specific devices or classes of devices. However, a version of Android that can’t run software built using Dalvik would leave the vast majority of existing Android software behind. That’s the same gamble Microsoft is taking with Windows 8 on ARM: It won’t run legacy x86 applications. Microsoft might be able to get away with spawning a new Metro-only ecosystem built around tablets and mobile devices, or may not. We don’t know yet. However, Google is unlikely to cut its existing Android platform off at the knees by announcing a forthcoming version of Android won’t be able to run most existing Android software, and Google’s partners are almost certainly not willing to let that happen. Google would be better off sunsetting Android and moving on to “Cyborg” or some all-new mobile OS.

In either scenario, Google can’t make previous and existing versions of Android disappear. If Google is found to have violated Oracle’s copyrights or patents, it will will be liable for damages and unjust profits gained from all the Android devices on the market today.

What can Google do?

At this stage, Google’s options seem to boil down to paying Oracle now, or paying Oracle later. For the moment, Google wants “later.”

If more of Oracle’s patent claims are invalidated, Oracle’s position gets weaker and Google can leverage that to negotiate for more favorable settlement terms. However, if significant portions of Oracle’s patent claims hold up, or the case goes to trial, it will likely be in Google’s interest to cut its losses as quickly as possible… and that will give Oracle the advantage.

It’s unlikely either company truly wants the case to go to a jury. Juries and open court proceedings are unpredictable, and while settlements can be quick, jury trials and appeals processes can draw proceedings out for years. Ultimately, Google doesn’t want Oracle looming over Android’s future any longer than necessary.

Editors' Recommendations