Whew! That loud sigh of relief you hear reverberating from Silicon Valley is a reaction to yesterday’s Oracle-Google ruling, which declared that APIs are not protected by copyright. While this case could be far from over – Oracle may appeal and force another $50 million round of litigation – a knowledgeable judge and a well-argued 41-page decision will likely make for a strong precedent.
In the few weeks, since I last discussed this case, I’ve gotten a lot of feedback. While some techies provided commentary supporting Google’s position, more responses came in the form of questions about APIs themselves. Are programming language APIs different from Web, Cloud or other APIs? Does Oracle deserve special consideration due to the time and effort invested? Can one API be “better” than another?
Language APIs certainly appear to be different from Web APIs. They are bound to language syntax and define local functions, which are then compiled or interpreted into bytecode and executed on a low-level platform. Web APIs, on the other hand, are generally language-independent and use basic networking protocols to execute remote services often hosted by an external party.
However, there is an important common bond defined in the acronym itself. Each API is defining an interface to some actual functionality or data. To use a travel metaphor, APIs are not a destination – they are the directions to that destination. Whether it’s a Java class definition, an Amazon S3 storage operation or a Netflix catalog request, an API describes how to do something, get something, calculate something etc.
Because an API is simply a method for accessing an application (the implementation of which is protected under the law), there are many ways to describe the interface, some “better” than others. And Sun Microsystems (later purchased by Oracle) did put time and effort into its creation of a highly-structured Java API.
But structure and complexity are not necessarily the hallmarks of a superior API, as we’ve seen with the move from SOAP Web services to REST-based APIs over the past few years. In fact, generic self-describing APIs simple enough to be navigated without documentation by man or machine are now considered the pinnacle of success, at least according to the Richardson Maturity Model.
When it comes to whether or not APIs can be copyrighted, I happen to be in favor of the ruling as it stands, if only to avert disaster in the IT industry. By taking a strong stand on the issue (even with caveats around extending this ruling to other case law), the judge has possibly prevented a whole new round of lawsuits that could have rivaled the still-ongoing Apple/Samsung/Google patent wars. The last thing the tech world needs is more distractions from all of the fantastic innovation taking place today.
So for now, we can continue to focus on how to secure and govern the applications and data being exposed via APIs. Access to that functionality is the true value of an API and needs to be protected by both technology and the law.
(See Groklaw’s review of the decision for more trial details.)