« Ain't No Party Like a Bloomberg Party Because a Bloomberg Party Don't Stop (Or, You Know, Have to Deal With Term Limits) | Main | Principles for Productive Conversations About Race »

Monday, May 07, 2012

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.

Posted by Michael Risch on May 7, 2012 at 08:07 PM in Information and Technology, Intellectual Property, Web/Tech | Permalink

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341c6a7953ef016766475eb4970b

Listed below are links to weblogs that reference Oracle v. Google - Round I jury verdict (or not):

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Michael, excellent summary, thanks very much for posting this. I'm still trying to grapple with what exactly this suit is about based on just some cursory reading. I get that what is being disputed (at least at this stage) is whether Google infringed Oracle's copyright in some sort of APIs. My understanding of APIs is that they are just the call and response formats necessary to exchange information and commands between operating system and application. As I understand it, there's no way, if you want interoperability between an application and an operating system, to NOT duplicate the entire set of APIs verbatim; either the OS and the application understand each other's messages, or they don't. The situation is a bit more complicated here because we're talking about a virtual machine, so there's actually two sets of APIs, one for the application to Java and another for Java to the underlying mobile OS. Basically the situation is a lot like Adapter in the old CA v. Altai case.

But I take it that we're not just talking about "APIs" as I just defined them, given that there's been mention of structure, sequence, and organization (which wouldn't make much sense for API formats -- either you have them or you don't), "11,000 lines of code," and the like. I take it what's at issue is, as in CA v. Altai, not the API formats themselves but the underlying code in Java that actually does the work of "translating" between the application and the mobile OS. So if that's right, then what we have is a garden-variety software infringement case, albeit one with a lot of externally imposed demands (as in Altai), not really a case about copyright in API formats -- which matters to me because I'm still looking for a decision that directly tackles the question of whether THOSE are copyrightable, where they are written in advance of any existing third-party application program market, such that you cannot say that the choice of API formats is driven by external considerations. Do I have this right or am I heading off the rails somewhere?

Posted by: Bruce Boyden | May 8, 2012 3:11:51 PM

Post a comment