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

App.net Materials is Vague and Restrictive #5

Closed duerig closed 12 years ago

duerig commented 12 years ago

'Service' is unclear. Does it refer to the Alpha client? To any client built on the API? The API itself? To something else?

The following restrictions seem to preclude a lot of legitimate activity, much of which is already happening now with the blessing of the app.net team:

(i) publicly performing or publicly displaying the Service

This seems to preclude screenshots, public presentations that either display or show a screenshot of app.net, etc. This is in addition to posting videos of the service being used, etc. If it really means any client built on top of the API, then that means I can't post a screenshot of quickapp or AppApp. If it means the API itself, it is unclear how you would perform or display it.

(ii) modifying or otherwise making any derivative uses of the Service or any portion thereof

Modifying the service itself sounds like a prohibition against hacking which is fine. But making derivative uses seems like the whole point of app.net. @q used it to make a blog commenting system. Many others are thinking in terms of using it as a information backbone for other derivative systems like games.

(iii) using any data mining, robots or similar data gathering or extraction methods;

Many current apps use datamining and bots. These include both appnetstats.com by @clint and the various search engines which mine the data in order to construct search indices. They are constantly updated because bots are gathering the latest posts.

(iv) downloading (other than page caching) of any portion of the Service or any information contained therein;

The above datamining apps are driven by mass downloading and retention of data. This is definitely something that needs to be regulated so they don't swamp the system. However, preventing it altogether seems to preclude such services.

(v) reverse engineering or access to the Service in order to build a competitive product or service

Not terribly worried about this one. But given that you have an open API, it is reasonably possible for people to do this without trying to understand the internals of your system. So this seems mostly moot.

(vi) using the Service other than for its intended purposes

Here, 'intended purposes' is never defined.

fields commented 12 years ago

I strongly agree with all of these points.

mattflaschen commented 12 years ago

(v) should be removed, and ideally the API license (soon to come) should explicitly allow it. If the ADN API becomes a de facto standard (much like the EC2 and S3 APIs, which are used in competing products), that could easily end up helping ADN.

jhubball commented 12 years ago

(i) "publicly performing" was covered in issue #3, now closed. Summary is that it is necessary to preserve our IP protection for the service itself (logos, code, etc) but does not prohibit public use of the service.

(ii) through (vi) will be superseded by the developer ToS with respect to doing any of those things using the API.