{"API Licensing"}

Tracking On Licensing For The Solutions In My OpenAPI Toolbox

I wanted to provide an easy way to publish and share some of the tools that I'm tracking on in the OpenAPI ecosystem, so I launched my API toolbox. In addition to tracking on the name, description, logo, and URL for OpenAPI tooling, I also wanted to categorize them, helping me better understand the different types of tools that are emerging. As I do with all my research, I published the OpenAPI Toolbox as a Github repository, leveraging its YAML data core to store all the tools

It will be a never ending project for me to add, update, and archive abandoned projects, but before I got too far down the road I wanted to also begin tracking on the license for each of the tools. I'm still deciding whether or not I want the toolbox to exclusively contain openly licensed tools, or look to provide a more comprehensive directory of tooling that includes unknown and proprietary solutions. I think for now I will just flag any tool I cannot find a license for, and follow up with the owner--it gives me a good excuse to reach out and see if there is anyone home.

Eventually, I want to also provide a search for the toolbox that allows users to search for tools and filter by license. Most of the tools have been Apache 2.0 or MIT license, details that I will continue to keep tracking and reporting on. If you know of any tooling that employs the OpenAPI Specification that should be included feel free to submit a Github issue for the project, or submit a pull request on the repository and add it to the YAML data file that drives that OpenAPI Toolbox.

See The Full Blog Post


IoT Extends Software Terms of Service And Licensing To Our Every Day Objects

I find myself thinking about what the terms of service we agree to for online services are doing to our lives. Whether we see the effects or not, they are guiding almost everything we do in our personal and professional worlds. They are something that began on our desktop computers, migrated to our more mobile laptops, then deeper into our personal lives via our mobile smartphones.

We rarely understand what we are agreeing to when we check the box for these terms of service, which leaves me really surprised to see us accept the application of terms of service to everyday objects we depend on, as part of the Internet of Things movement. As physical objects in our lives get connected to the Internet, they begin to generate valuable data, requiring software to manage--all being directed by the terms of service set forth by the manufacturer. 

You can see this playing out as manufacturers like GM and John Deer are limiting what you can do with their physically connected equipment. These terms of service are changing the meaning of ownership, and evolving te physical things we purchase into subscriptions, instead of outright ownership. Following the tone of the conversation set by terms of service which is guiding software, this new breed of terms of service being applied to physical objects in a way that heavily benefits manufacturers, shifting as much the risk as possible to the consumers, leaving many of the benefits as possible for themselves.

In the rapidly expanding online and mobile worlds we (consumers) have almost no tools that help us manage the terms of service we are agreeing to, and almost no leverage when it comes to how these are crafted, changed, and applied. Why the hell would we keep this rapid pace continuing into the physical world, as well as our online worlds? It just doesn't pencil out? Especially when you consider how we give up so much of our privacy, security, and ownership as in agreeing to these terms of service.

How terms of service are applied to virtual and increasingly physical objects that are being connected to the Internet are much like algorithms, as they are often coded black boxes that we do not always understand. I will keep tracking on them the best I can, but as a community, we need a lot more resources if we are going to shift the balance of all of this more in the favor of the average consumer.

See The Full Blog Post


What Licensing Should I Be Considering When I Take Open Source Software And Offer Up As An API?

I've done this a couple of times now. I took PhantomJS, and created my Screenshot API, and used ImageMagick to create my Image Manipulation API. These are two openly licensed software solutions, which I took, and am using as an API. 

What are my licensing considerations? If I keep my server side code licensed according to the specifications, am I fine? PhantomJS is licensed under BSD, and ImageMagick is Apache 2.0. Does the licensing extend itself to the commercial services I would potentially offer via an API interface? There are lots of questions to satisfy, before I move forward--I guess I am looking for a precedent.

I am evaluating at a number of openly licensed software solutions right now to deliver a variety of stops along the API life-cycle, ranging from design, to deployment, virtualization, and much more. As always, I am trying to better understand the layers involved, and how software licenses, patent, and potentially copyright might apply.

Just putting it out there to the universe, and curious to see what comes back.

See The Full Blog Post


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.

  • Apache - The Apache License is a free software license written by the Apache Software Foundation (ASF). The Apache License requires preservation of the copyright notice and disclaimer. Like other free software licenses, the license allows the user of the software the freedom to use the software for any purpose, to distribute it, to modify it, and to distribute modified versions of the software, under the terms of the license, without concern for royalties.
  • GPL - The GNU General Public License (GNU GPL or GPL) is the most widely used[6] free software license, which guarantees end users (individuals, organizations, companies) the freedoms to run, study, share (copy), and modify the software. Software that allows these rights is called free software and, if the software is copylefted, requires those rights to be retained.
  • MIT - The MIT License is a free software license originating at the Massachusetts Institute of Technology (MIT). It is a permissive free software license, meaning that it permits reuse within proprietary software provided all copies of the licensed software include a copy of the MIT License terms and the copyright notice.

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.

  • CC BY - This license lets others distribute, remix, tweak, and build upon your work, even commercially, as long as they credit you for the original creation. This is the most accommodating of licenses offered.
  • CC BY-SA - This license lets others remix, tweak, and build upon your work even for commercial purposes, as long as they credit you and license their new creations under the identical terms. This license is often compared to copyleft free and open source software licenses. All new works based on yours will carry the same license, so any derivatives will also allow commercial use.
  • CC0 - Use this universal tool if you are a holder of copyright or database rights, and you wish to waive all your interests in your work worldwide.

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.

  • CC BY - This license lets others distribute, remix, tweak, and build upon your work, even commercially, as long as they credit you for the original creation. This is the most accommodating of licenses offered.
  • CC BY-SA - This license lets others remix, tweak, and build upon your work even for commercial purposes, as long as they credit you and license their new creations under the identical terms. This license is often compared to copyleft free and open source software licenses. All new works based on yours will carry the same license, so any derivatives will also allow commercial use.
  • CC0 - Use this universal tool if you are a holder of copyright or database rights, and you wish to waive all your interests in your work worldwide.

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.

  • Apache - The Apache License is a free software license written by the Apache Software Foundation (ASF). The Apache License requires preservation of the copyright notice and disclaimer. Like other free software licenses, the license allows the user of the software the freedom to use the software for any purpose, to distribute it, to modify it, and to distribute modified versions of the software, under the terms of the license, without concern for royalties.
  • GPL - The GNU General Public License (GNU GPL or GPL) is the most widely used[6] free software license, which guarantees end users (individuals, organizations, companies) the freedoms to run, study, share (copy), and modify the software. Software that allows these rights is called free software and, if the software is copylefted, requires those rights to be retained.
  • MIT - The MIT License is a free software license originating at the Massachusetts Institute of Technology (MIT). It is a permissive free software license, meaning that it permits reuse within proprietary software provided all copies of the licensed software include a copy of the MIT License terms and the copyright notice.

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.

See The Full Blog Post


A Better Understanding When It Comes To Licensing Of Data Served Up Through APIs

Through my work on API Evangelist, and heavy reliance on Github, I have a pretty good handle on the licensing of code involved with APIs--I recommend following Githubs advice. Also derived from my work on the Oracle v Google copyright case, and the creation of API Commons, I have a solid handle on licensing of API interfaces. One area I am currently deficient, and is something that has long been on my todo list, is establishing a clear stance on how to license data served up via APIs.

My goal is to eventually craft a static page, that helps API providers, and consumers, better understand licensing for the entire stack, from database, to server, the API definition, all the way to the client. I rely on the Open Data Commons, for three licensing options for open data:

I am adding these three licensing options to my politics of APIs research, and will work to publish a single research project that provides guidance in not just licensing of data served up through APIs, but also addresses code, definitions, schemas, and more. 

The guidance from Open Data Commons is meant for data owners who are looking to license their data before making available via an API, if you are working with an existing dataset, makes sure and consult the data source on licensing restrictions--making sure to carry these forward as you do any additional work.

See The Full Blog Post


Taking A Look At The API Licensing Stack

One of the byproducts of the Oracle vs Google API copyright case, was a realization that many API providers and consumer do not understand the layers of the API stack, let alone the potential licensing considerations for each layer of the API onion. I wouldn't just blame API providers, and consumers, I’m still getting a grasp on all of this, which is why I'm blogging about the subject.

Let’s take a quick crack at defining the layers to the potential API licensing onion:

  • Data - What is the licensing for the actual data returned and collected by an API? I’m still learning about the ways to license your data, and the Open Data Commons provides some guidance in this area, while others feel that your data can just as be easily licensed using Creative Commons licensing.
  • Data Model - The separation between data and its data model can be hard to see, where in reality end-users may own their data, but the order and structure of it can be owned by the originating application. If this layer is a concern, Creative Commons, or other copyright options should be considered.
  • Server - Server side API code is the core of any API operations, and should be licensed accordingly using common open source software licenses when appropriate. However I would add that this is the one layer in the API stack where a proprietary licensing could make sense, but the rest of the stack should always be licensed as open as possible.
  • Interface - The separation between the API and its surface area is important, and is something that is just becoming relevant with the Oracle v Google copyright case. Understanding the importance of an openly licensed surface area, is essential to the health of any API stack, and should be kep as open as possible, even when associated with a proprietary API backend. This is why we started API commons, to help API providers take a stance on the license of the surface area of the API stack.
  • Clients - As with server side code, you should apply common open source software licensing to client code when appropriate, but your client code samples, libraries and SDKs should never be licensed in a proprietary way, encouraging implementation for any commercial integration.

In this scenario we are talking about a purely data API, if you are serving up some sort of programmatic resource, things might be different. My goal is to just try and understand the separation between the API layers, and apply some thoughts on how licenses can be applied to open, or possibly close access and constraint an APIs operation.

Much like other political building blocks of the API ecosystem, licensing in the aPI stack can be good, bad, or neutral. In the end, regardless of your stance I think it is important to have an open conversation about how our API stack is licensed, so that your consumers can better understand what they are in for.

See The Full Blog Post


What Is Your API Content Licensing Default?

I was taking another look at the Makerbot Thingiverse API the other day, and was very pleased with their developer area overhaul. One feature I noticed when playing with my account settings, was the ability to set the default licensing for my "things".

Interestingly this is a feature you don't see in many SaaS apps, let alone as part of API developer settings. I remember first seeing this in my Flickr account settings, and is something I wish I’d see it in every platform I use (keep dream'n buddy).

When it comes to user generated content via APIs, this licensing is kind of a big deal. It decides as a user and developer, who ultimately owns the exhaust from your work or just from your daily online world.

I'll be including licensing considerations in the future discussions around the politics of APIs. A setting to determine how user generated content is licensed should not just be a setting in your application account settings, but baked into API developer account settings as well.

See The Full Blog Post