Thank you for the clarification, glad to hear that it shouldn't conflict with the TOS.
On 8/28/09, Andrew Badera <and...@badera.us> wrote: > > 1. If you're not putting messages in front of someone, it's not spam. > If you're not aggressively following and @'g people, it's probably not > spam. > 2. It would probably be better to do it all with one account -- most > users don't wish to sign up for and maintain more than one. But people > having multiple accounts is not, to my knowledge, against TOS by any > means. (But maybe it should be .... ) > > ∞ Andy Badera > ∞ This email is: [ ] bloggable [x] ask first [ ] private > ∞ Google me: http://www.google.com/search?q=(andrew+badera)+OR+(andy+badera) > > > > On Fri, Aug 28, 2009 at 12:24 AM, Peter J. Walsh<xor.g...@gmail.com> wrote: >> >> tl;dr: I'm a hobbyist programmer writing an application that passes >> data to/from devices using twitter, and was wondering if this would be >> a violation of the TOS? >> >> or if you prefer, the longer version: >> >> I'm a hobbyist programmer writing an application. An application that >> controls other applications on a host by receiving data sent to >> twitter from a remote device such as a cell phone. It's not very far >> along, so far the only thing it can do is query the status of uTorrent >> at the request of the remote device and return it through direct >> messaging, and add torrents passed through a direct message. I was >> wondering if this portion would constitute spam? >> >> The application also requires a person to have two accounts, one for >> themselves, and one for the application. As a hobbyist programmer I >> don't really spread my applications around, just to a few people to >> help test them. So far this particular application has only been sent >> to one other person. So I was wondering also if this creation of two >> accounts would cause issues? If this would cause issues, I could >> rewrite the application to only need one account for all it's users, >> but this would hinder it's adoption of other applications that don't >> support a HTTP interface. >> >> Of course if any of these things would cause any issues I would be >> more than willing to discontinue development. >> >
