Oracle v. Google

Android, Java, and the tech behind Oracle v. Google (FAQ)

Wondering what the lawyers and programmers are talking about in the highest-profile tech trial in years? Here's a guide to the ties between Android and Java -- and the history leading up to the case.

Sun Microsystems' years-long effort to profit from Java has come to this: the chief executives of two of tech's most powerful companies, Oracle and Google, being grilled in court.

Scrapping over copyrights, patents, and licensing deals is an ignominious outcome for a technology that a decade and a half ago spooked Microsoft and seemed poised to inject dynamism into a largely static Web. Back when it debuted, Java was a brand that carried impressive power.

Though Java has been technologically influential, its brand clout with the average person has diminished as other software such as Apple's iOS and cloud computing rose to prominence. So now probably is a good time to dig into some of the details on which Oracle's case hinges.

What is Java?
Java -- invented at Sun in the early 1990s and absorbed into Oracle with Oracle's Sun acquisition in 2010 -- is several things.

First, it's a programming language -- a carefully defined way of issuing instructions to get a computer to do something useful.

Second, Java comes with software called a virtual machine that runs programs written in Java. The Java virtual machine (JVM) looks to Java programs like a real computer, but it's really a layer that hands off instructions to the lower-level operating system actually running on some computing hardware. By building JVMs tailored for a variety of computers, the same Java program can at least theoretically run on both a Mac and a Windows computer. Thus Java's initial tagline: "write once, run anywhere."

Third, Java includes pre-written code called class libraries that does all manner of work -- everything from cryptography to communicating using Bluetooth. A Java programmer wanting to tap into this prefab power does so through a carefully defined mechanism called an application programming interfaces, or API. A sizable collection of companies define these APIs for Java.

Collectively, these three components are collectively called a Java runtime environment, or JRE, and it's what you need on your computer to run Java software. To be able to slap a Java logo on a particular device, it has to pass tests to ensure it runs Java programs correctly.

Well, that sounds simple enough
Guess again. Java quickly gets more complicated than that.

There are different varieties for different uses. The initial Java Standard Edition was geared for personal computers. It was joined by the Enterprise Edition, which defined APIs for server tasks such as managing databases, and the Micro Edition, which defined APIs for mobile tasks such as sending text messages on a phone.

And it got even more complicated: the Micro Edition had different varieties: the Connected Limited Device Configuration, the Personal Profile Specification, the Mobile Information Device Profile, the Mobile Information Device Profile 2.0, and more.

The upshot was that programmers couldn't necessarily predict what APIs a particular device would support. Would a phone allow accelerated 2D graphics through Java? How about 3D graphics? That's important to know if you're writing a game. The lack of consistency led to the mocking tagline of "write once, test everywhere."

A last gasp came in the form of JavaFX, which aimed to sweep away the muddle with a prepackaged software foundation from Oracle. But as it was arriving, another force attracted mobile programmer attention instead: Apple's iOS.

How does Android fit into this?
For all Java's shortcomings on mobile phones, Sun and Java allies such as Motorola had done a lot of work crafting technology suited to the market. And its cross-platform advantages held appeal for anyone hoping to build a broad new mobile ecosystem.

Thus, when Google and its allies were in search of a programming foundation for Android -- something that could span a range of devices -- Java was a natural place to start. Indeed, in 2005, that was the plan, for several reasons.

In addition to the technology itself, there were many Java programmers, meaning that developers aiming for Android wouldn't have to start from scratch. And embracing Java would stick it to Microsoft, the original competitor Google had in mind for its mobile operating system.

But Java came with strings attached.

What strings? I thought Java is open-source software?
Open-source software grants lots of liberties, but it doesn't necessarily mean somebody can do whatever he wants with it.

Sun picked the GNU General Public License for OpenJDK, the open-source version of Java Standard Edition project and what it called PhoneME, the open-source version of Java Micro Edition. But there was a subtle but important difference between the two projects.

For OpenJDK, Sun supplemented the GPL with what's called the "classpath exception" for class library code. That exception bypassed a key GPL requirement that a project derived from a GPL-governed project also be governed by the GPL. With the classpath exception, programmers didn't need to worry that using the GPL-governed libraries would "infect" their software, requiring them to release it under the GPL, too.

But PhoneME lacked the classpath exception. "The reason we have chosen not to add the classpath exception to Java ME is simply because Java ME applications are typically not shipped in a bundle together with the platform implementation and therefore an explicit classpath exception is not needed," Sun's Terrence Barr said of the decision.

That may or may not have been a typical situation, but it's exactly what happens with Android -- and Google didn't like it. The company wanted an open-source project, but one that others could modify as they saw fit, including with their own proprietary software. That could include anything from a user interface to a video decoding package to a custom keyboard.

"We are building a platform where the entire purpose is to let people differentiate on top of it," said Android chief Andy Rubin in an August 11, 2007, e-mail that Oracle is touting in its case against Google (PDF). "Sun chose GPL for this exact reason so that companies would need to come back to them and take a direct license and pay royalties."

So what did Google do?
It liberally borrowed technology from Sun's Java -- including the programming language itself, the syntax of many of the APIs that Java programs call upon, and the virtual machine approach.

But it also did things differently. For one thing, it built its own virtual machine, called Dalvik. For another, it drew upon another open-source Java project called Harmony for Android's class libraries. Harmony, whose backers included IBM, is governed by the Apache License -- Google's favored open-source license and one that lets people mix open-source and proprietary software without consequence.

Sun squawked about Google's Java-esque but not exactly Java move, but Google didn't budge. And it made it clear it wasn't going to try to label anything with the official Java brand. If nothing else, it seems unlikely that Google would have been able to accomplish what Harmony couldn't: to persuade Sun to grant use of the Java Technology Compatibility Kit (TCK) that would guarantee Java programs worked properly.

In essence, Google sidestepped Sun -- and by the way managed to build its Java knock-off into the stunningly successful foundation for smartphone programs that Sun only dreamed of.

Oracle argues that Google should have paid a license for Java and that it's damaged Java by fragmenting it into an incompatible version. That undermines the write-once, run-anywhere promise and devalues Java, Oracle argues. As a motivational stick, it's asserting Google violated both patents and copyrights.

Google clearly considered a range of licensing options, judging by many e-mails introduced as evidence (PDF), and indeed even kicked around one dramatic possibility in 2009: "Google buys the rights to Java from Sun (patents, copyrights, etc.)," perhaps for $100 million to $500 million.

But the companies couldn't come to terms. Thus, Oracle CEO Larry Ellison and Google CEO Larry Page were called as witnesses.

To make its case, Oracle has a number of arguments. One is that Google copied actual source code in the case of a Java function called RangeCheck. Joshua Bloch, a Google programmer who formerly worked for Sun, had this to say about the function, part of Android's TimSort library:

The class libraries enter more broadly with Oracle's claim that the APIs themselves used to access those libraries are copyrighted.

Oracle argues that the APIs aren't merely gateways to pre-written code, but actually a work unto themselves. The APIs collectively are carefully designed to work properly together, and the design of an individual API and its corresponding class library are essentially two sides of the same coin.

For its part, Google argues that its libraries are indeed different -- a "clean-room implementation," in computing industry jargon, meaning that the code was written without reference to the original whose abilities it's reproducing. Of the RangeCheck example, Google points out that it's only 9 lines of code among 924 in the larger file and among 15 million in Android overall.

Oracle also is gunning for Google on patents. It originally asserted Google infringed on seven, but five of them were thrown out, so now it's down to two.

Software copyright is complicated, API copyright is uncharted water, and patents are a thorny business for any industry. The jurors in the U.S. District Court in San Francisco will have plenty of work to do.


more @ http://news.cnet.com/8301-1001_3-57417144-92/android-java-and-the-tech-behind-oracle-v-google-faq/?tag=mncol;topStories