{"API Evangelist"}

Thinking Through The Licensing For An API Stack

I've spent a lot of time thinking through the licensing we apply to APIs, as part of my work on the Oracle v Google API copyright case. The licensing around APIs is still in flux, with the current precedent being that APIs are copyrightable. Even though I do not believe this stance, I encourage API designers to make sure and apply one of the more liberal Creative Commons licenses to your API definitions, taking a pre-emptive stance in the conversation.

In my experience most API providers, let alone consumers and the public at large, do not understand the separation between an APIs definition, and the code that runs the API, and often even the code that consumes an API. To help us visualize the separation, as well as think through the licensing implications of each layer, I have setup a specific research project that addresses API licensing, in hopes of spending time regularly researching the topic, as well as telling stories that help people navigate how to license their APIs.

Here is how I'd break down the five most common layers of the API licensing stack, and some ideas for how you can apply licenses to these layers of API operations.

Server Code - For many APIs, your server code will be your secret sauce and kept proprietary, but for those of you who wish to open source this critical layer, here are some options. To help you navigate the licensing, I recommend using Github's Choose a License.

Data - Serving up data is one of the most common reasons for deploying an API, and the Open Data Commons, provides us with some licensing options.

Content - Separate from the data, APIs are being used to server up short, and long form content, where liberal Creative Common licenses should be considered.

API Definition - The part of the discussion be defined (unfortunately) by the Oracle v Google Java API copyright legal battle, and in light of the ruling, I urge you to consider one of the more liberal Creative Common licenses.

Client Code - Separate from your server side code, you should make sure all of your client side code SDKs, PDKs, and starter kits have an open source license applied-o-remember you are asking them to potentially integrate this into their business operations. Again I recommend using Github's Choose a License to help you navigate this decision.

This list does not reflect all of the licensing opportunities available to you. These reflect the licensing options that I recommend you consider, as part of your API operations. I want as many APIs to thoughtfully consider the licensing for their entire API stack, and I'm kick-starting these research to provide a short, concise guide for API providers to consider. 

If I get my way, every layer of the API stack will be licensed as openly as possible, however I add some extra concern for the API definition layer. I know many of my readers will argue that this is just code, and should be licensed along side your server side code, but this is not true-modern API definitions are increasingly available as JSON, YAML, Markdown, that is telling a very important story that is having a significant impact on how we do business, and live our personal lives--a story that should be able to retold and echoed across the digital landscape, without licensing restrictions.

My API licensing research is just getting going. I will be rounding it off with examples of the approach used by leading API providers, news and stories I curated from across the space, as well as more API Commons tooling that helps you define the licensing for your API, and share in a machine readable way.