This website is currently dormant!

API Definitions News

These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is defining not just their APIs, but their schema, and other moving parts of their API operations.

Locking Up Any Open Data Taxonomy Is Short Sighted In Todays Online Environment

I published a taxonomy API as part of my Human Services Data API (HSDA) work recently, and as part of the work I wanted it to support a handful of the human services taxonomies available currently. The most supported taxonomy available out there is the AIRS/211 LA County Taxonomy. It is a taxonomy in use by 211 of LA County, as well as owned and licensed by them. From what I gather, it is the most common format in use, and you can find licensing pages for it from other municipal 211 providers. Before you can download a copy of the taxonomy you have to agree to the license I’ve posted at the bottom of this post, something I was unwilling to do.

Taxonomies shouldn’t be locked up this way. Let alone taxonomies for use in open data, helping citizens at the municipal level. I understand that 211 LA will argue that they’ve put a bunch of work into the schema, and therefore they want to protect what they view their intellectual property, but in 2017 this is wrong. This isn’t the way things should be done, sorry. The AIRS taxonomy should be openly available, and reusable in a machine readable format, and evolved by an open governance process. There is no reason for this valuable taxonomy, that has the potential to make our cities better, should be locked up like this–it needs to be widely used, and adopted without any legal friction along the way.

I understand that it takes work, and resources to keep a taxonomy meaningful, and usable, but we should not stand in the way of people finding human services, and restricting 211 providers from using the same vocabulary. There are other was to generate revenue, and evolve forward a taxonomy in an online, collaborative environment, much like we are currently doing with open source software. This kind of stuff drives me nuts, and the licensing around this important technology is something I’ll keep an eye on, and contributing whatever I can to help stimulate the discussion in favor of open sourcing. In the absence of AIRS, I have adopted an open source 211 taxonomy called Open Eligibility, but alas it seems like an effort that has gone dormant. I have forked the specification, added more simpler JSON, CSV, and JSON formats which I will be working with it alongside the rest of my Human Services Data API (HSDA) taxonomy work.

Taxonomy licensing is another area of consideration I’ll add to my API licensing research, as well as for guidance around my HSDA work. I wish this type of stuff didn’t still happen in 2017. It is a relic of another time, and in a digital age, taxonomies for any aspect of public infrastructure should be openly licensed, and reusable by everyone. I would like to see Open Referral expand its portfolio to push forward one or more taxonomies for not just human services, but also organizations, locations, and potentially other relevant schema we are pushing forward. I see Open Referral as an incubator for schema, OpenAPI definitions, as well as datasets like 211 taxonomy, helping provide a commons where 211 organizations can find what they need.



Taxonomy Subscription Agreement (“Agreement”) contains the terms and conditions by which Information and Referral Federation of Los Angeles, Inc., doing business as 211 of LA County (“211 LA”) provides a subscription license to use the Taxonomy. This Agreement is a binding legal contract between you (both the individual downloading, installing and/or using the Taxonomy and, if applicable, the legal entity on behalf of which such individual is acting) (“Subscriber”) and 211 LA.


Subscriber Database means a database of health and human services information and resources that is created and maintained by Subscriber.

Subscriber Directory means a printed directory or electronic read-only directory of health and human services that is created and maintained by Subscriber using a Subscriber Database. As used in this definition, “read-only” means an electronic version of a directory in which the information in such directory, including the Taxonomy, cannot be modified or altered in any way.

Subscription Order Form means the form(s) used by 211 LA for allowing subscribers to purchase or renew subscription licenses of the Taxonomy.

Taxonomy means the Taxonomy of Human Services maintained and made generally available by 211 LA for purposes of indexing health and human services information and resources, including its terms, definitions, codes and references and any and all updates, upgrades, enhancements or other modifications that may be made available by 211 LA to Subscriber from time to time.

Taxonomy Website means a website hosted by 211 LA through which subscription licenses for the Taxonomy can be purchased and the Taxonomy can be downloaded.

2.Taxonomy License.

Limited License. Subject to Subscriber’s compliance with the terms and conditions of this Agreement (including, without limitation, Sections 2.2, 2.3, 3 and 4), 211 LA hereby grants to Subscriber a limited, non-exclusive, non-transferable, non-sublicensable license to:

access portions of the Taxonomy Website designated by 211 LA for subscribers and download the Taxonomy as made generally available thereon;

use the Taxonomy, including its codes, terms, definitions, and references, as a classification structure for indexing health and human services information and resources in a Subscriber Database;

include Taxonomy terms in a survey instrument prepared by Subscriber as reasonably necessary to collect information from third party organizations regarding health and human services, provided that such survey instrument may only include the Taxonomy terms that Subscriber has used to index health and human services information and resources in the Subscriber Database;

include Taxonomy terms as an index in a Subscriber Directory distributed or otherwise made available to third parties (including over the Internet), provided that (i) the proceeds of any monetary or other consideration provided in connection with such distribution are provided to a non-profit, charitable organization and (ii) any such Subscriber Directory may only include the Taxonomy terms that Subscriber has used to index health and human services information and resources in the Subscriber Database, along with any higher level terms on the same branch that are needed to display the hierarchical structure; and

include the Taxonomy definitions in the Subscriber Directory referenced in Section 2.1(d) above, provided that such Subscriber Directory may include only those definitions for terms that Subscriber has used to index health and human services information and resources in the Subscriber Database.

License Restrictions. Nothing contained in this Agreement will be construed as conferring upon Subscriber, by implication, operation of law or otherwise, any license or other rights except as expressly set forth in Section 2.1. Subscriber shall not, and shall not allow any third party to: (i) copy, display or otherwise use all or any portion of the Taxonomy except as incorporated into a Subscriber Directory as permitted in Section 2.1; (ii) transmit or otherwise distribute the Taxonomy (or any portion of the Taxonomy) as a separate product, module or material to any end user or other third party, or make the Taxonomy (or any portion of the Taxonomy) available to any end user or other third party as a downloadable file separate from a Subscriber Directory; (iii) transmit or otherwise distribute any portion of the Taxonomy for commercial purposes or otherwise for profit or other monetary gain; (iv) incorporate the Taxonomy (or any portion of the Taxonomy) into any database or software through which the Taxonomy (or any portion of the Taxonomy) can be printed, downloaded or modified; or (v) loan, lease, resell, sell, offer for sale, sublicense, adapt, translate, create derivative works of or otherwise modify or alter all or any part of the Taxonomy. Further, Subscriber acknowledges and agrees that use of the Taxonomy Website is also subject to 211 LA’s Terms of Use, as made available thereon and updated from time to time.


If the Taxonomy, or any potion of the Taxonomy (including its terms, codes, definitions or references), are utilized in a Subscriber Directory that is published, transmitted, distributed or otherwise made available to third parties, by any means or medium, the Subscriber shall prominently display the following notice in such directory:

Copyright © 1983-2007, Information and Referral Federal of Los Angeles County, Inc. All rights reserved. The index, codes and definitions of the terms contained herein are the intellectual property of Information and Referral Federal of Los Angeles, Inc. and are protected by copyright and other intellectual property laws. No part of this listing of human services terms and definitions may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electrical, mechanical, photocopying, recording or otherwise without the prior written permission of the Information and Referral Federal of Los Angeles County, Inc.

If the Taxonomy is displayed or otherwise made available in a Subscriber Directory via the Internet, Subscriber shall prominently include a link to a copyright acknowledgement statement that 211 LA maintains online, currently located at:

3.Intellectual Property Ownership.

Ownership of the Taxonomy. As between 211 LA and Subscriber, 211 LA retains and shall own all right, title and interest in and to the Taxonomy and any derivative works or other modifications thereof, including, without limitation, all copyright, trademark, trade secret and other intellectual rights, subject only to the limited license set forth herein. Subscriber does not acquire any other rights, express or implied, in the Taxonomy. Subscriber hereby assigns, and agrees to assign, to 211 LA all right, title and interest (including all intellectual property rights) throughout the world that Subscriber has or may have in the Taxonomy (including with respect to any modifications suggested by, or other contributions made by, Subscriber), which assignment shall be deemed effective as to any future modifications or contributions immediately upon the creation thereof. Subscriber further irrevocably waives any “moral rights” or other rights with respect to attribution of authorship or integrity of any modifications suggested by, or other contributions made by, Subscriber under any applicable law under any legal theory.

Access and Security.

Subscriber is solely responsible for providing, installing and maintaining at Subscriber’s own expense all equipment, facilities and services necessary to access and use the Taxonomy, including, without limitation, all computer hardware and software, modems, telephone service and Internet access.

Subscriber may be issued or otherwise assigned a user identification and/or password (collectively, “User Identifications “) to access the Taxonomy and/or Taxonomy Website as permitted hereunder. Subscriber is solely responsible for tracking all use of the User Identifications and for ensuring the security and confidentiality of all User Identifications. Subscriber acknowledges that Subscriber is fully responsible for all liabilities incurred through the use of any User Identification and that any download, transmission or transaction under a User Identification will be deemed to have been performed by Subscriber.

Subscriber shall ensure that each of its employees complies with this Agreement, including, without limitation, the license restrictions in Section 2.2 and shall protect the Taxonomy from any use that is not permitted under this Agreement. Subscriber shall promptly notify 211 LA of any unauthorized copying, display, modification, transmission, distribution, or use of the Taxonomy of which it becomes aware.

211 LA reserves the right at any time and without prior notice to Subscriber to change the hours of operation of the Taxonomy Website or to limit Subscriber’s access to the Taxonomy (i) in order to perform repairs or to make updates, upgrades, enhancements or other modifications or (ii) in response to unforeseen circumstances or circumstances beyond 211 LA’s reasonable control. 211 LA may add or withdraw elements of to or from the Taxonomy and/or Taxonomy Website from time to time in its sole discretion, although Subscriber acknowledges and agrees that 211 LA has no obligation to maintain or provide any updates, upgrades, enhancements, or other modifications to the Taxonomy or Taxonomy Website.

Verification. 211 LA may, during the term of this Agreement and with seven (7) days prior notice, request and gain access to Subscriber’s premises for the limited purpose of conducting an inspection to determine and verify that Subscriber is in compliance with the terms and conditions hereof. Subscriber shall promptly grant such access and cooperate with 211 LA in the inspection; provided, however, the inspection shall be conducted in a manner not intended to disrupt unreasonably Subscriber’s business and shall be restricted in scope, manner and duration to that reasonably necessary to achieve its purpose.


Payment. In consideration for the subscription license granted under Section 2.1, Subscriber shall pay the applicable fees as set forth in the Subscription Order Form and/or Taxonomy Website. All fees are nonrefundable. Any information that you may provide in connection with obtaining the subscription (including any nonprofit and/or AIRS membership information) may be verified and your subscription license may be placed on hold or terminated in the event of inaccuracies or discrepancies.

Taxes. In addition to all applicable fees, Subscriber shall pay all sales, use, personal property and other taxes resulting from this Agreement or any activities under this Agreement, excluding taxes based on 211 LA’s net income, unless Subscriber furnishes proof of exemption from payment of such taxes in a form reasonably acceptable to 211 LA. Further, If Subscriber is required by law to deduct or withhold any taxes, levies, imposts, fees, assessments, deductions or charges from or in respect of any amounts payable hereunder, (a) Subscriber shall pay the relevant taxation authority the minimum amounts necessary to comply with the applicable law, (b) Subscriber shall make such payment prior to the date on which interest or penalty is attached thereto, and (c) the amounts payable hereunder shall be increased as may be necessary so that after Subscriber makes all required deductions or withholdings, 211 LA shall receive amounts equal to the amounts it would have received had no such deductions or withholdings been required.

Discounts. From time to time, and in 211 LA’s sole discretion, 211 LA may offer discounts to particular organizations (such as nonprofits, government agencies and members of the Alliance of Information and Referral Systems (AIRS)). If such a discount is offered to Subscriber, Subscriber may be required to submit proof of nonprofit status (such as a federal EIN number), a valid AIRS membership number and/or additional information in order to receive such discounts.

Delivery. The Taxonomy is only made available electronically via download from the Taxonomy Website and, unless otherwise agreed by 211 LA in writing on a case-by-case basis, will not be delivered in any other form or via in any other method.

5.Term and Termination

Term. Subscriber’s rights with respect to the Taxonomy will commence on the date full payment of license fees are received and approved by 211 LA and will continue for an initial period of one (1) year, at which point Subscriber’s rights and this Agreement shall expire. If available, Subscriber may renew its subscription license via the Taxonomy Website, which renewal will be subject to and governed by 211 LA’s then-current fees and then-current terms and conditions (which may include a new or updated Taxonomy Subscription Agreement).

Termination of Agreement. Subscriber may terminate this Agreement at any time by sending an email message addressed to [email protected], with the subject “Subscription Cancellation.” Further, if Subscriber commits any breach of any provision of this Agreement, 211 LA will have the right to terminate this Agreement (including the rights granted to Subscriber under 2.1) by written notice, unless Subscriber remedies such breach to 211 LA’s reasonable satisfaction within thirty (30) calendar days after receiving written notice from 211 LA.

Effect of Termination.

Upon termination or expiration, and except as expressly provided in Section 5.3(b), the rights and license granted to Subscriber hereunder shall immediately cease and Subscriber will immediately cease all use of the Taxonomy, will destroy all copies of the Taxonomy and will promptly certify such action to 211 LA in writing. Without limitation of the foregoing, 211 LA may immediately terminate Subscriber’s account and ability to access the Taxonomy via the Taxonomy Website upon any expiration or termination of this Agreement. Expiration or termination of this Agreement will not limit either party from pursuing other remedies available to it, including injunctive relief.

The parties’ rights and obligations under Sections 2.2, 3, 4, 5.3, 6, and 7 will survive expiration or termination of this Agreement. Further, unless this Agreement has been terminated by 211 LA for breach, the rights granted to Subscriber under Sections 2.1(b) through (e), as well as the rights and obligations set forth in Section 2.3, shall survive and continue following any expiration or termination of this Agreement, but only with respect to the most recent version of the Taxonomy downloaded by Subscriber from the Taxonomy Website as of the date of expiration or termination and provided that Subscriber’s rights shall continue to be subject to termination by 211 LA under Section 5.2.

6.Disclaimer of Warranty and Limitation of Liability.



7.Miscellaneous Provisions

No Assignment. Subscriber may not assign, sell, transfer, delegate or otherwise dispose of, whether voluntarily or involuntarily, by operation of law or otherwise, this Agreement, or any rights or obligations under this Agreement. Any purported assignment, transfer, or delegation by Subscriber will be null and void. Subject to the foregoing, this Agreement will be binding on the parties and their respective successors and assigns.

Relationship Between the Parties. The parties shall at all times be and remain independent contractors. Nothing in this Agreement creates a partnership, joint venture or agency relationship between the parties.

Governing Law. This Agreement is to be construed in accordance with and governed by the internal laws of the State of California (as permitted by Section 1646.5 of the California Civil Code (or any similar successor provision)) without giving effect to any choice of law rule that would cause the application of the laws of any jurisdiction other than the internal laws of the State of California to the rights and duties of the parties. In the event of any controversy, claim or dispute between the parties arising out of or relating to this agreement, such controversy, claim or dispute may be tried solely in a state or federal court located within the County of Los Angeles, California and the parties hereby irrevocably consent to the jurisdiction and venue of such courts.

Severability and Waiver. If any provision of this Agreement is held to be illegal, invalid, or otherwise unenforceable, such provision will be enforced to the extent possible consistent with the stated intention of the parties, or, if incapable of such enforcement, will be deemed to be severed and deleted from this Agreement, while the remainder of this Agreement will continue in full force and effect. The waiver by either party of any default or breach of this Agreement will not constitute a waiver of any other or subsequent default or breach.

Headings. The headings used in this Agreement are for convenience only and shall not be considered in construing or interpreting this Agreement.

No Third Party Beneficiaries. This Agreement is made and entered into for the sole protection and benefit of the parties hereto, and is not intended to convey any rights or benefits to any third Party, nor will this Agreement be interpreted to convey any rights or benefits to any person except the parties hereto.

Entire Agreement. This Agreement, along with the Terms of Use made available on the Taxonomy Website, constitutes the complete agreement between the parties and supersedes any prior or contemporaneous agreements or representations, whether written or oral, concerning the subject matter of this Agreement. This Agreement may be changed by 211LA from time to time immediately upon notice to Subscriber (which may be achieved by posting an updated copy of this Agreement on the Taxonomy Website) or by written agreement of the parties. Continued use of the subscriber portions of the Taxonomy Website following any change constitutes acceptance of the change.

API SDK Licensing Notifications Using VersionEye

I have been watching VersionEye for a while now. If you aren’t familiar, they provide a service that will notify you of security vulnerabilities, license violations and out-dated dependencies in your Git repositories. I wanted to craft a story specifically about their licensing notification services, which can check all your open source dependencies against a license white list, then notify you of violations, and changes at the SDK licensing level.

The first thing I like here, is the notion of an API SDK licensing whitelist. The idea that there is a service that could potentially let you know which API providers have SDKs that are licensed in a way that meets your integration requirements. I think it helps developers who are building applications on top of APIs understand which APIs they should or shouldn’t be using based upon SDK licensing, while also providing an incentive for API providers to get their SDKs organized, including the licensing–you’d be surprised at how many API providers do not have their SDK house in order.

VersionEye also provides CI/CD integration, so that you can stop a build based on a licensing violation. Injecting the politics of API operations, from an API consumers perspective, into the application lifecycle. I’m interested in VersionEye’s CI/CD, as well as security vulnerabilities, but I wanted to make sure this approach to keeping an eye on SDK licensing was included in my SDK, monitoring, and licensing research, influencing my storytelling across these areas. Some day all API providers will have a wide variety of SDKs available, each complete with clear licensing, published on Github, and indexed as part of an APIs.json. We just aren’t quite there yet, and we need more services like VersionEye to help build awareness at the API SDK licensing level to get us closer to this reality.

Github Helping Set The Bar For Your API Community Code Standards

Github has released an interesting new feature to help users better manage some of the community elements of the repositories they use to manage code, definitions, data, and content across API operations. For each repository, you now have a community profile tab, where you’ll see a checklist showing how your project compares to Github recommended community standards.

If you are lacking one of these common elements, it gives you an option to quickly add one of the missing pieces. I still have some repositories where I don’t properly have licensing dictated, even a handful without a README (I know). Almost none of my repositories have a code of conduct or contributing agreement. The new feature adds another task to my list of maintenance items I’ll be tackling to help standardize the projects I manage on Github (which is everything I do).

I like where Github is going with this. It resembles what I am trying to do with API projects by identifying the common building blocks of API deployments, providing a checklist that API providers can follow when publishing their APIs–which is often done using Github. One way that API providers can help standardize these common elements across groups is to create a working API portal prototype that is forkable on Github, similar to what the GSA is doing for the federal government with their working API prototype.

Most of the time API architects and eveloper just need a friendly reminder, or possibly a working example they can follow when it comes to standardizing how we deploy and manage the community elements of our API operations. I hope what Github is doing with their community standards baseline will keep evolving, spreading, and eventually be something that Github organizations can templatize, standardize, and define their own criteria regarding the minimum viable aspects of community operations for the repositories they have on Github.

Proprietary Views Of Your Taxonomy

I’ve been investing a lot more energy into open data and APIs involved with city government, something I’ve dabbled in as long as I’ve been doing API Evangelist, but is something I’ve ratcheted up pretty significantly over the last couple of years. As part of this work, I’ve increasingly come across some pretty proprietary stances when it comes to data that is part of city operations–this stuff has been seen as gold, long before Silicon Valley came along, with long lines of folks looking to lock it up and control it.

Helping civic data stakeholders separate the licensing layers around their open data and APIs is something I do as the API Evangelist. Another layer I will be adding to this discussion is around taxonomy. How city data folks are categorizing, organizing, and classifying the valuable data needed to make our cities work. I’ve been coming across more vendors in the city open data world who feel their taxonomy is their secret sauce and falls under intellectual property protection. I don’t have any wisdom regarding why this is a bad idea, but I will keep writing about as part of my wider API licensing work to help flesh out my ideas, and create a more coherent and precise argument.

I understand that some companies put a lot of work into taxonomies, and the description behind how they organize things, but like API definitions and schema, these are aspects of your open data and API operations you want to be a widely understood, shared, and reusable knowledge within your systems, as well as the 3rd party integration of your partners and customers. Making your taxonomy proprietary isn’t going to help your brand, or get you ahead in the game. I recommend focusing on other aspects of the value you bring to the table and keep your taxonomy as openly licensed as you possibly can, encouraging adoption by others. I’ll work on a more robust argument as I work through a variety of projects that will potentially be hurt by the proprietary views on taxonomy I’m seeing.

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.

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.

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.

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.

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.

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.

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.

If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.