4 ms·
While that would be a great law to have I don't think it exists. If I make an API for my own client software and put in the terms that you can only use my syste
by t0mas88 6y ago
While that would be a great law to have I don't think it exists. If I make an API for my own client software and put in the terms that you can only use my system in the combination in which I provide it, I think you're out of luck.
The only law I can think of that could get involved is the DMCA. If my client implements usage/content restrictions (very stupid design) you using the API with another program in violation of the terms could be considered circumventing the content restrictions and that's illegal due to the DMCA.
- sneak 6y agoYou seem to be conflating the DMCA, which regulates copying of copyrighted material, and the CFAA, which criminalizes unauthorized access. I don't think there is any case law related to "which client was used" applications of the CFAA. I can't really imagine any reasonable circumstance where someone would be authorized with one client and unauthorized with another. It's not really a reasonable position; if you offer a free network service on the internet, and anyone is authorized to use it, I don't know of any legal basis for gating that authorization on "user of your software". Perhaps some internet-clueless judge will one day disagree, but that's not how the mores and norms of the internet work today. Signal doesn't get to declare me a criminal if I write my own client software to talk to the Signal API servers (or use some other open source software I found), regardless of Moxie's squeaking. Either your service is public and open to everyone, or it isn't.
- Hello71 6y agoThis is reminiscent of anti-scraping lawsuits: "you may only access LinkedIn using the LinkedIn web application; it is a violation to access it using curl". Ironically, Google's position in that regard is likely to bite them here, where someone else wants to use unconventional clients.
- majewsky 6y ago> The only law I can think of that could get involved is the DMCA. The Supreme Court's upcoming decision in Oracle v. Google may also be relevant from what I gather.
- 411111111111111 6y agoThat's not quiet correct. Just because you write it in your ToS doesn't mean that users agreed to it. If your api is publicly readable (without any auth which you could only have by agreeing to the ToS), then whatever they write into their terms is irrelevant. This doesn't apply here however, because you can only sync with Google servers if you have an account, which means you must've agreed to the ToS. It's also the user that's breaking the ToS, not the developer of the competing browser... But that's irrelevant here in guess :)
- simcop2387 6y agoActually the CFAA would say otherwise as far as someone using it without agreeing to your ToS.
- 411111111111111 6y agoafter verifying on Wikipedia I can only conclude that you somehow misinterpreted my comment, as it addresses misuse of api by circumventing authentication, rate limits etc. That's entirely unrelated to unauthenticated and public APIs and their possible ToS relevance.
- simcop2387 6y agoThat's not how it's been interpreted in courts in the past, they've taken it to mean that a violation of the terms of service can be a violation of the CFAA, https://www.rcfp.org/scraping-not-violation-cfaa/ https://www.rcfp.org/scraping-not-violation-cfaa/ Some cases have been found to not be a violation given a public API, but in the case of sync like this, it is not a public API. It's a public facing api but it requires authentication (the keys in question) in order to be used, this means that using google's keys without authorization from google to use them for that purpose would likely be seen as a CFAA violation by the courts.
- deleted 6y ago[deleted]