Monday, May 21, 2012

Judge asks Oracle and Google excellent questions about Android/Java interoperability

Shortly before 6 AM local time, Judge Alsup entered a request for further briefing from Oracle and Google regarding "interfaces, exceptions and interoperability". The request has two parts:

  • The first question relates to interfaces and exceptions. I will comment on the parties' answers (due by noon local time on Wednesday) if there's any major disagreement in this regard. It appears to me that the judge just wants to get a better understanding of how interfaces and exceptions work in an object-oriented programming environment. I don't think interfaces differ from class definitions in terms of copyrightability. At the end of the day, an abstract class is almost the same as an interface.

  • The second part is a set of four questions about interoperability, and those questions are worth commenting on even before the parties have filed their replies.

These are the four interoperability-related questions:

  1. To what extent, if at all, have applications and programs written for the J2SE platform before Android arrived been able to run on Android?

  2. To what extent, if at all, have applications and programs written after Android arrived been able to run both on Android and J2SE?

  3. How, if at all, have Android and the replication of virtually all of the 37 packages promoted interoperability?

  4. To what extent was interoperability an actual motive of Google at the time the decision was made to replicate the 37 packages?

The answers to all those questions will be unfavorable to Google's anti-copyrightability argument. The answer to questions 1 and 2 is that Android apps don't run on Java, and Java apps don't run on Android, regardless of when they were written. Some small code snippets may work on both, but those are useless all by themselves. As a result, the answer to question 3 is that Android is all about fragmentation and not at all about interoperability. That already answers the fourth question about Google's motive: Google simply didn't want to be interoperable. It still doesn't want to (otherwise the parties would already have settled). What Google wanted to do is to build a somewhat (but not completely) familiar platform in order to attract Java programmers to Android. That's not what interoperability is about.

The only major copyright-related decision that Judge Alsup has to make during this trial (not including a retrial of the unanswered "fair use" question) is about the copyrightability of the 37 asserted APIs. If he rules in Oracle's favor, a retrial will be scheduled, and possibly in the not too distant future. If he rules against Oracle on this one, Oracle will need a successful appeal before it can make further headway with the API-related core part of its copyright liability claim.

Those four questions are just questions, and even if the judge requests answers to them at this stage, he may later conclude that those questions and answers aren't relevant to the ultimate decision. But those questions are a significant indication of one key issue the judge is considering in connection with copyrightability. Google's argument against copyrightability rests in no small part on its claim that material needed for "compatibility" cannot be protected, pointing to the Sega and Sony cases (which the judge mentions in his request). Here are a few quotes from a brief Google filed a week ago:

"That is, the specification identifies the functional requirements an implementation must meet to be compatible with the API described by the specification." (pointing to Sega)

"The SSO of the 37 API packages is functionally required for compatibility, and thus is not copyrightable." (again pointing to Sega)

"Notably, although Sega was a fair use case, the Ninth Circuit did not rely on fair use to conclude that functional requirements for compatibility are not copyrightable. Instead, the court relied on section 102(b). Indeed, the ultimate fair use holding depends on this statement of law."

"And, in order to be compatible with the APIs in the 37 packages, Google had to implement the SSO of those packages."

Especially the last sentence is a typical example of something that is not incorrect but grossly misleading. The fundamental problem with that statement is that Google wanted to be compatible with 37 Java APIs, but not with the other 100+. Why those 37? Not only hasn't Google presented any objective criteria for its arbitrary selection but it also contradicts itself with respect to which of those APIs are needed to implement Java. I've seen Google provide answers that suggest 20 -- not 37 -- APIs are needed to implement Java. In reality, the number is much lower: it appears that it only takes three APIs.

This is how Google describes Oracle's position on Java compatibility:

"Oracle argues that 'compatible' means whatever Oracle's business model wants it to mean, and more specifically that an implementation is compatible only if it passes Oracle's TCK."

Actually, the truth is in one of the Google-internal emails that served as trial exhibits:

The parties' responses to Judge Alsup's interoperability-related questions will essentially confirm this. Unless Google argues with pretty meaningless code snippets, it will be forced to concede that Android and Java aren't interoperable.

Google's legal theory boils down to a claim that something isn't copyrightable because it can be used for compatibility, but once it has been held non-copyrightable on that basis, the material can subsequently be used for incompatible implementations, and for the purpose of fragmentation. Today's interoperability-related questions clearly indicate that Judge Alsup is interested in the net effect of any sweeping rules that deprive material of copyrightability but ultimately allow someone to achieve the very opposite. What we don't know yet is how much weight the judge will give this question when he finalizes his decision on copyrightability. In my view, the question of the net effect of an overreaching interoperability privilege should be a key consideration. If a legal rule results in the opposite of what it was created for, there's something wrong, either with the rule itself or, more likely, with an overreaching proposal for how to apply that rule.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Share with other professionals via LinkedIn: