Oracle v. Google: Digging Deeper

This follows my recent post about Oracle v. Google. At the behest of commenters, both online and offline, I decided to dig a bit deeper to see exactly what level of abstraction is at issue in this case. The reason is simple: I made some assumptions in the last post about what the jury must have found, and it turns out that the assumption was wrong. Before anyone accuses me of changing my mind, I want to note that in my last post I made a guess, and that guess was wrong once I read the actual evidence. My view of the law hasn’t changed.

For the masochistic, Groklaw has compiled the expert reports in an accessible fashion here and here. Why do I look at the reports, and not the briefs? It turns out that lawyers will make all sorts of arguments about what the evidence will say, but what is really relevant is the evidence actually presented. The expert reports, submitted before trial, are the broadest form of evidence that can be admitted – the court can whittle down what the jury hears, but typically experts are not allowed to go much beyond their reports.

These reports represent the best evidentiary presentation the parties have on the technical merits. It turns out that as a factual matter, both reports overlap quite a bit, and neither seems “wrong” as a matter of technical fact. I would sure hope so – these are pretty well respected professors and, quite frankly, the issues in this case are just not that complicated from a coding standpoint. (Note: for those wonder what gives me the authority to say that, I could say a lot, but I’ll just note that in a prior life I wrote a book about software programming for an electronic mail API).

What level of abstraction was presented and argued to the jury? As far as I can tell from the reports, other than a couple or three routines that were directly copied, the Oracle’s expert found little or no similar structures or sequences in the main body source code – the part that actually does the work. The only similarity – and it was nearly identical – was in the structure, sequence and organization of the grouping of function names, and the “packages” or files that they were located in.

For computer nerds, also identical were function names, parameter orders, and variable structures passed in as parameters. In other words, the header files were essentially identical. And they would have to be, if the goal is to have a compatible system. The inputs (the function names and parameters) and the outputs need to be the same. The only way you can disallow this usage of the API is to say that you cannot create an independent software program (even one of this size) that mimics the inputs and outputs of the original program.

To say that would be bad policy, and as I discuss below, probably not in accordance with precedent. This is why the experts are both right. Oracle’s expert says they are identical, and Google copied because that was the best way to lure application developers – by providing compatibility (and the jury agreed, as to the copying part). Google’s expert says, so what? The only thing copied was functional, and that’s legal. It’s this last part that a) led to the hung jury, and b) the court will have to rule on.

In my last post, I assumed that the level of abstraction must have been at a deeper level than just the names of the methods. Why did I do that?

First, the court’s jury instructions make clear that function names are not at issue. But I guess the court left it to the jury whether the collection could be infringed.

Second, the idea that an API could be infringed is usually something courts decide well in advance of trial, and it’s a question that doesn’t usually make it to trial.

Third, based on media accounts, it appeared that there was more testimony about deeper similarities in the code. The copied functions, I argued in my prior post, supported that view. Except that there were no other similarities. I think it is a testament to Oracle’s lawyers (and experts) that this misperception of a dirty clean room shone through in media reports, because the actual evidence belies the media accounts.

This is why I decided to dig deeper, and why one should not rely on second hand reports of important evidence. Based on my reading of the reports (and I admit that I could be missing something – I wasn’t in the courtroom), I think that the court will have no choice but to hold that the collection of API names is uncopyrightable – at least at this level of abstraction and claimed infringement.

To the extent that there are bits of non-functional code, I would say that’s probably fair use as a matter of law to implement a compatible system. I made a very similar argument in an article I wrote 12 years ago – long before I went into academia.

Prof. Boyden asked in a comment to my prior post whether there was any law that supported the copying of APIs structure and header files. I think there is: Lotus v. Borland. That case is famous for allowing Borland to mimic the Lotus structure, but there was also an API of sorts. Lotus macros were based on the menu structure, and to provide program compatiblity with Lotus, Borland implemented the same structure. So, for example, in Lotus, a user would hit “/” to bring up the menus, “F” to bring up the file menu, and “O” to bring up the open menu. As a result, the macro “/FO” would mimic this, to bring up the open menu.

Borland’s product would “read” macro programs written for Lotus, and perform the same operation. No underlying similarity of the computer code, but an identical API that took the same inputs to create the same output the user expected.

Like the lower court here, the lower court there found infringement of the structure, sequence, and organization of the menu structure. Like the lower court here, the court there found it irrelevant that Borland got the menu structure from third-party books rather than Lotus’s own product. (Here, Google asserts that it got the API’s from Apache Harmony, a compatible Java system, rather than the Java documents themselves). There is some dispute about whether Sun sanctioned the Apache project, and what effect that should have on the case. I think that the Harmony is a red herring.The reality is that it does not matter either way – a copy is a copy is a copy – if the copy is illicit that is.

In Lotus, the lower court found the API creative and copyrightable, the very question facing the court here. On appeal, however, the First Circuit ruled that the API was a method of operation, likening it to the buttons on a VCR. I think that’s a bit simplistic, but it was definitely the right ruling. The case went up to the Supreme Court, and it was a blockbuster case, expected to — once and for all — put this question to rest.

Alas, the Supreme Court affirmed without opinion by an evenly divided court. And the circuit court ruling stood. And it still stands – the court never took another case, and the gist of Lotus v. Borland has been applied over and over, but rarely as directly as it might apply here.

Wholesale, direct compatibility copying of APIs just doesn’t happen very often, and certainly not on the scale and with the stakes of that at issue here. Perhaps that is why there is no definitive case holding that an entire API structure is uncopyrightable. You would think we would have by 2012, but nope. Lotus comes close, but it is not identical. In Lotus, the menu structure was much smaller, and the names and structure were far less creative. Further, the concern was macro programming written by users for internal use that would not allow them to switch to a new spreadsheet program. Java programs, on the other hand, are designed to be distributed to the public in most cases.

Then again, the core issue is the same: the ability to switch the underlying program while maintaining compatibility of programs that have already been written. Based on this similarity, my prediction is that Judge Alsup will say that the collection of names is not copyrightable, or at the very least usage of the API in this manner is fair use as a matter of law. We’ll see if I’m right, and whether an appeals court affirms it.