This is one of those times when you have to wish, as Henry Kissinger famously did, that they could both lose. Google’s original pure-as-the-driven-snow exhortation “don’t be evil” has, well, drifted; it’s been the running rumor for at least 30 years that Larry Ellison is in fact a Romulan spy. And the current battle is just another campaign in the war over the Java programming language that has been going on practically since it was first released.
The core of the problem is that Sun Microsystems started with the altruistic notion that Java should be available to everyone, and work on all platforms — “Write once, run anywhere.” It started out with great promise and a technical basis that made it achievable. Sun, under CEO Scott McNealy, thought that if everyone was using a Sun language, Sun couldn’t help but profit.
I was one of the first people, outside the group at Sun that developed Java, to use the language, first at IBM and then at Sun itself, so I watched a lot of this from the inside.
“Write once, run anywhere” had one essential problem: to make it work, the core of Java had to be uniform. Any Java programmer anywhere had to be able to depend on the basic properties of the language, and Java was structured in such a way that part of those basic properties was a collection of libraries of useful code.
(If you’re not technically inclined, bear with me — I’m going to explain this in more detail eventually.)
This was in the days when Microsoft was the 800-pound gorilla, and as befits the 800-pound gorilla, it wanted control. Netscape was the preferred browser? Fine, create Internet Explorer and give it away for free. Nothing hurts a company’s market plans like your competitor giving away their product for free, and tying it so intimately with their platform that you couldn’t get rid of it. The Department of Justice called it “embrace, extend, and extinguish“: adopt a technology, start adding proprietary extensions, and push it into the market until your extended and proprietary version wipes out the original — and its originators.
Microsoft tried that with Java, but Sun fought back, and after the expenditure of millions of dollars in legal fees, Sun won the right to define what the Java language was, albeit with a “community process” and a more or less adequate open-source licensing scheme. Microsoft took its proprietary variant of Java and made some incompatible changes to yield what became the C# language, which is now a successful language, albeit almost exclusively on Microsoft Windows.
Java went on to become one of the most widely-used programming languages in the world, and while I have some criticisms of what Java has become, there’s no doubt it has been a success.
Why Did “Write Once, Run Anywhere” Matter?
The original use case for a “write once, run anywhere” language was for embedded commodity systems; the first idea was for Java (then called Oak) to be used for cable television set-top boxes. I was personally involved in pitching Java for automotive on-board computers.
The key for these sorts of applications is that you would expect to be selling millions, even tens or hundreds of millions, of products (how many cars and trucks sold in a year?). The economics of computer chips was such that comparative prices among different processors could be very volatile, and being able to flexibly choose to save a few pennies for the next production run could result in hundreds of thousands of dollars in savings.
What stood in the way of this was that these platforms were generally programmed in machine language using just an assembler — in other words, rather than writing in a programming language close to human language, the programs were written in a shorthand notation for the individual machine instructions, and those machine instructions were different depending on which particular processor you chose.
A short C program compared to its Assembler version
Changing processors would mean rewriting every line of the assembler code to suit the new chip, and that wasn’t feasible. With Java, only one smaller piece of code — the Java Virtual Machine, or JVM — needed to be written specifically for each processor.
The truth was that this never really was a major market for Java. For various reasons, small embedded computers didn’t use Java, and because of the utter dominance of what was called the IBM PC long after IBM got out of the business, a single family of processor chips with the INTEL 8086 as their common ancestor came to completely dominate the rest of the market. “Write once, run anywhere” was important not because of the differences among computer processors, but because there were several competing operating systems: Microsoft’s various versions of Windows, and several variants of UNIX. Java became the dominant language not of small embedded computers, but of large-scale business systems, and especially of business systems that run on the World Wide Web.
And Then Came Google
While all this was happening, a completely different market developed after Steve Jobs and Apple developed the iPhone. The iPhone was a “smartphone,” which meant that as well as providing the functions of a telephone it provided the functions of a full-function computer, complete with Graphical User Interface (GUI) and a collection of applications. Apple’s iPhone was programmed using Apple’s own proprietary tools, so developers were locked into their platform.
Google saw an opportunity there. Using the freely-available, open-source Linux operating system (a variant of UNIX developed starting with Linus Torvald’s Master’s thesis) Google decided to get into the smartphone market as well.
Suddenly, we were back in an environment where we were talking about manufacturing millions of commodity devices that weren’t locked into a single processor chip — the market characteristics for which Java was originally intended. Google also employed many of the original developers of Java. Java was a natural language on which to base Google’s smartphones, and the combination of a specialized version of Linux and the Java language was chosen as the basis of Google’s Android smartphones.
By then, Sun Microsystems (RIP), including the Java language and environment, had been acquired by Oracle. Google attempted to negotiate a license to use the Oracle implementation of Java in their phones, but Oracle as a company famously has a negotiating style roughly halfway between Genghis Khan and an outtake from the first draft of The Merchant of Venice. Google and Oracle could not come to terms.
Google decided, instead of licensing Oracle’s code, to reimplement that whole of the Java core language from scratch. Android phones came onto the market and quickly gained market share worldwide.
A lot of market share. Which meant a lot of money.
Lawyers, Guns, and Money. Or At Least Lawyers and Money
Oracle then filed suit. The claim was that Google was violating Oracle’s copyrights on Java by reimplementing the Java core because part of that reimplementation was necessarily the way the components of the reimplemented code was organized — the Application Programming Interface or API.
Strangely, this was almost exactly a mirror image of the legal battles between Sun Microsystems and Microsoft. Sun and Microsoft fought over whether Microsoft could call a language Java if it wasn’t compatible with Java as Sun defined it; Oracle and Google were now fighting over whether Google could implement its own version of Java that was 100 percent compatible with Oracle’s (nee Sun’s) vision of Java.
The culmination of that series of legal battles is now at the Supreme Court.
Understanding the Technical Issue
I’m not going to pretend to understand the copyright law involved. It’s “you are in a twisty maze of decisions, all different, and all modified by rent-seeking lobbying revisions. (This article at Volokh Conspiracy seems to do a good job on the legal issues.) But the technical issue here is much easier to understand.
Java is what’s called an object-oriented language. What this means, stated simply, is that the code is organized into packages that collect everything, both code and data, and these packages are then organized using a relationship called inheritance. Inheritance is a relationship that simply says “is a kind of.” A common example is to think about birds. A blue heron is a kind of heron, and herons are kinds of birds, so the “inheritance” relationship would be “Bird->Heron->Blue Heron”
In Java, as well as the basic syntax of the language, the language itself depends on a whole hierarchy of these packages, all organized around this “is a kind of” principle. These provide all the things you need to write a successful Java program — everything from being able to read or write data, to performing mathematical calculations more advanced than basic arithmetic, to more complicated functions like accessing a database or building a web site — all of them are provided by packages that are inherently part of the language.
These packages have names that reflect these inheritance relations. These are named by these relationships, from java.lang.Object, the most basic package, to low-level components like java.util.concurrent.atomic. This collection is known collectively as the Java API and described by the Java API Specification. (That link goes to the specification for the version 7 edition, which isn’t the most recent, but serves the purpose. You don’t need to explore it in detail for me to make the point.)
Now, those are just names, addresses, directions, like “take the train to 42nd street, walk to Fifth Avenue, take the elevator to the 11th floor and go to number 41.” The whole language is built around this hierarchical naming scheme, and you can’t make a Java program run without it.
And (finally) this is what the current lawsuit is about. Unless you can use these addresses to find the package you need, and unless the package actually operates as the API specification defines, you simply can’t write a Java program at all. The lawsuit that Google and Oracle have now taken all the way to the Supreme Court is over the question of whether Oracle holds copyright not just on the code that provides those functions, but on the names of the packages that allow a Java program to find the code. And while the lawsuit just asserts a copyright claim on those names, the effect will be to use copyright to make it impossible for anyone but Oracle to implement Java.
Oracle Imperils Own Foot
So we come back around to the original purpose of Java: to be able to write once and run anywhere. Oracle has been pushing toward making “modern” Java proprietary again anyway — changing the license terms so that companies must pay a license fee, and no longer providing security updates for the free versions. There is a parallel open-source OpenJDK effort, as well, but it’s unclear to me just how that works for a production system from a licensing standpoint.
As I emphasized earlier, I’m certainly not a lawyer, but some of the briefs seem pretty convincing — a mere addressing scheme, a system of organization, seems unlikely to be capable of copyright. Has Ellison let having more testosterone than money and more money than sense led him into a ten-year, terrifically expensive folly?
I suppose Oracle is rolling the dice — Google makes a lot of money from Android, and Larry Ellison wants some. If Oracle prevails in the Supreme Court, the final award will be in the billions of dollars. But Google has lots of money, and Android development is already moving away from Java toward Kotlin, another more modern object-oriented language that Oracle didn’t invent. What happens to the golden-egg goose if Google decides to move away from Java entirely?
And now many new projects are deciding that Java has gotten too complex and Oracle too unpredictable and moving to Go or Python or Rust or Javascript-on-the-server?
Honestly, I don’t see there’s a winning outcome for Ellison either way. It may be better for Ellison and Oracle — and probably for the rest of us — if they lose.