Terms of use for application programming interfaces (TOS for APIs)

Please note that this post is from 2010. Evaluate with care and in light of later events.

Application Programming Interfaces (APIs) are the key to leveraging existing Web services, sites, and data (like Facebook, Twitter, or Google Maps) to create new and innovate services that users want to use. Users benefit from reusing their existing investment, developers benefit from not “recreating the wheel,” and business benefit from increased exposure and ubiquity (arguably, perhaps):

You see, the goal of “the cloud” isn’t simply putting all of your stuff into some stored space for access. It’s connecting your “stuff” — your apps, data, networks, etc. The how, if, why, when and where of that connecting (you could call it, for lack of a better word, “glue”) is wholly dependent on the terms of service around APIs.

via APIs, TOS, and building a hooked web | CloudAve.

In that spirit, lets review the highlights of some terms of service (Tos), current as of February 15, 2009:

Twitter

The main point of the Twitter API’s terms of service (which is surprisingly short!) is that you should get user permission first and not meddle with a Tweet’s content. Perhaps as a result of the very favorable set of terms, many applications access Twitter data, or leverage the Twitter stream.

Flickr

In contrast to Twitter, the Flickr API has a long and extensive set of terms as part of its terms of service. Like Twitter, none of these are too burdensome, although the pre-approval requirement for commercial apps could make basing a business on access to the Flickr API potentially problematic. Highlights include:

• Following all other Flickr and Yahoo terms of use
• Complying with user/owner terms and conditions (private flags, etc.)
• Have your own privacy policy
• Commercial applications have specific requirements and require specific approval from Flickr first (and may require payment)
• No warranty by Flickr, release of liability, etc. — plus some more legal terminology

Despite the longer language, most of this is not particularly onerous (possibly excepting the commercial-approval requirement), and there are thus many applications making use of the Flickr API in some form or another.

LinkedIn

The LinkedIn API terms of service are much more detailed and more restrictive. As a result, I know of very few applications that interface with LinkedIn. In reference to their API terms, Eric Norlin writes:

LinkedIn is famous in some circles (no names) for not playing so nice with their API. According to their terms, you can’t store anything other than a profile or ID — which is to say you can’t store the most powerful/useful thing about LinkedIn — the connections. Beyond that, their TOS says that you can’t use their API and “compete” (though it never defines what that is). And, to put the icing on top, they gain the right to “audit” you if you use their API.

Neither Flickr nor Twitter explicitly limit your ability to “compete” if you use their API (though Flickr might, since they reserve the right to deny “commercial use”), nor do they limit storage of the data you pull via the API. Certainly from a business perspective, it makes good sense for LinkedIn to take this approach — connections are the core of their offering, really, so allowing a competitor to leverage those connections via their API is a concern. Nonetheless, setting firm limits on use by everyone, potential competitor or not, severely limits the potential innovation of 3rd-party developers.

Facebook

Facebook has detailed, relatively easy-to-understand policies use of its APIs. Most of the complexity emerges from the fact that there are multiple ways for developers to interact with Facebook. Nonetheless, there are extensive examples and explanations provided by Facebook. There are a variety of limitations placed on developers, but this hasn’t hampered rampant Facebook application development. The biggest limitation — similar to LinkedIn’s restriction — is that Facebook data cannot be stored for more than 24 hours.

Unlike LinkedIn, commercial application development is clearly encouraged, although there are extensive limitations on how those applications can interact with Facebook. Like Twitter, Facebook’s stream is now available, and applications are starting to leverage it. But like LinkedIn, connection data cannot be stored, even if it can be accessed while a user is connected.

Conclusion

Despite the extensive limitations of Facebook, it is one of the #1 platforms for which 3rd-party developers write applications. LinkedIn, by contrast, has not developed the same number of application developers. Twitter, which has very loose terms, has extensive developer support.

In my opinion, developers write for Facebook because (1) that’s where the users are, first and (2) commercial applications are allowed and even encouraged. Developers write for Twitter because (1) it has users and (2) terms of use are straightforward. Similarly, Flickr has rich content and access is straightforward. LinkedIn, on the other hand, has a complex API and terms of service that appear limiting, especially when it comes to commercial use.

Terms of use are critical. Most allow for the revocation of access if the API provider decides to do so. If that happens to you, you may have little recourse. Make sure you understand the terms before you build a business on top of someone else’s API.

What does this mean in terms of “actually building things”? For software developers, not much. Technical utility of the API itself is much more important. For business developers, they can mean the difference between a neat toy and a profitable venture.

Related articles by Zemanta

• 35 APIs in 7 Days: Facebook, Flickr, Foursquare, Google, Twilio, Twitter, Yelp, and YouTube (programmableweb.com)
• Making a personal site more dynamic (inpropriapersona.com)