Actually, NOW would be the time to contribute feedback to the OWF, since there's a good amount of momentum converging on finalizing the various agreements that the OWF will be offering.
Changing the licenses once they're set won't be easy — since the point of the agreement is to codify a specific and particular understanding of the ownership model (or non-ownership desire) of a group of implementors. The first agreement is here: http://openwebfoundation.org/legal/agreement/ Meanwhile, feedback should be submitted here: http://groups.google.com/group/open-web-legal-drafting Chris On Jan 24, 2:36 am, Jesse Stay <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>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
