One important distinction that I see missed here is that of an API vs. a service.
Snapchat provide a service, which I mentioned in another comment here that they have every right to enforce terms of service on, and restrict or allow usage as they see fit.
Snapchat also provide an API (which, in this scenario can also be considered a network protocol). This API can be used to access this service.
Now that I've had a look at the code, I've noticed that it includes the API keys which grant programs using this library the appropriate access permissions for the service. I think this is wrong, and that these keys should not be included in an open source library. The rest of the code however, is fine, as it simply implements a protocol.
If I were to develop something like this, I would leave out the API keys and have the user of the library fill them in. In principle, and as someone else has mentioned here, it would be possible to develop and operate your own service which uses this protocol/API. And I see nothing wrong with that.
Well, except of course that the whole notion of an app which presents information for a set period of time after which the user can no longer view it is inherently flawed, since eventually someone's going to figure out how to not erase/hide the information.
Snapchat provide a service, which I mentioned in another comment here that they have every right to enforce terms of service on, and restrict or allow usage as they see fit.
Snapchat also provide an API (which, in this scenario can also be considered a network protocol). This API can be used to access this service.
Now that I've had a look at the code, I've noticed that it includes the API keys which grant programs using this library the appropriate access permissions for the service. I think this is wrong, and that these keys should not be included in an open source library. The rest of the code however, is fine, as it simply implements a protocol.
If I were to develop something like this, I would leave out the API keys and have the user of the library fill them in. In principle, and as someone else has mentioned here, it would be possible to develop and operate your own service which uses this protocol/API. And I see nothing wrong with that.
Well, except of course that the whole notion of an app which presents information for a set period of time after which the user can no longer view it is inherently flawed, since eventually someone's going to figure out how to not erase/hide the information.