Should APIs be copyrighted? – ZDNet





In the latest chapter of an ongoing legal battle, a U.S. appeals court has just ruled that Oracle can be granted copyright protection for its Java APIs in a battle with Google over Android’s inclusion of the code. As reported by ZDNet colleague Zack Whittaker, the case dates back to 2010, when Oracle took Google to court alleging that Google had violated Oracle’s Java copyright with the inclusion of 37 Java APIs within its Android mobile OS. The court ruled in May 2012 that the structure of the Java APIs were not copyrightable. The appellate court just reversed that ruling.

Keyboard and question marks 2 by Joe McKendrick
Photo: Joe McKendrick

What does it mean if APIs can be copyrighted? Will this have a chilling effect on the burgeoning API economy, and the flexibility of developers and enterprises to build and connect their digital ventures? Or will it afford developers some protection over the fruits of their labors?

The stakes are potentially high. As fellow ZDNet contributor Stilgherrian recently pointed out, the only businesses that can compete from this point going forward are those that leverage APIs for back-end services and digital capabilities.

Some industry observers say nothing good can come of copyrighting APIs. Ed Anuff, VP of product strategy at Apigee, says the ruling is “a no-win proposition for anyone involved,” noting that “while the goal of avoiding fragmentation of Java that has been Oracle’s stated intent in pursuing this has some merit, we’re not comfortable with the idea that copyrighting APIs is the way to accomplish this.  It’s likely going to have the opposite effect, causing the proliferation of convoluted APIs for no other reason than to avoid the potential of legal exposure.”

APIs can be quite simple, constructed with REST calls, and therefore many APIs developed by different creators are likely to be similar, if not identical. By some counts, there are more than 10,000 public-facing APIs, and it is projected that there may be between 100,000 to 200,000 public and private APIs this year. Anuff’s colleague, Bob Pagano, spelled out the implications of API copyright claims to developers in a Wired interview a couple of years back: he feared that in a world of proprietary APIs, someone will make “a land grab of common names and starts enforcing copyrights on APIs en masse,” locking down APIs in the same way internet addresses or Twitter handles are locked down. And “the odds of similarity between any two RESTful APIs is quite high,” he added.

Community sites such as the API Commons may help to keep APIs open and available — but will it be enough?

Dan Rowinski documents the appellate court’s ruling in ReadWrite, which states that “because we conclude that the declaring code and the structure, sequence, and organization of the API packages are entitled to copyright protection, we reverse the district court’s copyrightability determination with instructions to reinstate the jury’s infringement finding as to the 37 Java packages.”

Rowinski also cites the warning issued by the Electronic Frontier Foundation in 2012, as the lawsuit was progressing. “Treating APIs as copyrightable would have a profound negative impact on interoperability, and, therefore, innovation. APIs are ubiquitous and fundamental to all kinds of program development. It is safe to say that ALL software developers use APIs to make their software work with other software.”

Will extending copyright protection to APIs mean a step backwards in efforts to make applications more open and interoperable with each other? Or, is there another side to this? Does anyone see advantage in providing copyright protection to APIs? Perhaps this is also an opportunity for vendors to publicly demonstrate their commitment to innovation by putting many of their key APIs into the API Commons — as IBM and Microsoft have done in the past with Web services.





Should APIs be copyrighted? – ZDNet

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>