I think the OWF agreement is an excellent idea - I'd love to see Twitter
join in that agreement with its developers.  If Twitter has concerns with it
I'd love to see them get involved in the OWF discussions and perhaps the
agreement could be modified to meet Twitter's needs.  Why reinvent the
wheel?

Jesse

On Sat, Jan 23, 2010 at 6:28 PM, DeWitt Clinton <dclin...@gmail.com> wrote:

> Thanks for the update, Ryan.  And thanks for the compliment on the Google
> Code policies page -- that page was one of the first things I launched at
> Google back when we were being asked the exact same questions.
>
> We also added patent licences, which follow this general format:
>
>   http://code.google.com/apis/gdata/patent-license.html
>
> Granted, that license is maybe even more liberal than most implementors
> require.   Also, that was before we had a reusable patent agreement, such as
> the OWFa: http://openwebfoundation.org/legal/agreement/.  If I did
> something new outside Google I'd probably go the OWF route now.
>
> Trademark is trickier.  I'm not sure we've quite nailed it yet at Google,
> actually.  But the basic framework might be a statement that enumerates
> specific marks and lists specific appropriate usages.  You can always add to
> that list over time, and this would protect Twitter's rights in the cases
> you haven't anticipated yet.
>
> Thanks again for pushing this forward.  Cheers,
>
> -DeWitt
>
>
> On Sat, Jan 23, 2010 at 11:28 AM, Ryan Sarver <rsar...@twitter.com> wrote:
>
>> DeWitt,
>>
>> Thanks for the serious patience on this thread. We're constantly trying to
>> adapt to the needs of the developer community, and you're right that we
>> haven't published guidelines around use of the Twitter API specifications.
>> But, we are working on it and I wanted to share some of the thought that
>> will help drive the policy.
>>
>> What we do know is that there is a clear need for a flexible, friendly and
>> responsible policy. Policies such as this one (
>> http://code.google.com/policies.html#restrictions) are a good start, and
>> I can share some principles we'd like to live by. CC-BY should apply to a
>> lot of the tools we release. You should be able to copy, modify and make
>> derivatives of our specifications (with attribution). We shouldn't throw
>> arbitrary roadblocks in your way, such as preventing you from naming a
>> library "tweet." And last, we shouldn't pester you for utilizing our patents
>> underlying these specifications.
>>
>> These are flexible and friendly principles, and in exchange we ask the
>> development community to act responsibly. For example, naming a library
>> "twitter" is one thing. Naming your application "twitter" is quite another.
>>
>> We hear you loud and clear, so please bear with us as we translate these
>> principles into official policy.
>>
>> Thanks again for your patience and interest :)
>>
>> Best, Ryan
>>
>> On Tue, Nov 24, 2009 at 9:12 AM, DeWitt Clinton <dclin...@gmail.com>wrote:
>>
>>> Hi all,
>>>
>>> I recently received a request to implement the "retweet" api calls in the
>>> python-twitter and java-twitter libraries, but before I proceed I was hoping
>>> for a bit of clarification around the licensing terms for the Twitter API.
>>>
>>> My layman's understanding is that without explicit terms there are
>>> relatively few rights offered by default regarding a specification.  In
>>> particular, I have a few questions about copyright, trademark, and patents
>>> rights being offered to implementors of the Twitter API.  My longstanding
>>> sense is that Twitter has indicated the spirit of offering the API under
>>> generally permissive usage rights, so hopefully this thread can move the
>>> discussion forward a bit and perhaps turn that spirit into something more
>>> formal.
>>>
>>>
>>> *Copyright*
>>>
>>> **Question: Under what terms may third-party library and application
>>> developers use the text and images associated with the Twitter API
>>> specification?
>>>
>>> Example use case:  Third-party library developers would like to copy
>>> and/or modify the text of the Twitter API specification in the library's
>>> documentation.  This is preferred over inventing new text for the
>>> documentation, the meaning of which could deviate from the canonical version
>>> in the Twitter API specification.
>>>
>>> Potential concern:  Without a copyright license, implementors may not be
>>> permitted to use or reuse the Twitter API specification text in third-party
>>> library documentation.
>>>
>>> Current state:  While the Twitter API specification itself doesn't
>>> mention copyright, the Twitter Terms of Service (http://twitter.com/tos) 
>>> state:
>>> "The Services are protected by copyright, trademark, and other laws of both
>>> the United States and foreign countries," which could reasonably be
>>> interpreted to apply to the Twitter API service as well.
>>>
>>> Possible desired outcome:  The Twitter API specification is made
>>> available under a permissive and derivative works-friendly copyright
>>> license, such as the Creative Commons BY or BY-SA license.
>>>
>>>
>>> *Trademark*
>>>
>>> Question: Under what terms may third-party library and application
>>> developers use the various registered service marks of Twitter, Inc?
>>>
>>> Example use case:  Third-party library authors would like to use the
>>> words "twitter", "tweet", "retweet" (all live service marks of Twitter, Inc)
>>> in their libraries.  This is preferred over third-party library authors
>>> inventing new terms for API methods such as "retweet".
>>>
>>> Potential concern: Without terms that specify where and how the various
>>> registered marks can be used, third-party library implementors may or may
>>> not be permitted to use terms such as "twitter", "tweet", "retweet", etc.,
>>> in their libraries.
>>>
>>> Current state:  The Twitter Terms of Service (http://twitter.com/tos)
>>> appear to prohibit such use: "Nothing in the Terms gives you a right to use
>>> the Twitter name or any of the Twitter trademarks, logos, domain names, and
>>> other distinctive brand features."
>>>
>>> Possible desired outcome:  Twitter publishes acceptable-use guidelines
>>> for registered marks in third-party libraries and third-party applications.
>>>
>>>
>>> *Patent*
>>>
>>> Question:  Under what terms may third-party library and application
>>> developers make use of current or future patent claims made by Twitter, Inc?
>>>
>>> Example use cases:  A third-party developer may wish to implement an
>>> independent service that conforms to the Twitter API method signatures, or a
>>> third-party developer may wish to implement a library that implements
>>> portions of the Twitter API on the client.
>>>
>>> Potential concern:  Without terms that specify how third-party developers
>>> may use patent claims (if any) made by Twitter, Inc, implementors assume the
>>> risk of potentially infringing on current or future claims made by Twitter.
>>>
>>> Current state:  Twitter (to my knowledge) has made no statement regarding
>>> patent claims with respect to implementations of the Twitter API.
>>>
>>> Possible desired outcome:  The Twitter API specification is made
>>> available under a patent agreement, such as the Open Web Foundation
>>> Agreement (http://openwebfoundation.org/legal/), or a similarly
>>> permissive agreement, such as the Microsoft Open Specification Promise (
>>> http://www.microsoft.com/Interop/osp/) or a Google-style patent license
>>> (http://code.google.com/apis/gdata/patent-license.html).
>>>
>>>
>>> ...
>>>
>>> I realize that these are meaty (and potentially legally sensitive)
>>> questions of course, and likely ones that are not easily answered in a
>>> public forum.  However, any feedback from the team would certainly be
>>> appreciated.
>>>
>>> The fact that people are even thinking about these types of questions is
>>> a good thing, both for open specification development in general, but also
>>> because it shows how successful and important the Twitter API is today.  So
>>> again, continued success with the API, and I look forward to hearing more
>>> from the team.
>>>
>>> -DeWitt
>>>
>>>
>>>
>>>
>>>
>>
>

Reply via email to