Oracle v Google, redux, redux

It's that time again.

The third round of the gigantic lawsuit between two of the largest corporations in the world over control of the Java programming language is underway here in San Francisco: Oracle America, Inc. v. Google, Inc.

Oracle America, Inc. v. Google, Inc. is a dispute related to Oracle's copyright and patent claims on Google's Android operating system. In May 2012, the jury in this case found that Google did not infringe on Oracle's patents, and the trial judge ruled that the structure of the Java APIs used by Google was not copyrightable. The parties agreed to zero dollars in statutory damages for a small amount of copied code. On May 9, 2014, the Federal Circuit partially reversed the district court ruling, ruling in Oracle's favor on the copyrightability issue, and remanding the issue of fair use to the district court. A petition for certiorari was denied by the United States Supreme Court on June 29, 2015. A second trial is scheduled for May 9th, 2016, in which Oracle is seeking $8.8B in damages.

Ugh, that's pretty dry.

So why do I find it so interesting?

Well, one reason is that it involves a lot of Silicon Valley corporate leaders, including a number of companies which I myself worked for, over the years: Oracle’s Suit Against Google Digs Up Old Bones

Java was a programming breakthrough, just as browsing the World Wide Web was becoming mainstream. The Java motto at the time — "Write once, run anywhere" — while always a bit of an exaggeration, pointed to the importance that software created by anyone working on anything could have. Without that notion, the Web would not work.

Sun, founded years earlier and best known for its powerful workstation computers, became one of the most influential companies of the first dot-com boom.

And those companies have a lot of history: Oracle vs. Google, Round 2: Trial begins over Java API copyright claim

A decade ago, Android developers built their OS with the help of Java APIs, which were developed by Sun Microsystems in the 1990s. When Google decided to base Android on Java, it began licensing negotiations with Sun but ultimately abandoned them. After Oracle acquired Sun in 2010, it sued Google for using the APIs without paying licensing fees. Google argued they were free to use because the Java programming language is open source, and the APIs are required to use the language.

Another reason is that the various industry titans who are being called to the stand are so wonderfully eccentric:

• In Oracle v. Google, a Nerd Subculture Is on Trial

  Eric Schmidt sought to describe APIs and languages using power plugs as an analogy. Jonathan Schwartz tried his hand at explaining with "breakfast menus," only to have Judge William Alsup respond witheringly, "I don't know what the witness just said. The thing about the breakfast menu makes no sense."

  Schwartz’s second attempt at the breakfast menu analogy went much better, as he explained that although two different restaurants could have hamburgers on the menu, the actual hamburgers themselves were different—the terms on the menu were an API, and the hamburgers were implementations.

  No one bothered to challenge Schwartz's apparent belief that hamburgers are commonly featured on breakfast menus, as he had already moved on to confusing the jury on another front...

• In a $9 Billion Trial, Google's Secret Weapon Is a Filing Cabinet

  During opening arguments, Robert Van Nest, the lead attorney for Google, trotted out a literal actual physical filing cabinet labeled "java.lang" for the benefit of the jury.

  A flimsy 8.5" by 11" piece of paper that says "java.lang" sits on the very top of this beige metal cabinet, which I guess indicates what the filing cabinet is even supposed to be? The first drawer is labeled "Math" in big bold letters. As Van Nest talked to the jury about what APIs were, he opened up the "Math" drawer, pulled out a file, and waved it around.

  ...

  After conferring with others, I have determined that Van Nest means to explain that the system of filing (the labels on the folders and the drawers) is the API, and that he waved around some empty folders to illustrate how Google wrote its own implementing code to "fill the folders" with, rather than "stealing" Oracle's intellectual property.

• Top programmer describes Android's nuts and bolts in Oracle v. Google

  "This is me and my computer," said Bornstein, drawing a stick figure holding a laptop. He paused. "OK, now I've got a problem," he said, drawing a thought bubble above the stick figure to express his quandary. "Here are two numbers. Which of these two numbers is bigger?"

  Bornstein drew a book, presumably a book about Java, which would inform Stick-Bornstein how to use math.max, and the role of APIs in that.

• The biggest problem for the Oracle v. Google retrial: Judge Alsup's reality distortion field

  The only way Oracle could counter such testimony is by calling Judges O'Malley, Plager, and Taranto as witnesses to tell the jury that the Court got it completely wrong, and in fact that the declaring code and SSO are copyrightable. But no judge should be a witness, pure and simple. And a judge should not become a witness inadvertently through the act of informing the jury of his views on a legal issue that already has been decided. Such testimony is inadmissible under Rule 605.

But anyway, behind all these corporations, and celebrities, and history, and flamboyance, what is really going on here?

Well, here's a quick summary:

• The first trial was thought to be about patents.
• The patent issue went nowhere.
• But during that trial, what was thought to be a minor side-topic about APIs and copyrightability took center stage.
• And it turns out that everyone's really arguing about two things:
  • What's an "API"?
  • How does U.S. Copyright Law apply to APIs?

So, what IS an API?

Well, it stands for "Application Programming Interface", but the most important of those three letters is 'I', for "Interface".

About 25 years ago, in the early 1990's, there was a major movement towards what became known as "Object-Oriented Computing". This was a collection of techniques computer programming which dramatically revised the entire approach to software.

Prior to object-oriented computing, people tended to think first about algorithms, and used those algorithms to guide the overall structure of their program designs.

Object-oriented computing, however, encouraged people to think about their data model, and in particular about the individual objects that their program was manipulating. Those objects might be:

• Employees, departments, managers, and teams, in a Human Resources application
• Drivetrains, suspensions, and tires, in a Racecar Design application
• Missiles, warheads, and targets, in a Military Weapons application
• Accounts and transactions, in a Banking application

and so forth.

The point is, there are particular objects, with certain behaviors, and your program is concerned with assembling those objects into higher-level applications which accomplish tasks.

And, in order to do that, your PRIMARY CONCERN has to be with the interface between those objects; this became known as the

separation of interface and implementation

The interface to an object describes what the object can do.

The implementation of the object, which is internal to that object's source code, and is not available to its callers, specifies how the object does its tasks.

Prior to object-oriented computing, people found that programs could only be built to a certain size, after which no amount of effort could improve or extend them.

Every part of the program turned out to be inter-connected to every other part of the program, a nightmare often referred to as "spaghetti code."

But object-oriented programming brought relief from that crisis, enabling the programming-in-the-large which made the industry what it is today. Here's a nifty summary from a Microsoft guide: Understanding Interface-based Programming

Getting a grasp of interface-based programming is really tough. To gain an appreciation for this style of programming, you must leave behind old habits and intuitions about writing code and look back at the evolution of object-oriented programming (OOP) and computer science over the past decade—a Darwinian saga of how the interface has made modern software designs more fit for survival. For software to survive in the ever-changing jungle of the production environment, it must have three distinct characteristics: reusability, maintainability, and extensibility. This article will provide a general overview of interface-based programming and examine these characteristics.

The Component Object Model (COM) is founded on the idea of interface-based programming; COM would have no meaning without the concept of the interface. If you are a Visual Basic programmer who is trying to understand how COM really works, you should spend the time to learn how and why interfaces are so valuable in object-oriented software design. An understanding of interface-based programming will make you a much stronger COM programmer. This, in turn, will prepare you for creating COM-based applications for distributed environments such as Microsoft Transaction Server (MTS).

Interface-based programming exists outside the world of COM. It is a programming discipline that is based on the separation of the public interface from implementation. It was pioneered in languages such as C++ and Smalltalk by software engineers who discovered that using distinct interfaces could make their software, especially large applications, easier to maintain and extend. The creators of Java saw the elegance of interface-based programming and consequently built support for it directly into their language.

If you don't know what APIs are, or what object-oriented computing is, I recommend that Microsoft article. It's extremely well-written, which is actually no surprise for Microsoft documentation (which is typically of very high quality). But many people forget that Microsoft itself was one of the true pioneers of object-oriented computing: their COM and OLE technologies are nearly 30 years old now, and still going strong.

So where does that leave us? Michael Byrne of Vice's Motherboard site tries to sum it up: What an API Is and Why It’s Worth Fighting For

We can as programmers just use Java's own implementations by referencing the Java core API, but we can also use someone else's implementation as well, or we can even write our own. We just have to make sure that the result meets the same specifications given by the Java API.

This is what Google did, roughly: It used an implementation of the Java API not sanctioned by Oracle/Sun. So, the question is whether or not that constitutes copyright infringement. It should be clearer now as to what is at stake: the fundamental divide between interface and implementation. It so happens that this divide is what much of the open-source software world revolves around, the ability to separate functionality from implementation, to build the same things in new and better ways. Watch Google v Oracle closely.

And the team at Programmable Web try to dig into it in more detail, with an excellent article from last summer: Will Oracle v. Google Mean The Death of the API economy?

Oracle's case sits upon the argument that the first and fourth fair-use factors that were mentioned before have not been met. It argues that the purpose and character of Google's use of the Java APIs is clearly commercial and that it negatively affected the potential market by creating an unlawful market domination that hurt companies that had Java licenses, while Google's Android was built without meeting Java licensing standards, namely its requirement for compatibility.

It's complicated, and not easy to understand.

And I'm not sure where I personally stand on it.

I do think that Google was wrong to take Java and change it: the programming environment on Android devices is very, very similar to a programming language called Java, but it is not Java, and perfectly reasonable Java programs (e.g., Apache Derby) do not run on Android devices, not because such programs break any of the rules of Java, but because Android's programming environment is not Java.

On the other hand, in my lifetime I have seen copyright law used as a blunt force by massive corporations to control human behavior to an absurd extent, and I'm no fan of extending the reach of such.

Certainly you shouldn't be allowed to copyright the notion of taking the maximum of two numbers. That's an abstract concept, and the fact that Java spells it

java.lang.Math.max( int a, int b);

should not be something that Oracle America, Inc., can own.

Either way, though, Oracle v Google is important, and worth paying attention to.

So there you go.