So, I have been going through the opinion (though I haven't finished reading every single word of it, I do intend to do this, and I hope that many other people do as well; certainly, I wanted to skim enough of it to have an informed opinion, rather than operating only off of things I've heard in popular news articles). I care a lot about this case (doing interoperable development), and there is some nuance to what is going on that I don't think many of the people commenting on this matter in the general developer public appreciate.

To fail to summarize ;P, this nuance stems from separating the question of whether Oracle's APIs are copyrightable from whether Google can claim "fair use" in copying them for their purposes. Much like with trademarks (where people get really uptight that someone "trademarked a word", ignoring context restrictions), I think people lose these nuances while talking about situations like this, and presume that if something is protected in some way then it is an ironclad protection that applies even in ludicrous circumstances.

Keeping this difference in mind, if the court said "APIs are copyrightable, but what Google did was a clear example of fair use: creating interoperable implementations is allowed", some people might still be angry, but I think many fewer people would be bothered: it changes what the opinion means. And, in fact, this is closer to what this opinion is saying than many people seem to be reading from it: they talk a lot about whether what Google is doing might be fair use, but they essentially punt that call back to the lower court.

> Because the jury deadlocked on fair use, we remand for further consideration of Google’s fair use defense in light of this decision.

We then have to ask "what happened" with this fair use argument, as we would hope that in the situation that APIs are copyrightable that interoperating with those APIs would be considered fair use: "something went wrong here". I think we can actually see some disappointing mistakes in Google's argument from reading this opinion: even though it wasn't trying to decide this matter directly, it talks a lot about fair use and models of interoperability. It frankly seems like Google just did a really really bad job of arguing the case :(.

If we go back to the beginning of this, most of Sun's core arguments about Java surround the idea that code written against Java should run on anything claiming to support Java. Microsoft was really excited about Java, but because they wanted to add a few extra features--some classes that would exist for UI purposes on their implementation of Java but on no other--the Internet has ever since considered them horribly evil people and were happy when Sun won in court against them (which is why Microsoft decided to build C#, btw).

Google seriously did not want to build something interoperable with Java under this definition: they have their own class libraries for handling large regions of the platform, including basic things absolutely any application would be using a lot of, such as UI and RPC. Given this, Google trying to claim "we want to be interoperable with Java" is horribly confusing. You find the opinion trying to understand Google's position on interoperability and failing: it almost makes Google look like they are lying about "interoperability".

> Indeed, given the record evidence that Google designed Android so that it would not be compatible with the Java platform, or the JVM specifically, we find Google's interoperability argument confusing. While Google repeatedly cites to the district court's finding that Google had to copy the packages so that an app written in Java could run on Android, it cites to no evidence in the record that any such app exists and points to no Java apps that either pre-dated or post-dated Android that could run on the Android platform.

> During oral argument, Google's counsel stated that "a program written in the Java language can run on Android if it's only using packages within the 37. So if I'm a developer and I have written a program, I've written it in Java, I can stick an Android header on it and it will run in Android because it is using the identical names of the classes, methods, and packages." Counsel did not identify any programs that use only the 37 API packages at issue, however, and did not attest that any such program would be useful. Nor did Google cite to any record evidence to support this claim.

Now, I have certainly seen many Java libraries that manage to only use this subset of features; and to me, being able to use those libraries is an interesting aspect of "interoperability". Sadly, however, Google's lawyers seem to have not bothered making that argument: they were probably doing the important thing where they simplify the kinds of words and ideas they are using for the jury to quickly understand, but the difference between applications and libraries needs to not be understated and left to implicit context :(.

The result is that rather than seeing what Google was doing as building an interoperable implementation of an API, the panel sees Google as instead building their own non-interoperable platform that happens to share striking similarities to Oracle's Java. They feel like Google is just copying a bunch of effort and work and even creative expression that Sun had put into Java in the construction of Google's competing way of developing applications for the seemingly-purposely unrelated platform that they are using on Android.

> The compatibility Google sought to foster was not with Oracle's Java platform or with the JVM central to that platform. Instead, Google wanted to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue. The district court agreed, finding that, as to the 37 Java API packages, "Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java."

Let's say that Microsoft's C# happened to have a programming library that had large regions of API that were "directly copied" from the standard library of Java, even if there were no way to even attempt to run a Java class/jar on the .NET Virtual Machine. While many people would still say "that clearly should be allowed", I think that changes the character of the discussion quite a bit: I think many of the same people angry at Samsung about copying things off Apple would find themselves angry at Microsoft for copying things off Sun.

Again, I want to stress that I am not saying this should sit well with everyone: I can easily appreciate the arguments of people who feel that APIs should simply fundamentally not be subject to copyright. (That said, I can also appreciate the arguments of people who feel that software in general should not be subject to copyright, and I appreciate the arguments of people who believe that absolutely nothing should be subject to copyright as they think the idea of copyright is flawed. These are all somewhat reasonable positions to me.)

Instead, I point this stuff out as I think people are extrapolating too much from this decision and are taking it to mean things that it doesn't: in particular, it doesn't mean that you can't build systems that interoperate with an API designed by another party. It is then unfortunate that people are extrapolating this decision all the way up to hyperbole like "the PC revolution wouldn't have happened under this ruling". It just doesn't help when people make these kinds of grandiose statements: everything becomes emotional :/.

Really, what we are looking at (and I think grellas is saying something similar, though from a different direction) is an opinion that leaves an area of law in a state where it is not entirely clear: that is a problem, as it leads to individuals having to make horrible and oft-flawed decisions as to whether specific actions they want to perform are or are not allowed. But this uncertainty is not the same as saying "this is not allowed"; and even if Google's usage was not allowed, maybe a intended-to-be-fully-interoperable Java is.