In the wake of a ruling last week by an appellate court that APIs can in fact be protected by copyright, industry reaction ranges from outrage to forlorn pragmatism. In general, the fact that any given vendor can enforce copyright protection claims on its APIs is likely to drive developers toward more open APIs, where the terms of usage are clearly defined.
While the consensus is that the latest decision in the lawsuit between Oracle and Google over the cloning of Java APIs is unfortunate for all concerned, the fact is that when it comes to openness, not all APIs are created equal. Case in point is Rackspace, one of the primary drivers of the OpenStack cloud computing framework that is being broadly adopted across the cloud service provider landscape. In a blog post this week, Van Lindberg, vice president of intellectual property at Rackspace, reiterated Rackspace’s position on APIs. Not only are the Rackspace APIs on both the client and server sides open source, Rackspace has publicly said it will not enforce API copyrights. In fact, Rackspace has challenged Amazon specifically and other cloud service providers to follow suit.
Many developers fundamentally believe that APIs simply serve as an interface between two sources of code. As such, they should not be patentable or subject to copyright. Last week a federal appeals court fundamentally disagreed with that position, as least as it applies to copyright law. But the court left open the idea that invoking an API could be construed as fair use of an API.
As developers become more cognizant of the implications of API copyright law, the expectation is that many will vote with their feet to embrace open APIs, where the terms of usage are clearly defined. According to MuleSoft CTO Uri Sarid, "in this ruling the court clearly treated the interface (the API) separately from the underlying code behind the interface, and pronounced the API itself to be copyrightable" (disclosure: Mulesoft is parent company to ProgrammableWeb). "But," Sarid says, "it also returned to the lower court the question of what might still constitute fair use of the API." Because the court's decision seems largely based on the choice the API author had in expressing the functionality of the API, Sarid wonders whether some of the dire implications of this decision may be avoided by adopting more prescriptive approaches to API construction.
At the same time, some think there may soon be a wholesale migration away from Java in favor of other programming languages, such as Node.js, where no one vendor is trying to enforce control over an entire API ecosystem.
Also remaining to be seen is how, if this ruling stands, vendors ranging from Concurrent to IBM are affected. Concurrent provides an alternative to the Java API in its open source development tools, while IBM has open sourced Java client software while keeping its implementation on its server operating systems proprietary.
Ed Anuff, vice president of product strategy for Apigee, a provider of an API management platform, says the biggest problem facing developers may simply be that there is far too much gray area when it comes to invoking APIs. All the ambiguity resulting from a 20-year-old effort to prevent the fragmentation of Java is now having a chilling effect on an API economy as a whole, says Anuff. In the meantime, 3scale CEO Steve Willmott says that despite what is occurring in the Oracle case, he expects that vendors and developers will remain sensible in terms of what promotes the common good. In an ideal world, says Willmott, whose company provides API management tools, all APIs would be published under an open API Commons license that he says goes a long way toward clearing up any usage ambiguity.
Ultimately, it will be up to developers to decide to what degree open APIs are critical to their business strategies. Today everything from software-as-a-service applications to cloud infrastructure provides access to some type of API. The issue is that not all of them are as open as others. That means developers going forward are going to take a much longer look at terms and conditions of usage before taking the API plunge.