Sarid first acknowledges the fear he and others have legitimately feared about the decision's extension of copyright protection to APIs and the reasons for believing such protection is not appropriate:
APIs are quite utilitarian, like an ATM machine’s operation: slide your card here, punch your code there, select from a menu, and expect cash in return. How could that be copyrighted? This surely isn’t what the copyright law was intended to protect: it’s not a creative work of art, it’s not an author expressing ideas in a personal and distinctive style, nor a programmer choosing to write code this way vs that way.
Most importantly, however, Sarid recognizes that the mere fact something is entitled to copyright protection does not mean no one else can use it without permission (or even without credit), and the non-creative aspects of API creation is a significant reason that much of the appropriation of others' APIs will turn out to be legitimate, non-infringing fair use:
First, the entire ruling by the appeals court is about copyrightability, not about whether anyone can freely use that copyrighted work — that aspect is called “fair use,” and fair use in this case is still wide open. And while the appeals court chastised the lower court for mixing those up, we might not care so much: whether the API is not copyrightable, or whether it is copyrightable but anyone can use it, the outcome seems pretty much the same freedom we’re striving for.
If there’s no fear of legal action, the API ecosystem can get back to the merit-based evolution and natural selection it’s been enjoying. The appeals court not only explicitly instructs the lower court to make a determination about fair use, it even outlines the case and the aspects the lower court should consider. For example, while interoperability doesn’t make a case against copyright, it could make a case for fair use, the appeals court says. It then lays down the four cornerstones for establishing fair use, some of which should be music to our ears:
>Is the copy “transformative” and is it for non-profit purposes? In the API world, the answer is often no and no, because we’re trying to converge on common approaches rather than lots of transformation, and profit is indeed a great driver. That’s not good for fair-use claims. But fear not, the other cornerstones await…
>Is the copyrighted work “informational” vs truly “creative?” I think we have a good argument that an API is closer to a user manual for a toaster than to a play by Shakespeare. At least it better be, if you don’t want to assume the developers using your API have a healthy dose of early modern English training. If any cornerstone should give us great hope, it’s this one. As the court of appeals stated, “Thus, where the nature of the work is such that purely functional elements exist in the work and it is necessary to copy the expressive elements in order to perform those functions, consideration of this second factor arguably supports a finding that the use is fair.”
>Have you copied the entire API? If you do, including the documentation of each and every parameter and function call, of every area of functionality, with no changes, verbatim, you have less of a fair use defense. But if you’re just using the same pattern, or even if you’ve replicated just the functional aspects of an area of an API to achieve interoperability, perhaps you can lean on this cornerstone as well.
>To what extent is the marketability of the original work harmed by the copy? This one seems very open-ended. Surely people will not stop reading the spec for the original API because they can just read the spec for the new API — that’s the kind of test you might apply about a copyrighted book or article. But would the new API take market share away from the original API’s provider? In many cases, yes, but that’s good: there should be vigorous competition based on the merits of the services provided, and not on barriers of interoperability because the functional instructions for how to access the services cannot be copied. We’ll just have to see where this one goes. And perhaps it won’t matter much, if the market rewards service providers not on the originality of their APIs but rather on the value they provide.
I actually sat down to read the ruling, in detail, all 69 pages of it. It is remarkably readable, insightful, and germane. Granted, it’s all about language-level (Java) APIs rather than web APIs, but all the right pieces are there. The judges discuss with great care the separation of interface from implementation; the essence of an interface as a whole, vs. its being a collection of short command names, parameter names, and value types which themselves are not copyrightable; its form (which they ruled copyrightable) vs its function (which is not). A major point is that the author of an API has many choices about how to express their interface’s functionality, so when the author expresses it in a particular way, he or she is making a creative choice which then grants copyright protection.
Addendum: For another, partly contrary view, see Jonathan Band's article, The Federal Circuit's Poorly Reasoned Decision in Oracle v. Google. I think it very likely Sarid agrees with Band's hope that on remand from the Federal Court's decision the lower court finds that Google's uses of Oracle's APIs consituted non-infringing fair use:
One possible light at the end of the tunnel is that on remand, the lower court could rule that the copying of program elements necessary for interoperability is a fair use as a matter of law. After all, the Ninth Circuit in Sega held that “where disassembly is the only way to gain access to the ideas and functional elements embodied in a copyrighted computer program and where there is a legitimate reason for seeking such access, disassembly is a fair use of the copyrighted work, as a matter of law.” Such a ruling would restore the legal certainty that [the decision in Oracle v. Google] has upended.