Oracle v. Google – Round I jury verdict (or not)

The jury came back today with its verdict in round one of the epic trial between two giants: Oracle v. Google. This first phase was for copyright infringement. In many ways, this was a run of the mill case, but the stakes are something we haven’t seen in a technology copyright trial in quite some time.

Here’s the short story of what happened, as far as I can gather.

1. Google needed an application platform for its Android phones. This platform allows software developers to write programs (or “apps” in mobile device lingo) that will run on the phone.

2. Google decided that Sun’s (now Oracle’s) Java was the best way to go.

3. Google didn’t want to pay Sun for a license to a “virtual machine” that would run on Android phones.

4. Google developed its own virtual machine that is compatible with the Java programming language. To do so, Google had to make “APIs” that were compatible with Java. These APIs are essentially modules that provide functionality on the phone based on a keywords (instructions) from a Java language computer program. For example, if I want to display “Hello World” on the phone screen, I need only call print(“Hello World”). The API module has a bunch of hidden functionality that takes “Hello World” and sends it out to the display on the screen – manipulating memory, manipulating the display, etc.

5. The key dispute is just how much of the Java source code was copied, if any to create the Google version.

The jury today held the following:

1. One small routine (9 lines) was copied directly – line for line. The court said no damages for this, but this finding will be relevant later

2. Google copied the “structure, sequence, and organization” of 37 Java API modules. I’ll discuss what this means later.

3. There was no finding on whether the copying was fair use – the jury deadlocked.

4. Google did not copy any “documentation” including comments in the source code.

5. Google was not fooled into thinking it had a license from Sun.

To understand any of this, one must understand the levels of abstraction in computer code. Some options are as follows:

A. Line by line copying of the entire source code.

B. Line by line paraphrasing of the source code (changing variable names, for example, but otherwise idential lines).

C. Copying of the structure, sequence and organization of the source code – deciding what functions to include or not, creative ways to implement them, creative ways to solve problems, creative ways to name and structure variables, etc.  (The creativity can’t be based on functionality)

D. Copying of the functionality, but not the stucture, sequence and organization – you usually find this with reverse engineering or independent development

E. Copying of just the names of functions with similar functionality – the structure and sequence is the same, but only as far as the names go (like print, save, etc.). The Court ruled already that this is not protected.

F. Completely different functionality, including different structure, sequence, organization, names, and functionality.

Obviously F was out if Google wanted to maintain compatibility with the Java programming language (which is not copyrightable).

So, Google set up what is often called a “cleanroom.” The idea is not new – AMD famously set up a cleanroom to develop copyrighted aspects of its x86 compatible microprocessors back in the early 1990’s. Like Google now (according to the jury), AMD famously failed to keep its cleanroom clean.

Here’s how a cleanroom works. One group develops a specification of functionality for each of the API function names (which are, remember, not protected – people are allowed to make compatible programs using the same names, like print and save). Ideally, you do this through reverse engineering, but arguably it can be done by reading copyrighted specifications/manuals, and extracting the functionality. Quite frankly, you could probably use the original documentation as well, but it does not appear as “clean” when you do so.

Then, a second group takes the “pure functionality” description, and writes its own implementation. If it is done properly, you find no overlapping source code or comments, and no overlapping structure, sequence and organization. If there happens to be similar structure, sequence and organization, then the cleanroom still wins, because that similarity must have been dictated by functionality. After all, the whole point of the cleanroom is that the people writing the software could not copy because they did not have the original to copy from.

So, where did it all go wrong? There were a few smoking guns that the jury might have latched on to:

1. Google had some emails early on that said there was no way to duplicate the functionality, and thus Google should just take a license.

2. Some of the code (specifically, the 9 lines) were copied directly. While not big in itself, it makes one wonder how clean the team was.

3. The head of development noted in an email that it was a problem for the cleanroom people to have had Sun experience, but some apparently did.

4.  Oracle’s expert testified (I believe) that some of the similarities were not based on functionality, or were so close as to have been copied. Google’s expert, of course, said the opposite, and the jury made its choice. It probably didn’t help Google that Oracle’s expert came from hometown Stanford, while Google’s came from far-away Duke.

So, the jury may have just discounted the Google cleanroom story, and believed Oracle’s. And that’s what it found. As someone who litigated many copyight cases between competing companies, this is not a shocking outcome. This issue will not doubt bring the copyright v. functionality issue to the forefront (as it did in Lotus v. Borland and Intel v. AMD), this stuff is bread and butter for most technology copyright lawyers. It’s almost always factually determined. Only the scope of this case is different in my book – everything else looks like many cases I’ve litigated (and a couple that I’ve tried).

So, what happens now in the copyright phase?  (A trial on patent infringement started today.) Judge Alsup has two important decisions to make.

First, the court has to decide what to do with the fair use ruling. Many say that a mistrial is warranted since fair use is a question of fact and the jury deadlocked. I’m not so sure. The facts on fair use are not really disputed here – only the legal interpretation of them; my experience is that courts are more than willing to make a ruling one way or the other when copying is clear (as the jury now says it is). I don’t know what the court will do, but my gut says no fair use here.  My experience is that failed cleanrooms fail fair use – it means that what was copied was more than pure functionality, and it is for commercial use with market substitution. The only real basis for fair use is that the material copied was pure functionality, and that’s the next inquiry.

Second, the court must determine whether the structure, sequence, and organization of these APIs can be copyrightable, or whether they are pure functionality. I don’t know the answer to that question. It will depend in large part on:

a. whether the structure, etc., copied was at a high level (e.g. structure of functions) or at a low level (e.g. line by line and function by function);

b. the volume of copied (something like 11,000 lines is at issue);

c. the credibility of the experts in testifying to how much of structure that is similar is functionally based. On a related note, the folks over at groklaw think for the most part think this is not copyrightable. They have had tremendous coverage of this case.

I’ve been on both sides of this argument, and I’ve seen it go both ways, so I don’t have any predictions. I do look forward to seeing the outcome, though. It has been a while since I’ve written about copyright law and computer software; this case makes me want to rejoin the fray.