RSS

Terms of Service News

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.

Patent US9639404: API Matchmaking Using Feature Models

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 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.


Patent US 8954988: Automated Assessment of Terms of Service in an API Marketplace

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.


No Innovation Around Terms of Service Reveals True Motives

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.


Thinking In Terms of API Skills And Moving Beyond Just API Resources

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.


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.


Managing Your API Terms of Service And Privacy Policies On Github Like Medium Does

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.

Anyways, to help manage the evolution of the terms of service, privacy policy, Medum uses Github to establish a historical record of all the changes to all legal documents that impact platform, and API operations. Seems like a pretty sensible, and default approach to the legal department for any platform. Hosting your legal department on Github, making sure their is as much transparency, and logging across this area of operations will play a central role in establishing and maintaining trust with your partners and consumers.

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. 


Customizable Terms of Service As Part Of Your API Plans

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. 


Machine Readable Terms of Service Didn't Read Applied To APIs Via APIs.json

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.


Driving The #Reclaim Process Using Terms Of Service Didn't Read

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.


The Machine Readable Questions We Should Ask Of Terms Of Service

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.


One Of The Problems With API Terms of Service Is That There Is No Negotiation

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.

As I continue to develop a better understanding of how API terms of service influence the API economy, I can't help but think one of the fundamental flaws of API terms of use is that there is no room for negotiation. Earlier this month I explored the concept of being able to pay for alternate options within a terms of service, as part of my ongoing journey towards a machine readable TOS.

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.


Would You Pay For Alternate Options For An API Terms Of Service?

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.

Currently options for API access are throttled across TOS, privacy policy, branding, service level agreements, pricing, and service composition and partner access tiers. I want to explore the possibility that these building blocks could be machine readable, allowing for variances on each aspect of API operations. This scenario would allow for API consumers to prioritize which aspects of operations are most important to them, allowing them to pay more for premium access to API services.

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?


Makerbot Terms of Use in Plain English

API Terms of Use is the single most important building block of any ecosystem, yet it is the least discussed area of API management and integration. I’m working hard to dedicated more time in 2014 to not just the area of API TOS, but what I consider to be the politics of APIs.

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”.

Music to my ears. Every time I come across an example of plain english terms of use like this, I’m going to write a short blog post on it. While I may not always agree with a company’s terms of service, I can get behind approaches to make them simpler, more accessible and understandable by users.


API Terms of Service Wizard From Swedish API License

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:

  • License
  • Intellectual Property Rights
  • Processing of Personal Data
  • Technical Requirements and Limitations
  • Other Requirements of Use
  • Liability
  • Changes
  • 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.


Providing Plain English Version Of API Terms of Service

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?


Instagram Terms of Use Change Represents a Lack of Imagination

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.


Managing API Terms of Service, Privacy, and Branding with Github

The legal building blocks of an API can be just as critical as the technical and business building blocks. It makes sense to version and communicate your API terms of use (TOS) , privacy policy and branding guidelines alongside your code.

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.


Crowdsourced API Terms of Service

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
  • Jurisdiction

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.


Follow Terms of Service to Get Increase in Number of API Calls

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 Deploys a Single, Centralized Terms of Use for APIs

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.

At the moment it seems as though most of the APIs that use the central terms of service are content and data related APIs, like Google Tasks, Google ModeratorGoogle Charts and Blogger.

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. 

With almost 100 APIs now, it makes sense for Google to reduce the complexity of terms of use across APIs, increasing the chances a developer will “legally” build an application or business around one or multiple Google APIs. 

Google provides tools for developers to easily discover, explore their APIs, while also providing centralized management of billing, usage reporting and terms of use.  I predict we will see other API service providers offering tools for managing terms of use, branding and other legal aspects of API management in 2012.


USA Today Announces Commercial Terms of Use for Its API

USA Today has announced that they now support the commercial access of articles, reviews and census data through their content APIs.

Any developer can request a key, and start making calls for free, with initial calls being restricted at a default rate. But as applications prove successful they are now willing to increase usage caps on a case-by-case basis. USA Today doesn’t describe what its commercial pricing will be, but they state in their terms and conditions:

If USAT decides to charge a fee for use of or access to the USAT APIs, such fees will be disclosed to you prior to USAT charging such fees to you.

Every couple of months USA Today rolls out a new API or evolution in their business model, as they get more comfortable with their API. This latest move seems to seems to be centered around encouraging commercial of its census data, which the NY Times makes available for commercial use as well.

Its interesting to watch these media giants evolve their business models using APIs to make themselves more competitive.


API Terms of Service Predict an Unsure Future

I was just working on a piece for ProgrammableWeb about the new Yahoo WebPlayer, which is amedia player that can play video and audio from any site or service, and be distributed across the web.

While browsing around the Yahoo WebPlayer site I came to the Terms of Service, which I found three items that stand out:
Yahoo! can update and change this Agreement and TOS by posting a new version without notice to you.

You understand and agree that the Player may allow for advertisements and that these advertisements are necessary for Yahoo! to provide the Player for your use.

Yahoo! Media Player is free, but Yahoo! reserves the right to charge fees for future use of or access to the Player at Yahoo!'s sole discretion.
I think these are pretty standard rules of the road that us publishers and developers are getting used when integrating with APIs and deploying gadgets, widgets and other embeddable tools. But they don't give us much build upon, as a content publisher, or developer trying to build a business.

I cannot see into the future, and I understand the problems providers face, but these terms seem pretty wide open, in favor of the provider. What can we do to make terms of services (TOS) for APIs and other tools more in support of the community a provider is targeting with these services?

I don't have the answers, just asking the question. This bizdev 2.0 stuff is a lot harder than we anticipated.

Setting the Tone for your API Terms of Service

I wanted to establish a base Terms of Service for my API area.

So I went and read the API terms of service from 15 top APIs

I found the opening paragraph says a lot about how a company approaches their API.

Here are the opening paragraphs for the top 15 API terms of service I came across:

Twitter Twitter maintains an open platform that supports the millions of people around the world who are sharing and discovering what's happening now. We want to empower our ecosystem partners to build valuable businesses around the information flowing through Twitter. At the same time, we aim to strike a balance between encouraging interesting development and protecting both Twitter's and users' rights.

So, we've come up with a set of Developer Rules of the Road ("Rules") that describe the policies and philosophy around what type of innovation is permitted with the content and information shared on Twitter.

Amazon Web Services Welcome to the Amazon Web Services site (the AWS Site). Amazon Web Services LLC and/or its affiliates (AWS) provides the AWS Site to you subject to the following terms of use (Terms of Use). By visiting the AWS Site, you accept the Terms of Use. Please read them carefully. In addition, when you use any current or future AWS services, content or other materials, you also will be subject to the AWS Customer Agreement or other agreement governing your use of our services (the Agreement).

Google Maps Thank you for your interest in the Google Maps/Google Earth APIs. The Google Maps/Google Earth APIs are a collection of services that allow you to include maps, geocoding, and other Content from Google in your webpages or applications.

Skype These Skype API Terms of Use ( "API Terms") set out the terms and conditions of use of the Skype API. If You want to use the Skype API for any purpose (including without limitation, in connection with an application or software program or for the purpose of interfacing with hardware), You must first register with Skype by completing and providing accurate contact information on the Skype Partner enquiry form available at the Skype Website (the "Registration"). By submitting Your Registration to Skype and / or using Skype API, You explicitly agree to be bound by these API Terms and any revised or renewed versions thereof, as will be published on the Skype Website or as may be otherwise notified to You by Skype. Skype reserves the right, at its sole discretion, to refuse or reject Your Registration.

LinkedIn We're glad you've chosen to use the LinkedIn APIs. By using one or more of the LinkedIn APIs (the "LinkedIn APIs" or APIs), you and, if applicable, the company you represent (collectively, "you") accept and agree to be bound by the following terms and conditions (the "Terms of use" or Terms). It is important that you read these Terms as they form a legal agreement between you and LinkedIn, Inc. (LinkedIn, we, or us).

Rapleaf These terms and conditions constitute a legal agreement between you and Rapleaf, Inc. ("Rapleaf," "We" or "Us"). By accepting these terms and/or using the Rapleaf Personalization API service ("Personalization API" or "API"), you are representing that you have the authority to bind the party being issued an API Passkey for this Personalization API and otherwise act on their behalf (you and any such party are collectively referred to as "You"). The "API Passkey" is the Personalization API service user passkey given to you by Rapleaf upon successful sign-up for this service. In exchange for use of and access to an API Passkey and Rapleaf's proprietary Personalization API and its technical specifications ("Specifications") you agree to be bound by these Rapleaf Personalization API Terms and Conditions (this "Agreement"). This Agreement shall take precedence over and supersede any prior agreement, whether oral or written, express or implied, between the parties, including any non-disclosure or confidentiality agreement.

Netflix We're glad you've chosen to use the Netflix API. By using the Netflix API (the "Netflix API" or "API"), you and, if applicable, the company you represent (collectively, "you") accept and agree to be bound by the following terms and conditions (the "Terms of Use," "Terms" or "Agreement"). It is important that you read these Terms as they form a legal agreement between you and Netflix, Inc. ("Netflix", "we", or "us").

Scribd Welcome to the Scribd, Inc. (hereafter referred to as Scribd) content management and file download platform consisting of web sites, services, software applications and networks that allow for the authorized download and distribution of digital content over the internet (the Scribd Platform).

Ebay Thank you for your interest in the eBay Developers Program, which allows you to build applications that usecontent from and interact with eBay-branded marketplaces around the world. Because we are committed toprotecting our users and our sites and services, we require you to abide by the following terms governingyour participation in the eBay Developers Program and your use of the eBay API, this eBay DevelopersProgram & API License Agreement (Agreement).

Etsy Below this introduction is quite a bit of important legal language. Please read it. Inside Etsy, we talk a lot about the importance of humanity, honesty and transparency in our communications. So, before you read on to the important legalese, we want to share a few thoughts in human and honest terms.

Wolfram Alpha Wolfram|Alpha LLC ("Wolfram|Alpha"), a Delaware company, provides you ("You/Your") one or more unique application ID keys (the "AppID") to its application programming interface ("Wolfram|Alpha API") for the purpose of developing a website or software application ("API Client") subject to Your compliance with these Wolfram|Alpha API Terms of Use (the "Terms"). By using any AppID, You agree to be bound by these Terms.

Foursquare BY INTERACTING IN ANY WAY WITH THE FOURSQUARE API, INCLUDING, BUT NOT LIMITED TO REQUESTING CREDENTIALS OR MAKING API CALLS, YOU OR THE ENTITY OR COMPANY THAT YOU REPRESENT ("YOU") UNCONDITIONALLY CONSENT AND AGREE TO BE BOUND BY AND A PARTY TO THESE TERMS AND CONDITIONS (AGREEMENT).

SalesForce Welcome to Developerforce. By accessing or using any part of Developerforce, or by uploading ordownloading any content, you agree that you are subject to and will comply with these Terms of Use, asWe may update them from time to time. Facebook Facebook Platform is an extension of Facebook, whose mission is to give people the power to share and make the world more open and connected.

Platform applications and developers are required to comply with the following documents:
  • Statement of Rights and Responsibilities: requirements for anyone who uses Facebook.
  • Principles: the spirit of the law for Platform.
  • Policies: the letter of the law for Platform.
Flickr Thank you for using the Flickr application programming interfaces (the "Flickr APIs"). By using the Flickr APIs, you agree to the terms below. If you disagree with any of these terms, Flickr does not grant you a license to use the Flickr APIs. We reserve the right to update and change these terms from time to time without notice. You can always find the most recent version of these terms here http://www.flickr.com/services/api/tos/.

------

The first paragraph sets the tone as strictly legal, business or welcoming you to the API community.

How will you set the tone for you API terms of service?

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.