APIs Can Be Copyrighted… Now What?

May 13 2014

6 comments 0
motif

The battle between software giants Oracle and Google hit close to home again last week, when a Federal Court of Appeals overturned a 2-year-old ruling by a lower court and established that APIs are entitled to copyright protection. The first reaction from most people is: how strange! After all, APIs are just the specification of how a software system or service behaves – call it this way, send it this information, get back that information – so how is that possibly something copyrightable? It’s not like a book, or a painting, or even software… And the second reaction, from many in the API world, is: no!!!

Do we really need to worry about being sued for adopting some popular API pattern to which developers have grown accustomed, and that’s been tried and tested by a major player? Should a new service provider be barred from providing an API that’s interoperable with an established player so it can compete with minimal developer friction? What if I build a mobile app to an API and that app embeds the specification of the API in order to call it correctly – can the API provider now control what I do with my app? And do we really want to scare the numerous enterprises now opening themselves up via APIs into coming up with arcane API designs just to avoid the specter of legal challenges?

These concerns are all very real and very immediate, especially to those of us in the API ecosystem working to solve problems of interoperability, usable and consistent and predictable API design, and accelerating value creation in the API economy. But before pushing the panic button, I took some time to really read the 69-page ruling of the appellate court, which – fortunately for someone like me with no legal background and even less patience – is remarkably well-written and clearly thought out. These are not lawyers and judges missing the gist of technology, confusing interface with implementation, mixing code with specs. They get it, they focus on the right issues, and they state unequivocally: copyright happens when an API is created, not later when you may want interoperability; copyright is appropriate when the API author explicitly chooses from many possible expressions of the interface’s desired functionality; and copyright isn’t invalidated just because the interface also embodies a functional process (which itself is not copyrightable).

Fortunately, they don’t end there. Two rays of hope also emerge from that tome:

  1. The copyright claim is based on the author of an API having a broad choice in expressing the functionality they’re providing. That’s like a book’s author having lots of choices for how to put a story down in words, and it’s that combination of words which receives copyright protection. Take away the choice, and there may be no copyright. If the words are generated by a program following a predetermined procedure, a recipe, there is no choice. So… if API design becomes even more prescriptive, if we come up with recipes that automatically lead to usable, consistent, predictable APIs in any domain, perhaps we also avoid legal hurdles? That would be sweet, providing even more motivation to pursue the course we’ve embarked on.
  2. Even if APIs are subject to copyright, that need not mean you cannot copy them. The court of appeals laid out the argument that could be used to establish fair use of APIs, and sent the case back to the lower court to make a determination on fair use. Now, fair use may not be as clean as non-copyrightability in avoiding legal battles, but it may be the best weapon we have, and it’s been very effective in other areas. When we quote a copyrighted work in our own writing, when a parody is created of another work, we’re not paralyzed by fear of infringement, because there’s a broad legal precedent established this as legitimate fair use. I anticipate such a precedent will now be set for APIs. Indeed, we should strive to test the boundaries of fair use sooner rather than later, to establish a safe zone of operation in which the API ecosystem can grow unimpeded.

And finally, we can do something about this now: establish lots of API patterns, examples, best practices, and full specs, put them in the public domain, and promote them, to not only improve and facilitate API creation but to preempt future copyright challenges; work harder on prescriptive approaches, such as practically-RESTful web APIs, and express them in ways that explicitly reference patterns, as you can do with RAML; and encourage anyone with a good API or pattern to open-source their interface and help us all press on the gas pedal and not the brake pedal.

You can read more details about all of this on my Wired Insights article »


We'd love to hear your opinion on this post

6 Responses to “APIs Can Be Copyrighted… Now What?”

  1. […] APIs Can be Copyrighted…Now What? – Uri Sarid […]

    Agree(0)Disagree(0)Comment
  2. I really enjoyed this. I was thinking that perhaps we need an open source API project (nuget or github) that just has APIs. Perhaps interfaces for common patterns. Would this solve the problem? If so, any open source projects you would suggest?

    I am a .net developer, but an API should really be platform agnostic. Normally I would just create an Interface in C# but in this case wondering what a good approach would be. If we open-source an API in one language I suppose it is open in all?

    Hopefully Congress fixes this, but in the mean time I think we should rush to get major APIs open sourced. Thoughts on implementation?

    https://m.facebook.com/?_rdr#!/story.php?story_fbid=10152428154109337&id=670514336 – repost if your blog entry. Thanks for the thought provoking blog.

    Agree(0)Disagree(0)Comment
  3. I clearly need to read the whole ruling, but this seems to indicate that creating an API project of just Interfaces is of no use (legally):

    “copyright happens when an API is created, not later when you may want interoperability; copyright is appropriate when the API author explicitly chooses from many possible expressions of the interface’s desired functionality; and copyright isn’t invalidated just because the interface also embodies a functional process (which itself is not copyrightable).”

    An interface is a specification that can be used across a variety of proprietary software solutions which each may be proprietary. But if you don’t have a system and only a specification (Interface) does that really protect your right to use later when you need the API?

    Agree(0)Disagree(0)Comment
  4. I’m no lawyer so please take all I say as just a layman’s opinion. But *if* API interface specifications (I’m trying to be REALLY explicit that I’m talking about the interface, not the implementation) are really copyrightable, then it can only help to explicitly license them for any manner of use under as broad a license as you can find. Apache, MIT, BSD come to mind. If they’re not copyrightable, anyone can use them; if they are copyrightable and the courts rule they can still be used/copied broadly without explicit permission and without infringing because of fair use, great; and if none of those hold, an open source license by the copyright owner grants anyone the explicit right to use/copy them. 3 layers of defense! As for a project that lists APIs and patterns and now, perhaps, also their licenses, look to directories like ProgrammableWeb adding that capability soon.

    Agree(0)Disagree(0)Comment
  5. We are on the same page when speaking about the specification/Interface… No implementation.

    If we did create them under one of the more common open source license, I am not sure it accomplishes anything legally, but also not sure it wouldn’t.

    Next step is to figure out if the specification is copyrightable. Checking out legal analysis…

    Agree(0)Disagree(0)Comment
  6. […] Can Be Copyrighted… Now What? Mulesoft Blog – March 13, 2014 by Uri […]

    Agree(0)Disagree(0)Comment