Oracle v. Google judge to decide whether APIs are Copyrightable, not the jury

I'm not sure it's actually supposed to be surprising that the Judge came down on this side. The whole point of the Judge/Jury separation is that one gets to decide matters of law and the other matters of fact. Clearly whether or not the doctrine of copyright extends to the expression of an API is not a fact being contested here.<p>The more amusing bit is that the incriminating code snipped in Oracle's slides goes the other way: the code is in Java because Josh Bloch (the Google employee who checked it into Android) <i>wrote it in the first place and gave it to Sun</i>. So the same TimSort implementation got carried with him into Android. There may still be a copyright question if he actually assigned ownership to Sun, I guess. But suing the author over the use of open source code he gave you in another open source project is... yeah.

As someone who obsesses over API design, it is interesting for me to reflect on why I don't consider APIs copyrightable, even though I have spent so much effort and creativity designing them.<p>The issue makes the most sense to me when I think of APIs as communications protocols. Indeed APIs for remote services literally <i>are</i> communications protocols. But even for the in-process case an API is the means by which two decoupled pieces of code communicate.<p>In this sense, APIs aren't that different from languages themselves. If you get really abstract, you could think of LISP as nothing but S-expression syntax and everything else (including define, lambda, etc) as an API.<p>Languages themselves aren't copyrightable, even thought things you can say <i>in</i> a language are. Languages like Lojban certainly had a lot of creative design go into them, but that alone doesn't make them copyrightable.<p>So even though I think you can make a pretty convincing philosophical argument for why APIs shouldn't be copyrightable, the critical deciding factor to me in is a practical one. Allowing APIs to be copyrightable would be a huge and unwarranted advantage to incumbents at the expense of innovation and disruptive technology. Users of any API would be locked in to one particular provider of that API.<p>The ability to swap out one component for another is a fundamental tool for software engineers, and it's a fantastically pro-competitive check that keeps people honest. If your API provider BigCo raises their prices and no one else is allowed to compete with them because their API is copyrighted, how is that good for anyone except BigCo? In particular, someone else may have developed a superior way of implementing the API; allowing them to do so could help move the entire industry forward. Protecting BigCo from this disruption gives them no incentive to move their own tech forward; they can continue to coast on the vendor lock-in of their customers. We're not talking about letting others copy their product, but rather allowing others to speak the same <i>language</i> that everyone is currently speaking to BigCo.<p>I agree with Joshua Bloch's sentiment that API design is "tough" and "a noble and rewarding craft," but I don't think either of these imply legally-protected status. I think it would be terrible for the industry if the judge ruled that APIs are copyrightable.

One thing that suprises me is how <i>well</i> the judge seems to grasp this rather technical issue.

That seems correct: whether copyright law in principle covers copyright of APIs is a question of law rather than fact.

I'm surprised that copyrightability of APIs is still an open question in (US) law. Is that because people haven't copied each other's APIs before, or because when they did nobody cared about the legality?

I feel the judge will rule that APIs are not subject to copyright. There is no expression of creativity and it is fairly mechanical. I also think that if they are subject to copyright lots of people are going to get sued.

Google will have to display Android's relevance via the difference between implementing an API into a piece of software vs. the open and free use of an API's concept, which in this case is mostly a set of [37] "best practices" for a programming language. I suspect the latter is where Google will try and grab some ground in the copyright debate in the days to come.