JayFoxRox
commented
4 years ago Closed haitrec closed 4 years ago
JayFoxRox
commented
4 years ago 
theScrabi
commented
4 years ago So far we didn't reverse eginere we red the public available documentation. @TheAssassin what do you think?
TheAssassin
commented
4 years ago These clauses in some contracts such as ToS or licenses (the latter are often called "shrink wrap licenses" in this context) often prohibit reverse engineering. The question you need to ask is therefore, "does that apply to me?" (i.e., "can I legally reverse engineer this thing?"), as pointed out in the previous posts.
One big problem I have with this issue is: this is way less a question of copyright than civil law/contract stuff. The client app is open-source (no copyright infringement possible by reading that code and extracting knowledge), and APIs can AFAICS not be copyrighted (only the usage can be limited). You should adjust the issue title.
I'll split this post into three parts. A philosophical one, a context one, and a legal one. That said, I'm not a lawyer, I just work a lot with legal documents. This is not legal advice, and I take no responsibility. If in doubt, ask a lawyer! Lawyers are liable for answers they give you, at least here in Germany. So, if you follow their advice and fail, they're accountable. There's websites where you can get such advice from actual lawyers for a couple of bucks.
In any case, I can recommend the excellent talk BahnMining by David Kriesel, which also covers the legal aspects of his webscraping resp. API data downloading nicely. (TL;DR: he asked Deutsche Bahn for permission to download the data, and they agreed.)
I'd like you to ask yourself another question first: "Do I think they'd sue me at all?"
Publicity is important to companies, and in the current situation, I think even if you might not act entirely legally, it'd be a PR nightmare for a company to sue you folks for not adhering to some weird unclear ToS/license.
You have no financial advantage from this project, nor do your users have. The original app also doesn't generate any revenue as far as I can see to its developers. We cannot know about Google, but I doubt there's a direct revenue stream generated by users of the API. That'd run against any data protection principle. So, another good reason not to sue you, and another good reason why a case might be rejected by a judge even if you were.
Really, I don't think there'd be a huge problem. But again, this is my personal opinion.
In any case, you could even ask for permission to be on the safe side. Worst case, they say no, but then they might not even be able to sue you (well, of course they can try to sue you and that'd be pretty annoying/expensive for the time being, but they might in the end lose).
Anyway, let's talk about the context. The question we first need to answer is which legal documents are relevant in this context. @haitrec mentioned the Google API ToS. Are there any other ones? I am not at all into this topic. I was just pinged here.
Regarding the Google ToS, I'd recommend you to talk to the MicroG folks. They've reverse engineered Google APIs, and apparently don't have any legal issues (at least as far as I can see). They have some experience that might be relevant to you.
Let's look at the legal side of this issue. Personally, I'm more into German/EU law than international law, but I've done some research on the topic recently. But, as said, please don't rely on it.
First, you need to find out whether you agreed to terms that explicitly forbid reverse engineering at all. If you are not subject to such contracts, you're perfectly fine. As long as they don't forbid it, they have no base to even sue you. If they do, things get more interesting.
As you probably have used these Google APIs, you likely agreed to their ToS due to you accessing them. This is annoying but it's how the world works. Of course, that only works as long as you're aware of these ToS, but for APIs, I doubt any judge would believe you if you'd say you used them accidentally and didn't know what you were doing. You already stated this here.
So let's talk about reverse engineering in general. Most of the time, reverse engineering appears to be legal for purposes such as security research, bug fixing, et cetera. This is said in the context of software (reverse) engineering. You can easily run into problems if you use the knowledge for "business purposes", e.g., if you'd reverse engineer a software and sold cracks/cheats for it, or rebuilt and sold a product from that knowledge. (You might not even be held liable for the reverse engineering per se, but for violating patents or similar.)
For classic software or hardware, there's therefore many attempts to annoy people during reverse engineering such as obfuscation etc.
That knowledge is widely known in the software engineering community. But there's a rather new topic, and that's API reverse engineering. Web APIs are offered as a public service, they're interfaces for other software. As far as I can tell, reverse engineering cannot be considered a copyright or whatnot offense. In fact, often enough, header files in software projects etc. aren't really protected by copyright, as they only describe interfaces most of the time (other code may be). If you use a header file to interface some other software, that's usually safe.
So, the reverse engineering itself should be fine and you likely won't run into problems.
So far so good, right? Well, not really. The real issue only begins now.
ToS don't only cover the reverse engineering of APIs, but they cover the actual usage. The question is if your users can safely use your app without running into problems with the providers. May I even build a third party client for <insert service here>?
In the real world, there's plenty unofficial third party clients for many popular services. For instance, there's a few clients for Discord (a topic I've looked into recently; really, don't use that platform, it sucks in sooo many ways) and many more. Most of the time, the platforms don't mind this at all, as these clients make new groups of customers accessible.
Since you are building a sort of unofficial third party client, you might also want to look into that topic for more information.
Worst case scenario btw. is usually a "you violated our contract, you're banned from our service" kind of response. It's a question of civil law, not criminal law. But in this context, I think banning third party clients isn't even doable easily. I don't see how you could implement this safely without breaking the privacy promises all parties have made so far.
TL;DR: IMO the reverse engineering should be fine for you guys. The interesting question is whether there will be action taken against people using your app.
If you can, ask a lawyer about the situation. I gave a few pointers about the topics which are related to your work, and which ones are less related. You probably should consider yourself an unofficial, third party client, and look for other similar projects and their experiences.
P.S.: Regarding reverse engineering itself, you're likely not subject to US law until you publish your result in some app store. Then, you might be filtered out because they don't want to risk anything. But it's not your problem, it's the app store owner's. I highly doubt you'd be sued by anyone regarding this. Since Google offer the API you intend to use, they might already sort you out because they can.
haitrec
commented
4 years ago Thank you for the in depths answers. So after reading these and rereading parts of the terms and agreements, I come to the following conclusion: The EN Service Additional Terms forbid quite much, but they do not apply to us, since we do not actually use the service (at least I don't). They also refer to the Google APIs ToS, but anyway, I did never accept them. We probably all have accepted the Android SDK License Agreement, but it does not cover the EN API. So here we should be safe as well. Also the inner workings of the EN service should not be a trade secret (then paragraph 3, section 2.b of the GeschGehG could apply), since they are documented publicly.
Since you are building a sort of unofficial third party client [...] The interesting question is whether there will be action taken against people using your app.
This should not be a problem as far as I can see. We do not build a third party client to access the API, we replace the API and the underlying service. If we can legally do this, the result will be a completely free piece of software. Then google's terms of service do not apply for the users.
Anyway, I will read a bit more and look at MicroG and other existing examples.
TheAssassin
commented
4 years ago Thanks for the additional links.
This should not be a problem as far as I can see. We do not build a third party client to access the API, we replace the API and the underlying service. If we can legally do this, the result will be a completely free piece of software. Then google's terms of service do not apply for the users.
As long as you don't use any Google APIs but host your own, you should be safe indeed. Nobody can complain about you not using their APIs.
Happy hacking!
Lurkars
commented
4 years ago I ran into another legal question in my Exposure Notification API project regarding Corona Warn App and as stated out in the first answer to my question, this will also belong to your Fork of CWA. So you may be interested in following this issue regarding the use of the backend servers https://github.com/corona-warn-app/cwa-wishlist/issues/130
From what I have found in the internet, we should be quite safe against any thinkable copyright complaints from google when publishing the EN API reimplementation. All information I have used for the reimplementation so far is available in the source code of the Corona-Warn-App. However, the Google APIs Terms of Service explicitely prohibit reverse engineering. Thus I would be glad if an expert in this field could provide some more information here. Also feel free to contact me via mail, if you have (professional) experience in this field and want to work through the topic with me.