A couple of days ago, Ryan Sarver of Twitter sent an email to the API developers mailing list notifying us of changes to their terms of service. As per usual the community have exaggerated the implications of these changes to the point where it’s now pure comedy. As has happened every time Twitter make any changes that may affect developers, developers are panicking, and for no good reason that I can find.
Techcrunch have put up an excellent post highlighting the differences between the old and new terms. Most of the changes are pretty straightforward, and make a reasonable amount of sense.
Part of the confusion was actually caused by the text of Ryan’s email rather than the changes in the terms. I’ll comment on that email after I’ve reviewed the TOS changes.
This change, in the first paragraph of the terms, seems to have gotten everyone riled up. It’s an interesting change of term, but I think it’s simply clarifying Twitter’s priorities. Their ultimate interest is in ensuring they themselves are profitable, whereas the previous wording implied they would do what they could to assist their partners in achieving that same goal.
This is about setting expectations, and I think they’ve done the right thing in making it clear where their priorities lie. They’re not here to support your business, they’re here to provide a platform that your tool can utilise. I don’t criticise them at all for taking that position, and I applaud them for being explicit about it.
The previous terms were put in place at a time when a large number of applications were out there, all of which had been developed before there were any formal rules. The language in the third paragraph reflected that by using phrases like “If you are doing something prohibited by the Rules”. These rules have now been out there for long enough that no application should still be breaking the rules.
By changing that text to “Don’t do anything prohibited by the Rules” Twitter have forced developers to contact them for permission before they implement anything that might break the rules. This seems like a reasonable approach to rolling out the rules and enforcing them.
It makes sense for Twitter to limit wrapper APIs that are then made available to the public. Restricting those APIs such that they can only serve IDs ensures that Twitter remains the only source for the actual content.
Unfortunately this extends to services that backup your tweets, since such tools would be covered by exporting to “a datastore … or other cloud based service”. However, this does appear to allow desktop tools that maintain local backups.
The scope of their marks not withstanding (the word tweet was first used by the community, not by Twitter), this is pretty standard stuff.
I’m not sure I see the thought behind the addition of this clause. I don’t get how a premium-rate SMS service could harm Twitter’s revenues unless they themselves are planning to start charging for it. I find it unlikely that such a move is in their roadmap.
This is the addition that has caused most of the confusion amongst the developer community. The essence of what they’re doing here is protecting their current and future revenue streams.
They start by defining what they mean by a “Client”, and it’s really quite straightforward: they mean anything that provides a “standard” user experience. This would be a combination of showing the user’s timeline, allowing them to post tweets, search, and basically anything else that’s available within the web interface.
Let’s look at each part in turn.
A. Your Client must use the Twitter API as the sole source for features that are substantially similar to functionality offered by Twitter. Some examples include trending topics, who to follow, and suggested user lists.
In other words, if you’re going to show trending topics or follower suggestions you have to use the lists provided by the API so that promoted items are displayed, thus helping them get paid for the free access to the API that your app utilises.
This is somewhat unfortunate since it prevents clients from using their own algorithms to build this data, thereby preventing innovation. I’d like to see a modification that simply ensures that where such functionality is present, the Twitter-provided lists are used while not preventing the client from augmenting those lists if desired.
B. You may not pay, or offer to pay, third parties for distribution of your Client. This includes offering compensation for downloads (other than transactional fees), pre-installations, or other mechanisms of traffic acquisition.
Curious one this, since they’re basically making sure that you can’t use that stash of cash you sleep on at night to spread your app to the masses. Not sure they should be particularly worried about that. While there are several examples from the olden days where such strategies have worked, I’m having trouble coming up with a recent example.
D. Do not store non-public user profile data or content.User privacy is a hot topic for Twitter at the moment, and this clause simply enforces that attitude onto third-party developers. Essentially... don't be an arsehole!
E. You may not use Twitter Content or other data collected from end users of your Client to create or maintain a separate status update or social network database or service.Shocker! They don't want you taking their data and creating a rival service. Unfortunately this probably prohibits gateways between Twitter and other networks which, while protecting user's reliance on their service, would slow uptake of a decentralised replacement system.