search

appdotnet / terms-of-service

The App.net terms of service documents live here. To facilitate transparent discussion, we encourage users to create issues and/or submit pull requests with your feedback. Our general process is to incorporate user feedback on a roughly quarterly basis based on review with our legal team, but in the early stages this may occur significantly more often.
Other
39 stars 23 forks source link

How will app-level ToS collisions be handled? #9

Open fields opened 12 years ago

fields commented 12 years ago

Presumably, there will be a ToS / community guidelines for each app, and one much less restrictive one for the API. If we're talking about app-level filtering so that messages can be targeted to a certain type of app (but maybe not a specific app), will there be a collision if those apps have different terms?

What's the thinking on how this will work?

mattflaschen commented 12 years ago

It shouldn't be an app-level TOS violation to receive messages that the app wouldn't allow you to send. Perhaps the API TOS could specify that.

JoshBlake commented 12 years ago

@fields I'm not sure I'm following what the objection here is. It would help if you could provide a concrete example.

In general I think ADN should provide an application ToS guideline that outlines what options an app developer has in terms of restricting core rights or granting extra rights such that the app's ToS remains compatible with the ADN ToS. If these were enumerated well, ADN could even provide a ToS generator tool on the developer portal. I'm visualizing something like how Creative Commons enumerates the different options and the pros and cons of each.

As long as the core ADN ToS gives app developers enough flexibility, I'm imagining three core variations. I'll describe them in terms of restrictions on use of content submitted through the app. That is just one axis, but there could be others or some finite choices that are separate.

  1. App ToS is less restrictive about use of content. An example would be a plug-in for a blogging engine or other content management application that primarily deals with content outside of ADN, but some content is submitted through ADN like blog summary and links. These types of apps may not make any restrictions about content that users put into it if they're primarily utilities or tools. "This app makes no restrictions on content. Portions of content that are submitted to ADN must comply with the ADN content guidelines/ToS."
  2. App ToS exactly copies the right grants of ADN. An example would be an ADN client that is used primarily for accessing and generating ADN content. "All content accessed or submitted through this app must comply with the ADN content guidelines/ToS."
  3. App ToS is more restrictive on the content. An example would be a game or private corporate network app which always submits content to ADN with a access control policy that only allows the same application to retrieve the content. "All content submitted to this application will only be usable from this or other instances of this application. This app may display additional content from ADN generated elsewhere."

One variation of the above might be protocol-limited apps which allow content exchange with apps from other developers that support the same protocol, such as a chess-game protocol. Those apps might fall under #2 or #3 depending upon whether they also submit regular ADN posts (such as for an in-game chat room) to the general network, or just within the protocol network.