These are the news items I've curated in my monitoring of the API space that have some relevance to the terms of service conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is testing their APIs, going beyond just monitoring and understand the details of each request and response.01 May 2018
I’ve been tracking on the terms of service for APIs for eight years, but I haven’t ever come across a terms of service API. I found one the other day while looking through the Box API, and thought it was worth showcasing as part of my research. The Box terms of service API, “allows Box Admins to configure ToS and end users to accept / re-accept ToS for custom applications.” The Box terms of service API represents the association between Terms of Services and users, providing several different configurations:
- There is exactly one Terms of Service User Status for a given Terms of Service and a given user.
- There are multiple Terms of Service User Statuses for a given Terms of Service (e.g. one per each user).
- There could be multiple Terms of Service User Statuses for a given user. The user could accept/reject multiple external ToS for enterprises they have been collaborated into in addition to accepting/rejecting their own enterprise’s managed ToS.
The Box terms of service API allows for managing multiple terms of service, and multiple users engagement with those terms of service. Providing eight separate API endpoints for managing each individual terms of service, and the users agreement to them. I’d like to see a more modular approach to managing the components of each terms of service, as it applies to APIs. Allowing for more reusable terms of service modules that can be reused across many different APIs. I’m thinking beyond just documents and their applications, I am thinking about widely applied across APIs and any application that can be built on them.
I’m going to add Box’s terms of service API definition to my research, and use as a base for other potential use cases. It is one of those areas I feel like need some investment in, to help make this layer of API operations more observable. Every building block of the API platform should have an API in my opinion, especially the terms of service layer. It is an API pattern I’d like see exist in the API space, and is an API definition I’ll add to to help make more applicable, and forkable so that API providers can implement their own terms of service API.
I received a tweet from my friend Kelly Taylor with USDS, asking for any information regarding establishing an “approve access to production data” for developers. He is working on an OAuth + FHIR implementation for the Centers for Medicare and Medicaid Services (CMS) Blue Button API. Establishing a standard approach for on-boarding developers into a production environment always makes sense, as you don’t want to give access to sensitive information without making sure the company, developer, and application has been thoroughly vetted.
As I do with my work, I wanted to think through some of the approaches I’ve come across in my research, and share some tips and best practices. The Blue Button API team has a section published regarding how to get your application approved, but I wanted to see if I can expand on, while also helping share this information with other readers. This is a relevant use case that I see come up regularly in healthcare, financial, education, and other mainstream industries.
Virtualization & Sandbox The application approval conversation usually begins with ALL new developers being required to work with a sandboxed set of APIs, only providing production API access to approved developers. This requires having a complete set of virtualized APIs, mimicking exactly what would be used in production, but in a much safer, protected environment. One of the most important aspects of this virtualized environment is that there also needs to be robust sets of virtualized data, providing as much parity regarding what developers will experience when they enter the production environment. The sandbox environment needs to be as robust and reliable as the production, which is a mistake I see made over and over from providers, where the sandbox isn’t reliable, or as functional, and developers never are able to reach production status in a consistent and reliable way.
Doing a Background Check Next, as reflected in the Blue Button teams approach, you should be profiling the company and organization, as well as the individual behind each application. You see company’s like Best Buy refusing any API signup that doesn’t have an official company domain that can be verified. In addition to requiring developers provide a thorough amount of information about who they are, and who they work for, many API providers are using background and profiling services like Clearbit to obtain more details about a user based upon their email, IP address, and company domain. Enabling different types of access to API resources depending on the level of scrutiny a developer is put under. I’ve seen this level of scrutiny go all the way up to requiring the scanning of drivers license, and providing corporate documents before production access is approved.
Purpose of Application One of the most common filtering approaches I’ve seen centers around asking developer about the purpose of their application. The more detail the better. As we’ve seen from companies like Twitter, the API provider holds a lot of power when it comes to deciding what types of applications will get built, and it is up to the developer to pitch the platform, and convince them that their application will serve the mission of the organization, as well as any stakeholders, and end-users who will be leveraging the application. This process can really be a great filter for making sure developers think through what they are building, requiring them to put forth a coherent proposal, otherwise they will not be able to get full access to resources. This part of the process should be conducted early on in the application submission process, reducing frustrations for developers if their application is denied.
Syncing The Legal Department Also reflected in the Blue Button team’s approach is the syncing of the legal aspects of operating an API platform, and it’s applications. Making sure the application’s terms of service, privacy, security, cookie, branding, and other policies are in alignment with the platform. One good way of doing this is offering a white label edition of the platforms legal documents for use by the each application. Doing the heavy legal work for the application developers, while also making sure they are in sync when it comes to the legal details. Providing legal develop kits (LDK) will grow in prominence in the future, just like providing software development kits (SDK), helping streamline the legalities of operating a safe and secure API platform, with a wealth of applications in its service.
Live or Virtual Presentation Beyond the initial pitch selling an API provider on the concept of an application, I’ve seen many providers require an in-person, or virtual demo of the working application before it can be added to a production environment, and included in the application gallery. It can be tough for platform providers to test drive each application, so making the application owners do the hard work of demonstrating what an application does, and walking through all of its features is pretty common. I’ve participated on several judging panels that operate quarterly application reviews, as well as part of specific events, hackathons, and application challenges. Making demos a regular part of the application lifecycle is easier to do when you have dedicated resources in place, with a process to govern how it will all work in recurring batches, or on a set schedule.
Getting Into The Code As part of the application review process many API providers require that you actually submit your code for review via Github. Providing details on ALL dependencies, and performing code, dependency, and security scans before an application can be approved. I’ve also see this go as far as requiring the use of specific SDKs, frameworks, or include proxies within the client layer, and requiring all HTTP calls be logged as part of production applications. This process can be extended to include all cloud and SaaS solutions involved, limiting where compute, storage, and other resources can be operated. Requiring all 3rd party APIs in use be approved, or already on a white list of API providers before they can be put to use. This is obviously the most costly part of the application review process, but depending on how high the bar is being set, it is one that many providers will decide to invest in, ensuring the quality of all applications that run in a production environment.
Regular Review & Reporting One important thing about the application review process is that it isn’t a one time process. Even once an application is accepted an added into the production environment, this process will need to be repeated for each version release of the application, along with the changes to the API. Of course the renewal process might be shorter than the initial approval workflow, but auditing and regular check-in should be common, and not forgotten. This touches on the client level SDK, and API management logging needs of the platform, and that regular reporting upon application usage and activity should be available in real time, as well as part of each application renewal. API operations is always about taking advantage the real time awareness introduced at the API consumption layer, and staying in tune with the healthy, and not so healthy patterns that emerge from logging everything an application is doing.
Business Model It is common to ask application developers about their business model. The absence of a business model almost always reflects the underlying exploitation and sale of data being access or generated as part of application’s operation. Asking developers how they will make money and sustain their operations, along with regular checkins to make sure it is truly in effect, is an easy to ensure that applications are protecting the interests of the platform, its partners, and the applications end-users.
There are many other approaches I’ve seen API providers require before accepting an application into production. However, I think we should also be working hard to keep the process simple, and meaningful. Of course, we want a high bar for quality, but as with everything in the API world, there will always be compromises in how we deliver on the ground. Depending on the industry you are operating the bar will be made higher, or possibly lowered a little to allow for more innovation. I’ve included a list of some of the application review process I found across my research–showing a wide range of approaches across API providers we are all familiar with. Hopefully that helps you think through the application review process a little more. It is something I’ll write about again in the future as I push forward my research, and distill down more of the common building blocks I’m seeing across the API landscape.
Some Leading Application Review Processes
Troubling Terms of Service Changes From Washington Metropolitan Area Transit Authority (WMATA) Data APIs30 Nov 2017
I was turned onto a developing problem within the Washington Metropolitan Area Transit Authority (WMATA) around a recent terms of service change made around the transit data API by Technically DC. While the transit authority is saying the changes are business as usual and make sense for the platform, some of the developers, specifically one of the biggest API users MetroHero says the changes are targeting them specifically.
MetroHero presented what they feel are the unreasonable changes to the WMATA API terms of service in a WMATA Board Meeting recently, focusing on four main areas:
- That no user or developer can mention “WMATA” in press releases without letting WMATA first review it.
- That WMATA can gain access to any user’s applications that use the data, can audit personnel information for anyone working on those applications, and WMATA can also create their own version at any time.
- That WMATA forbids users from claiming their data is accurate, complete or timely, or claiming it is more so than WMATA’s data.
- That the transit agency may now charge users in the future for using their data.
These are all common changes I’ve seen made to API terms of service before, and are usually signs that a platform operator that is pretty out of touch with what it is like to be an API consumer, and with their own API community. It is a sign of a broken or pernicious feedback loop which leads to API providers making decisions that do lasting damage to their communities like this. These types of changes reflects the “rules of road” terms of service changes Twitter made to back in 2012. Which didn’t fully kill off the Twitter API, but set such a bad tone in the community, the company is still working to dig out of it five years later. I know platform operators feel they need to assert this level of control, but in an API community you need to learn to let go a little, communicate, and work with your community, not against them.
I’m going to work through all of these bullet points as separate stories, and try to help other API providers, as well as the WMATA understand how they might be able to handle these types of requests better. Doing it in a way that doesn’t cause irreparable damage to their communities, and still achieves their objectives. However, I will emphasize that I think if WMATA spent more time actually communicating with their developers, especially the leading ones like MetroHero, you’d probably see how ridiculous your requests area in the first place. APIs are not just about you opening up access to your data, it is about opening up access to your processes, and feedback loops, and collaborating with your community. It isn’t about command and control, and broadcasting the rules of the road for you platform–Twitter showed us this does not work well in todays environment.
Github is releasing an update to their platform Terms of Service and Corporate Terms of Service. Guess what platform their are using to manage the evolution, and release of their terms of service? Github of course! They are soliciting feedback, along with clarifications and improvements to their terms of service, with an emphasis on helping making things more readable! #nice
Github has provided a deadline for everyone to submit comments by the end of the month, then they’ll spend about a week going through the comments before making any changes. It provides a pretty useful way for any platform to manage their terms of service in a way that gives the community a voice, and provides some observability into the process for everyone else who might not feel confident enough to chime in on the process. This can go a long way towards building trust with the community, even if they don’t directly participate in the process.
Managing terms of service using Github makes sense for all providers, not just Github. It provides an open, transparent, and participatory way to move forward one of the most important documents that is governing API consumption. It is logical that the drafting, publishing, and evolution of platform terms be done out in the open, where the community can watch and participate. Pushing forward the design of the legal document in sync with the design, deployment, management, SDKs and other aspects of API operations. Bringing the legal side of things out of the shadows, and making it part of the conversation within the community.
Eventually, I’d like to see the terms of service, privacy policies, service level agreements, and other legal documents that govern API operations managed and available on Github like this. It gives the wider API community the chance to play a more significant role in hammering out the legal side of API operations, ensuring this are easier to follow and understand, and maybe even standardized across APIs. Who knows, maybe some day terms of service, privacy policies, and service level agreements will all be available in plain language, as well as machine readable YAML, shifting how the API contract will scale.
Here is another patent in my series of API related patents. I’d file this in the category as the other similar one from IBM–Patent US 8954988: Automated Assessment of Terms of Service in an API Marketplace. It is a good idea. I just don’t feel it is a good patent idea.
Title: API matchmaking using feature models Number: 09454409 Owner: International Business Machines Corporation Abstract: Software that uses machine logic based algorithms to help determine and/or prioritize an application programming interface’s (API) desirability to a user based on how closely the API’s terms of service (ToS) meet the users’ ToS preferences. The software performs the following steps: (i) receiving a set of API ToS feature information that includes identifying information for at least one API and respectively associated ToS features for each identified API; (ii) receiving ToS preference information that relates to ToS related preferences for a user; and (iii) evaluating a strength of a match between each respective API identified in the API ToS feature information set and the ToS preference information to yield a match value for each API identified in the API ToS feature information set. The ToS features include at least a first ToS field. At least one API includes multiple, alternative values in its first ToS field.
Honestly, I don’t have a problem with a company turning something like this into a feature, and even charging for it. I just wish IBM would help us solve the problem of making terms of service machine readable, so something like this is even possible. Could you imagine what would be possible if everybody’s terms of service were machine readable, and could be programmatically evaluated? We’d all be better off, and matchmaking services like this would become a viable service.
I just wish more of the energy I see go into these patent would be spent actually doing things in the API space. Providing low cost, innovative API services that businesses can use, instead of locking up ideas, filing them away with the government, so that they can be used at a later date in litigation and backdoor dealings.
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.
I’m reading a lot of API patents lately trying to understand the variety of approaches these “innovative” patent authors are using to help define the API space. Many of the API patents I have historically objected to tend to patent the technical detail that make the web work or significantly contributes to the integration benefits that an API delivers. Today’s patent does all of this but is focused on patenting the legal details that are needed to make this whole API thing work at scale.
Title: Automated assessment of terms of service in an API marketplace Number: 08954988 Owner: International Business Machines Corporation Abstract: An embodiment of the invention comprising a method is associated with an API marketplace, wherein one or more API providers can each supply an API of a specified type, and each provider has a set of ToS for its API of the specified type. The method includes, responsive to an API consumer having a need for an API of the specified type, obtaining the ToS of each of the API providers. The method further includes implementing an automated process to determine differences between the ToS of a given API provider, and a ToS required by the API consumer. The ToS differences determined for respective API providers are used to decide whether to select a particular one of the API providers to supply an API of the specified type to the API consumer.
Don’t get me wrong. I think this is an innovative idea. I just don’t think it is something that should be patented. It should be an open standard, with a wealth of open (and proprietary) tooling developed to enable it to be a reality. If you are patenting the thing we need to make the legal partnership details in API marketplace, and ideally on the open web across API implementations more streamlined, you are just slowing meaningful API adoption and integration–it isn’t something you are going to get rich doing.
Imagine if every technical, business and legal detail of the web was patented early on–it wouldn’t exist as it does today. We do need an automated way to assess the terms of service that govern API consumption. We need this now, but we need it to be an open standard that anyone can implement as part of any API marketplace or single API implementation. This is similar to what we are trying to accomplish with API Commons, trying to make the licensing portion of platform operations machine readable and digestible at integration, as well as at runtime.
I just wish the innovation and resources that went into this patent had gone into an open standard for helping define terms of services so that there could be any innovation when it comes to automating the assessment of API terms of service. It feels like this patent author is just counting on the fact that the API space will eventually mature and reach a point where automating the assessment of terms of service is possible, and then cash in on the fact that they hold a patent on this valuable aspect of the API economy.
Silicon Valley startups and entrepreneurs love to point out that they are trying to make the world a better place. Over a 25+ year career, I have fallen for the belief that I was improving a situation through technology. Hell, I still do this regularly as the API Evangelist, stating that a certain approach to opening up access to data, content, and algorithms can make things better, when in numerous situations it will not. I walk a fine line with this and I hope that I'm a little more critical about where technology should be applied, and focus primarily on making existing technology more accessible using APIs--not starting new ones.
When you are critical of technology in the current climate, there are plenty of folks you like to push back on you, leaning on the fact that they are trying to make the world a better place. Not sure where this line of bullshit first began but is something I should look into. I mean, when you hang out with enough entrepreneurs you really begin see through the bullshit and hype, and you know that this is all about them selling you something, and then selling you and your data as part of an exit via acquisition or going public. It rarely ever has anything to do with making the world a better place, what was promised as part of the marketing, and helping the average end-user.
This is where my entrepreneur friends have stopped reading and lean on the fact that they actually believe they are trying to make the world a better place, and their firm belief that Kin is an annoying hippie. You know I love you. You are a special snowflake. But, you are a minority, I am talking about the other 95% of the system you choose to be willfully ignorant of. If you want some evidence of this in the wild, take a look at all the world saving, innovative, revolution startups out there and how many are dedicated to terms of service?
You know, those little legal documents we agree to for our usage of every device in our life, and every single application we use in our professional and personal worlds. The terms of service touch ALL of our lives, and act as a central force throughout our days--kind of like gravity, except it's a corporate force, not anything natural--pushing down on everything we do. As important as terms of services are, and how big of a role they play in our lives, where is the innovation around these legal documents? You know, the kind that assists the average citizen make sense of all of this bullshit and makes their life better?
There are Terms of Service Didn't Read, Docracy, and TOSBack, but they just don't have the resources to tackle this properly. There are some service providers who do a good job of helping users make sense of their own terms of service, but there is NO INNOVATION when it comes to terms of service. There is nothing that serves the end-users over the platforms. With all of the innovation going on out there why isn't there more investment, and solutions in the area of terms of service? I mean, if we are trying to make our user's lives easier with technology, and not more complicated, why isn't there more technology to make sense of this legalese that is governing our lives?
Hint, it is because we aren't out for the greater good. With all the money flowing around out there, I just can't believe there isn't the money to do this right. Provide a suite modern tooling and a wealth of legal resources to tackle this problem properly. If nothing else, let's throw TOS Didn't Read, Docracy, and EFF's TOSBAck more money. Maybe there should be a "guilt tax" imposed on every terms of service owner to pay for an English, human translation of the legal documents that guide their platforms. Maybe there should be a machine-readable schema enforced at the regulatory level, making sure a suite of tools can process, and make sense of TOS changes in real-time.
Maybe some day we will stop just saying we are trying to help the world with our technology, and actually invest in what truly does.
The APIs which have seen the greatest adoption across the API space, always provide the functionality that developers are needed in their applications. It is either because the platform is already in use by their users (ie. Twitter, Facebook), or just provides the core feature that is required (ie. SMS, Email). There are an unprecedented number of high-value APIs out there, but I think many API providers still struggle when it comes to defining them in a way that speaks to the needs that web, mobile, and device app developers will be needing.
I have explored this topic before, discussing the importance of exposing the meaningful skills our APIs possess for use in the next generation of messaging and voice apps, as well as asking whether or not our APIs have the skills they need in a voice and bot enabled world. I am not 100% behind the concept that voice and bots are the future, but I am 100% behind defining our API resources in a way that immediately delivers value like they are doing in these environments.
The approach used by Alexa, when it comes to developing "skills" is an important concept for other API providers to consider. Even if you aren't targeting voice enablement with your APIs, the model provides many positive characteristics you should be emulating in your API design, helping you deliver more meaningful APIs. For me, thinking in terms of the skills that your APIs should be enabling, better reflects the API journey, where we move beyond just database and other very technical resources, and providing the meaningful skills developers need for success, and end-users (aka humans) are desiring.
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.
I always dig it when API stories spin out of control, and I end up down story holes. I'm sure certain people waiting for other work from me do not appreciate it, but these are where some of the best stories in my world come from. As I was writing the story about Best Buy limiting access to their API when you have a free email account, which resulted in the story about Best Buy using Medium for their API platform blog presence, which ended up pushing me to read Medium's terms of service.
Maintaining the legal side of your platform operations on Github, taking advantage of the version control build in makes a lot of sense. Something that also opens the door for using Github Issue Management, and the other more social aspects of Github for assisting in the communication of legal changes, as well as facilitate ongoing conversations around changes in real time. I can see eventually working this into some sort of rating system for API providers, a sort of open source regulatory consideration, that is totally opt in by API platforms -- if you give a shit you'll do it, if you don't, you won't.
I am spending a significant amount of time looking through the pricing pages for leading API providers, working to get a sense for some of the common approaches to API monetization in use across the space. Along the way I am also finding some simple and unique approaches from API providers that I wanted to share as bit-size API planning stories here on the blog.
As I was working to understand the coupling between the Box SaaS business model, and the one applied to their API, I noticed an interesting element, that was part of their enterprise API plan--custom terms of service. At first glance it doesn't seem like much, but making elements of your TOS dynamic, allowing them up to be used as a metric within your API plans, opens up a whole world of possibilities.
I have to note, this option is only available in the enterprise plan, which means only those with the most resources get this opportunity, but I still think its presence is meaningful. Right now, most terms of service and privacy policies are immovable shadows that guide how we do business and conduct our personal lives online, so the ability to think of them more dynamically, and one that could be tied to specific API access plans has huge potential. Unfortunately in the true Silicon Valley spirit, only some of this potential will be good, much of it will be in the name of exploitation, and the shifting of how power flows.
I have terms of service listed as a potential metric in my API plans research--we'll see where this goes, as my work evolves. I have a whole list of bit-size API monetization, pricing, and planning stories queued up. I will try to space them out, alongside other stories, but you will just have to suffer a little as I spend time expanding on my API monetization, and API plans research areas.
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.
I’m thinking through some of the next steps for my Reclaim Your Domain process, in preparation for a hackathon we have going on this weekend. Based upon defining, and executing on my own #Reclaim process, I want to come up with a v1 proposal, for one possible vision for the larger #Reclaim lifecycle.
My vision for Reclaim Your Domain, is to not create yet another system, we have to become slave to. I want #Reclaim to be an open framework, that helps guide people through reclaiming their own domain, and encourages them to manage and improve their digital identity through the process. With this in mind I want to make sure I don’t re-invent the wheel, and build off of any existing work that I can.
One of the catalysts behind Reclaim Your Domain for me, was watching the Terms of Service Didn’t Read project, aimed at building understanding of the terms of service, for the online services we depend on. Since the terms of service of my platforms, is the driving force behind #Reclaim decisions that I make, I figured that we should make sure and incorporate TOS Didn’t Read into our #Reclaim efforts--why re-invent the wheel!
There is a lot going on at TOS Didn’t Read, but basically they have come up with a tracking, and rating system for making sense of the very legalese TOS of services that we depend on. They have three machine readable elements, that make of their tracking and rating system:
- Services (specification) (listing) - Online service providers that we all depend on.
- Topics (specification) (listing) - A list of topics being applied and discussed at the TOS level.
- Points (specification) (listing) - A list of specific points, within various topics, that applied directly to services TOS.
This gives me the valuable data I need for each persons reclaim process, and insight into their actual terms of service, allowing me to educate myself, as well as anyone else who embarks on reclaiming their domain. I can drive the list of services, driven by TOS Didn’t Read, as well as educate users on topics, and the points that are included. As part of #Reclaim, we will have our own services, topics, and points that we may, or may not, commit back to the master TOS Didn’t Read project—allowing us to build upon, augment, and contribute back to this very important work, already in progress.
Next, as part of the #Reclaim process, I will add in two other elements:
- Lifebits - Definitions of specific type of content and data that we manage as part of our digital life.
- Actions - Actions that we take against reclaiming our lifebits, from the services we depend on.
I will use a similar, machine readable, Github driven format like what the TOS Didn’t Read group has used. I don’t even have a v1 draft of what the specification for life bits and actions will look like, I just know I want to track on my lifebits, as well as the services they are associated with these lifebits, and ultimately be able to take actions against the services--one time, or on regular basis.
I want to add to the number of TOS Didn't Read points available, but provided in a #Reclaim context. I think that once we beta test a group of individuals on the #Reclaim process, we will produce some pretty interesting topics, and points that will matter the most to the average Internet user. With each #Reclaim, the overall #Reclaim process will get better, while also contributing to a wider understanding of how leading technology providers are crafting their terms of service (TOS), and ultimately working with or against the #Reclaim process.
These are just my preliminary thoughts on this. I’ve forked the TOS Didn’t Read repository into the #Reclaim Github organization. Next I will make the services available in machine readable JSON, and driven using TOS Didn’t Read services within my personal #Reclaim project. Then I will be able to display existing topics, points and even the TOS Didn’t Read ranking for each of the services I depend on. Not sure what is after that, we’ll tackle this first, then I feel I’ll have a new understanding to move forward from.
I’ve been following the work of Terms of Service Didn’t Read for some time now. In my opinion this work is some of the most important legal work out there right now, which is guiding all of our activity not just online, but increasingly in our offline worlds. If you aren't familiar with Terms of Service Didn’t Read, I think their slogan sums it up well:
“I have read and agree to the Terms” is the biggest lie on the web. We aim to fix that.
More clarity and balance in the terms of service that online services employ is critical to the future of society and the web, this single checkbox is deciding our fate, whether you realize it or not. One of the projects I’m working on in coming months, is forking and extending the Terms of Service Didn't Read work into the world of APIs.
While I was aware that the Terms of Service Didn’t Read work is openly licensed, I wasn't aware of the degree of openness, until I started digging through their Github account and found machine readable inventory of the questions they ask of TOS. This is huge!
To achieve their rating of each online service, TOS Didn't Read asks questions of each service providers TOS. This list of questions is critical to making sense of the complex legalese that TOS contain, allowing for them to derive a rating for each service, and provide a list of plain english description of what you face when signing up for each online service.
In coming months, I will be working on a forked version of TOS Didn't Read, applying their machine readable questions specifically to APIs, and hopefully contributing cycles to the central TOS Didn’t Read. My intention is to make machine readable API definitions for this critical building block of the API economy.
There is a laundry list of problems with the current state of terms of service, affectionality called TOS--those legal documents we all agree to as part of our usage of online services, and are defining relationships between API providers and their consumers. API Voice is dedicated to exploring this, and other building blocks that make up the politics of APIs, an area you will see increased coverage of in 2014.
I strongly believe that to fully realize the API economy as many of us technologists see it, the terms of service have to be machine readable, allowing for seamless integration into the other political building blocks like privacy policies, service level agreements, partner access tiers, and pricing. If you think about it, current API terms of service reflect the command and control governance style of SOA, not the flexible, agile and innovative approach that APIs are often known for.
Why aren't API terms of service negotiable? Well they are, it just isn't built into the existing API platform. Many API ecosystem allow for circumventing and negotiating at the terms of service level behind closed doors, with partners, and API consumers who share the same investors, it just isn't a conversation that occurs out in the open. This approach reflects legacy ways of doing business, where if you are in the know, have the right connections, you can negotiate, and not the new API driven approach that will allow the API economy to scale as required.
The ability for API consumers to negotiate the terms of service isn't something that we can just roll out overnight, it is something we have to evolve towards over time. I’m hoping to help facilitate this evolution, through brainstorming, stories and conversations around the potential of machine readable terms of service, here on API Voice over the next couple of years.
Terms of service guide every aspect of how we provide and consume an APIs that drive our web and mobile applications. As an excercise, lets imagine a future where API terms of service (TOS) are machine readable, and always in alignment with the multiple partner tiers, and the service composition of an API platform.
Right now, the options available to API consumers is organized into service packages, allowing us multiple tiers of access, based upon usage + cost, when registering for and consuming API resources. Imagine if during this process the API TOS were integrated into the registration and account management workflows. Imagine you could fully understand each portion of the API TOS, and be provided with options, instead of a single, rigid level of service.
I’m just working through my thoughts on the politics of APIs, expanding on ideas of machine readable terms of service (TOS) introduce to me by Tyler Singletary (@harmophone) of @KloutAPI, and also a tweet from Antony Falco (@antonyfalco) of Orchestrate.io about the potential to allow for variances of TOS.
I would love to hear your thoughts on this subject. Am I off in left field, or is this something we should play with more?
Today’s focus is on making a plain english translation of your terms of service available. I came across a great example over at Makerbot Thingiverse today, where they add:
We realize Terms of Service can be confusing and, quite frankly, a snooze- fest; however, they are very important in explaining the basis of what we, the Company, expect of you, the User, while on this Site and how this interaction plays out. We promised “understandability” so, to the right of each term, we provided a summary in “plain English”.
The terms of service for APIs is the single most important building block of an API strategy, one that dictates how developers can access and put API resources to use and sets the tone for an entire API ecosystem. Your API can be publicly available, but the terms of service and licensing will determine whether it is truly open.
Even with the importance of this area of API operations, there aren't a lot of open resources to help guide you through crafting your API licensing and terms of service properly--until now.
A group of swedish entrepreneurs Daniel Rudmark of Viktoria Swedish ICT, Elias Arnestrand of Samtrafiken, Anna Mirsch lawyer at Mannheimer Swartling, and Andreas Krohn at Dopter have come together to create a new project to address this need, called Swedish API License.
The goals with the project was to create an API license that...
- Is open and free for anyone to use, encouraging maximal adoption
- Is flexible enough to fit many different use cases
- Respects both the publisher and the consumer of the API.
- Easy to understand for people without a law degree
The Swedish API license covers the following areas:
- Intellectual Property Rights
- Processing of Personal Data
- Technical Requirements and Limitations
- Other Requirements of Use
- Terms and Conditions
The Swedish API license even has an API license wizard that walks you through 13 steps of constructing and customizing your license, keeping within the legal and commercial considerations your company has around your API.
While the Swedish API License is published in Sweden, the site and licenses are in english and all the work is licensed under CC-BY license. This opens up a whole lot of opportunity to use the model around the globe.
I will be spending more time getting familiar with the approach to developing terms of service by the Swedish API License, and consider it side by side with existing efforts like Terms of Service Didn't Read and TOS Back from EFF. I'm thinking we are approaching a critical point in API growth, where we really need to start getting our house in order when it comes to open resources for API providers and API consumers.
I read your Terms of Service is one of the biggest lies on the Internet. We agree to terms of service for each and every service we use online, without ever reading and understanding exactly what we are agreeing to.
This is one of the most damaging aspects of online life, as through this process we are giving away our rights, ownership of our data and allowing for our privacy to be compromised each and every day. While not all services are abusing this, there are many online services that use this to their advantage, in an effort to maximize the amount of value they extract from their platform and end users.
Service providers have to go further in educating users about the terms of service they are agreeing to. There is a great example of this in action, via an article in NextWeb called “now THIS is how to write your startup’s Terms of Service”. The post showcases how real-time sharing platform Heello has provided plain english descriptions, next to each “legaleze” paragraph in their terms of service.
This is nothing new. You see it with other providers like Tumblr. But I think it is a very simple enhancement to API terms of service that can have a huge effect, and begin leading us in a more healthy direction when it comes to educating end-users about the TOS they are bound to. While companies need the protection of a legal terms of service, there is no reason you can't provide your end users with a translated, plain english version. It doesn't take much work, and really sets you apart from other API service providers.
Do you know of any other examples of online services going above and beyond to help educate end users about terms of service?
As a startup, you are bound to reach a point in your evolution where money will blind you, whether its during roadmap planning or communicating with your customers--eventually you will be blinded by your investors.
Once you’ve taken on enough investment, or the load of the parent company who acquired, you will start seeing things differently. You won’t see your users the same way anymore, this will be reflected in how you deliver features, or structure your roadmap--it isn’t about users anymore, it is about profit.
Once you enter this phase your imagination goes away, and you work to speak in terms that your investors understand. This is where I feel Instagram is at.
Instagram found success by solving a pain point for users. Making taking, applying filters and sharing photos dead simple for end-users. Instagram founders had identified a problem and used their imagination to find a solution.
But when working to find solutions to problems their investors are having, unfortunately Instagram is experiencing a lack of imagination.
Could you imagine if Instagram had gotten creative with its advertising platform? If they had included it’s passionate users in the planning and platform, allowing advertisers to submit campaign ideas to users, and allow for users to submit photos that best represented the ad campaign, vote and generate buzz, even before the campaign is fully formed. Users would line up to give away licensing of their photos. It could be Instagram American Idol for advertising campaigns.
An Instagram advertising platform could run similar to the weekend #hashtag program that Instagram runs currently, but allow for campaigns to be submitted by advertisers. Generating passionate users, unique content and the buzz around what the community feels are the best advertising campaigns, and photos for these campaigns.
Instagram’s approach to taking control over it’s users content and serve advertisers and investors lacks imagination. Much like Twitter’s perspective, Instagram is focused on revenue and completely forgetting to include their users in their roadmap planning, and traded in their imagination for Facebook shares.
Since Github will allow document types other than code, such as markdown and PDF, it can make sense to use Github for managing the legal side of your API.
Using Github for the legal aspects of API operation will provide a level of transparency developers will appreciate, allowing them to download and store for their own records while being able to see the difference between each version, in a format that makes sense to them.
Just as with all other areas of an API, Github will allow you to completely manage the evolution of your API terms, privacy and branding in a way that is in sync with all the other technical and business building blocks of your API.
Consider using Github for API legal building block management.
API terms of service (TOS) is one of the most critical, yet one of the most silent links for developers who are building apps and business on top of APIs. Terms of service determine what you can or cannot do with an API, and often times developers do not understand these terms, leaving them vulnerable to some very negative outcomes.
Following in the footprints of a larger project, called “Terms of Service Didn’t Read”, a group of us have gotten together, and created “API Terms of Service Didn't Read”, which aims at creating a transparent and peer-reviewed process to rate and analyze API Terms of Service, to establishing a rating classification that all developers can understand.
To seed the process, we went out and reviewed a number of the popular API terms of service and identified seven categories that really affect developers:
- Business model (include pricing, rate limits and quotas)
- Terms change conditions
- Developers restrictions
- End-user Privacy
- API Data ownership
- Data portability
The goal is to rank each API using a classification ranging from A (good) to E (bad) in these seven areas, so developers can quickly understand where an API stands in the areas that are most important to them.
API Terms of Service Didn't Read, also known as API-ToS;DR, is a crowd-sourced effort and requires community involvement to be successful. To get involved you can visit the API-ToS;DR website, join the working Google Group or help by pushing code in the Github repository.
As APIs grow in popularity this problem is only going to get worse. Terms of service is something I see several groups working to actively understand such as Singly with their personal data terminator project, and EFF with their TOSBack project.
Over the coming months I’d like to help focus all this energy into API Terms of Service Didn't Read, providing a plain english rating system that all developers can use when navigating the often treacherous landscape of API development.
I am going through the Foursquare API, and found their section about how to get an increase in the number of calls you can make against the Foursquare API interesting:
If your application runs into any of our rate limits and you think you could use more, write us at [email protected] We'llneed your OAuth consumer id, an explanation about why you need an increased cap, and information about the following
- Usage: A description of the endpoints you're calling and how you're using the data retrieved. We use this to make sure you're abiding by our Platform Policies and Terms of Service. Sample requests are generally helpful.
- Attribution: Screenshots of your application so we can confirm you're attributing foursquare correctly.
- Caching: Cache venue details where appropriate to avoid making spurious requests to our servers. See theRetention section of our Platform Policies for more details.
I like the idea of rewarding developers with the ability to make more calls against your API, when they adhere to your terms of service and benefit your operations.
Google has made another step towards a more common API infrastructure in line with their API Discovery Service, API Explorer, and API Console by launching a single terms of service for all Google APIs.
Google has rewritten their terms from the ground up with the goal of making them easier to understand for application developers.
While more complex APIs like Youtube, Google Analytics, Google Adwords and Google Latitude still use their own terms of service. Over time, more APIs will be migrated to the new, centralized terms of service format.
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.