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:
- 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.
- 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 »
