Swagger is now Open API Definition Format (OADF) -- READ MORE
I’ve long been fascinated by the Terms of Service Didn’t Read project. i’m on the mailing list, and try to make time to stay in tune, but have yet to ever contribute any bandwidth to the EXTREMELY important project, around making sense of the crazy terms of services (TOS), that we agree to in our daily lives.
I finally found myself at a point where I'm forced to start paying more attention to API terms of service, and hopefully will be able to slice off a little bit of dedicated bandwidth to Terms of Service; Didn’t Read. I have two projects that have floated up on my list, and deserve some priority attention.
First I’m applying the TOS Didn't Read work to a side project of mine called Reclaim Your Domain, which is a project to help me define my digital self, and reclaim some of the content, data and other value I generate on a daily basis online. I’m hoping TOS Didn't Read will provide a machine readable moral backbone to the #Reclaim process—which is a work in progress.
Second, I’m looking to build on the TOS Didn't Read work, and apply further to the world of APIs, by defining another one of the machine readable API.json properties. The first of which are machine readable properties like API Blueprint, RAML, and Swagger API definitions, and the API Commons manifest, which allows you to reference the copyright for a specific API interface.
I want to build on the work TOS Didn’t Read has done, apply their tracking and ranking system of online services, to the APIs that I monitor. Using APIs.json I want to encourage API providers to publish this machine readable index of their available APIs, allowing them to be indexed by API search engines like APIs.io. Then, as part of each APIs.json I want to help API providers understand the benefits of machine readable API definitions, API copyright declarations, and API terms of service (TOS). I know, that is a pretty tall order, but I think it can be done.
TOS Didn't Read provides me with a wealth of topics, and detailed points to apply when evaluating API provider’s terms of service—which is an excellent foundation to build on top of. I've forked the TOS Didn't Read repository, as part of the APIs.json organization, and will be establishing a supporting project for defining what a machine readable terms of service file might look like. I think I will call this project Terms of Service; Machine Readable, or TOS;MR.
My goal is to provide a meaningful list of questions (TOS;DR topics & points), that we can use to quantify API providers. I want to enable API providers to answer these questions, and publish a machine readable list of relevant topics somewhere in their domain, and include as a property in their APIs.json file.
Ok, I have a lot of work. Luckily I'm not entirely re-inventing the wheel here. I’m building on the existing work of TOS Didn't read, but applying specifically to APIs, and connecting it to my existing API discovery work with APIs.json.
Updated November 27, 2015: Links were updated as part of switch from Swagger to OADF (READ MORE)