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

Reply via email to