Dewald, sorry if this isn't clear. The intent is to allow developers to still post to other 3rd party networks like Facebook, Identica, LinkedIn, etc. What we don't want to allow is for a client to use our content to build their own competing status service and by sending content to services that the user did not intend to send them to.
Users trust us with their content and we want them to have an idea of where the content goes and how it is going to be used. Hope that helps clarify. Ryan -- Ryan Sarver @rsarver <http://twitter.com/rsarver> On Mon, Mar 14, 2011 at 8:43 AM, Dewald Pretorius <dpr...@gmail.com> wrote: > Taylor, > > Would you mind taking a stab at clarifying Section 5.E of the new TOS, > which reads, "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." > > It appears to say that a Client is not allowed to offer its users the > ability to create status updates on other services (StatusNet, > Facebook, etc.). Had it not been for the "or other data collected from > end users" I would have interpreted it that one cannot use any Twitter > Content (user data and tweets obtained via the Twitter API) and feed > that Twitter Data into other and/or competing social network > platforms. But, "or other data collected from end users" seems to > suggest that one cannot so much as offer any support for any other and/ > or competing social network platform. Meaning, if you have a Client, > you can support Twitter OR Everything Else, not both. > > > On Mar 14, 11:12 am, Taylor Singletary <taylorsinglet...@twitter.com> > wrote: > > Hi Adam, > > > > Thanks for your comments as always. I can help clarify a bit around how > > clients will be held to higher standards. > > > > Criteria we may examine include: is the application in tune with the > spirit > > of the developer guidelines? Does the application refrain from storing > > username & password if it's using xAuth? Are tweets displayed with the > > proper attribution? Are the actions presented for the tweet appropriate > in > > respect to it being a tweet? Does the application frame portions of our > > mobile site? Does it store non-public user data in a public way? Does the > > application provide a privacy policy? Is the client application paying > for > > installation on mobile carriers? > > > > The new terms also offer some examples that are reasonably specific: > > > > > > > > > > > > >> 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. > > > > > 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. > > > > > C. Your Client cannot frame or otherwise reproduce significant > portions of > > >> the Twitter service. You should display Twitter Content from the > Twitter > > >> API. > > > > > D. Do not store non-public user profile data or content. > > > > > 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 > > > > Using a Twitter client is like using an extension of Twitter, and though > the > > user interfaces may change we want to ensure that the user experience is > > consistent, whether it's consistency in the actions a user can perform > with > > a Tweet, the way their private information is treated, or how slowly, > > quickly, and with what tact advertising flows or does not flow through > the > > network. > > > > Taylor > > > > On Sun, Mar 13, 2011 at 9:55 PM, Adam Green <140...@gmail.com> wrote: > > > Yes! Transparency! That is what we are really craving. That is the > subtext > > > for every developer responding to this thread. What we all want is > > > transparency about being shut down. Why does Twitter "revoke literally > > > hundreds of API tokens / apps a week" as Ryan said? Is it for something > > > obvious, like pumping out thousand of spam tweets or abusive follows, > or is > > > it for something innocent, like not putting the right text on a tweet > > > button? I have never seen a description of an app that was blocked, > except > > > for a few loons like Edward H. What if you told us about apps that get > > > blocked as examples, and explain what they did wrong? You don't even > have to > > > identify them by name. Just explain exactly what type of transgressions > are > > > causing rejection. That could calm people down. > > > > > Who doesn't meet the "high bar" and why? I know "high bar" has a lot of > > > meaning to you Twitter guys, since you all use the same term (a real > example > > > of groupthink, BTW), but it means nothing to us. Tell us where this > high bar > > > is exactly, by showing examples of not reaching it. Then we can learn > and > > > improve, rather than guessing at what you mean. > > > > > Nobody here would bitch and moan if they didn't really want to learn > > > something. Please, help us by giving us examples. > > > > > On Mon, Mar 14, 2011 at 12:07 AM, Matt Harris <mhar...@twitter.com> > wrote: > > > > >> Innovation and development with the APIs are not being prevented. > There > > >> have always been guidelines, and rules of the road so we all know what > is > > >> and isn't allowed. > > > > >> If you build a client you are touching the majority of Twitter > features. > > >> The APIs allow you to do this, and Twitter and your users trust you to > use > > >> them in the way the terms or service allow. The high bar covers your > use of > > >> these methods, and how you present information back to the user. The > ToS > > >> covers this but there are always situations where the application of > them > > >> isn't clear. — Let's have those discussions with your use cases > applied for > > >> the benefit of everyone. > > > > >> The direction, and motivation here is transparency. You asked us what > it > > >> looks like from the inside out. It can be uncomfortable, sure, but I > believe > > >> it's better we all know how it looks on both sides. > > > > >> Without us saying how we see it, how can we have these discussions? > > > > >> @themattharris > > > > >> On Mar 13, 2011, at 20:21, Lil Peck <lilp...@gmail.com> wrote: > > > > >> > On Sun, Mar 13, 2011 at 7:45 PM, @siculars <sicul...@gmail.com> > wrote: > > >> >> @raffi @rsarver, I wrote up my two cents earlier, > > >> >>http://siculars.posterous.com/twitter-monoculture. I just don't > > >> >> appreciate the direction you all are going in. @raffi, I spoke with > > >> >> you at the CU recruiting event a few weeks back and I got to tell > you > > >> >> that if I were asked I would tell those kids to reconsider working > at > > >> >> twitter and possibly consider a Twitter competitor. you say > "building > > >> >> clients is ... Thinking too small" I would say your policy change > is > > >> >> thinking small and alienating your ardent supporters. > > > > >> > To which I would add, what is Twitter to arbitrate that which is and > > >> > is not "too small?" Has Twitter subscribed to the fallacious "bigger > > >> > is always better" philosophy? > > > > >> > How small is too small? > > > > >> > Less than $25 million in startup funds? > > > > >> > OR > > > > >> > One creative, fun loving person and their sweat equity? > > > > >> > -- > > >> > Twitter developer documentation and resources: > > >>http://dev.twitter.com/doc > > >> > API updates via Twitter:http://twitter.com/twitterapi > > >> > Issues/Enhancements Tracker: > > >>http://code.google.com/p/twitter-api/issues/list > > >> > Change your membership to this group: > > >>http://groups.google.com/group/twitter-development-talk > > > > >> -- > > >> Twitter developer documentation and resources: > http://dev.twitter.com/doc > > >> API updates via Twitter:http://twitter.com/twitterapi > > >> Issues/Enhancements Tracker: > > >>http://code.google.com/p/twitter-api/issues/list > > >> Change your membership to this group: > > >>http://groups.google.com/group/twitter-development-talk > > > > > -- > > > Adam Green > > > Twitter API Consultant and Trainer > > >http://140dev.com > > > @140dev > > > > > -- > > > Twitter developer documentation and resources: > http://dev.twitter.com/doc > > > API updates via Twitter:http://twitter.com/twitterapi > > > Issues/Enhancements Tracker: > > >http://code.google.com/p/twitter-api/issues/list > > > Change your membership to this group: > > >http://groups.google.com/group/twitter-development-talk > > -- > Twitter developer documentation and resources: http://dev.twitter.com/doc > API updates via Twitter: http://twitter.com/twitterapi > Issues/Enhancements Tracker: > http://code.google.com/p/twitter-api/issues/list > Change your membership to this group: > http://groups.google.com/group/twitter-development-talk > -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
