Permission to distribute Signal or a renamed fork on F-Droid #9966
Comments
|
If it was up to me I would simply remove all ML code and features. Face recognition is not secure anyway as a picture could be used to trick it (I never tried Signal so I don't know what the ML is used for besides that) |
|
Hey there! Just some background on the website release: it was never intended to be completely free of any Google Play dependencies -- instead, all our builds have a fallback such that during registration, if we detect there's no Play Services, we will fallback to using a websocket for notifications. Using FCM for notification delivery still provides the most reliable user experience and is something we'd prefer to use if the user has Play Services available on their device. Concerning F-Droid, we already providing an auto-updating APK directly from our site, and we really don't want forked versions of the app maintained by other parties connecting to our servers. Not only could the users using the forked version have a subpar experience, but the people they're talking to (using official clients) could also have a subpar experience (for example, an official client could try to send a new kind of message that the fork, having fallen out of date, doesn't support). I know you say you'd advocate for a build expiry, but you know how things go. Of course you have our full support if you'd like to fork Signal, name it something else, and use your own servers. I think the rest of the discussion can happen on #9644. Thanks! |
|
Hi @greyson-signal , I've force-pushed the patch in the pull request to just the utility function removal, thanks if you can merge that for now. |
@greyson-signal wow, big misunderstanding here. fdroid doesnt distribute a "forked version" - it builds the app from the official source code repo - NO FORKING at all. It automatically builds the update 1-3 days after u push an update in OFFICIAL repo - again from the SOURCE in OFFICIAL repo. i dont know where did u infer that fdroid is about forking and all. or how did u miss the part that it builds from OFFICIAL source. But i hope u reconsider ur stance know that u know. some links: |
|
fdroid also supports reproducible builds |
|
@yashpalgoyal1304
Nope, no misunderstanding on my part. I wasn't saying that F-Droid inherently requires forking -- I was responding to OP's second suggestion:
Hope that helps. |
|
How much safe this link then ? https://langis.cloudfrancois.fr/ adding respiratory Fdroid . since signal is privacy concerned . |
|
@gsbnlda as safe as any other fork I guess. Langis still includes Google binary blobs, just sets them not to be used, and publishes its source code. |
Note to anyone who happens across this thread that that's not at all how free software works. If Signal authorizes their userbase to connect to their servers, Signal has authorized their userbase to connect to their server. Those users can use whatever clients they wish. Publishers of open source/free software applications don't get to dictate what the forks do with the code. Forks of Signal are 100% free to leave the official Signal(tm) API server URLs in the source code of those forks, and distribute those forks. The software license 100% allows this, and the fact that Signal staff "don't want forked versions of the app" being used by users is, well, explicitly contrary to the license which Signal releases the Signal clients under. That's literally the point of open source: users can use forks if they so desire. Signal wants to control the "product", but critically there are two important parts here:
Fork away. Rename it so you don't violate Signal trademarks, but don't let these sorts of mixed messages dissuade you: the software license expressly permits you to make and distribute forks that talk to the Signal official API. If Signal doesn't want Signal's end users using third party clients, they can take that up with them in their Terms of Service. As of right now that has not happened, and I do not expect that it will. |
@greyson-signal I'm sorry, I'm not an experienced coder, but isn't that what "protocol version" is supposed to do? You are basically saying, if I' not mistaken, that User A with the forked version uses "Signal protocol 1". User B with the official app uses "Signal protocol 2" (the new kind of message). Then both would have a way to find out which protocol version the other is using. So the version of User B could either send the message using "Signal Protocol 1", or if that protocol has no way to deliver that particular content, the version of User B would display "Sorry, the version of Signal used by User A doesn't support that content. Please ask User A to update". By the way, if the "new kind of message" is introduced in Signal v. 25, what happens to users of Signal v. 24? They can't talk with users of Signal v. 25, and viceversa? I mean, Matrix (and before that, IRC) has basically the same idea of Signal. Is there a reason why there are no problems in using different apps (Element, WeeChat) with the Matrix protocol, but it's advisable to have just one app for the Signal protocol? |
|
Totally confused all above answers and this also https://www.twinhelix.com/apps/signal-foss/ , A fork of Signal for Android with proprietary Google binary blobs removed. |
As of May 2018, Signal's Terms of Service have stated: "You must not (or assist others to) access, use, modify, distribute, transfer, or exploit our Services in unauthorized manners, or in ways that harm Signal, our Services, or systems. For example you must not (a) gain or try to gain unauthorized access to our Services or systems; (b) disrupt the integrity or performance of our Services; (c) create accounts for our Services through unauthorized or automated means; (d) collect information about our users in any unauthorized manner; or (e) sell, rent, or charge for our Services." In this thread, a Signal team member has explicitly stated that "we really don't want forked versions of the app maintained by other parties connecting to our servers." Doesn't this already mean that forks are explicitly "unauthorized" from using Signal's official API (the "Service")? From what I've understood, anyone who uses a fork to connect to the Signal service does so in an unauthorized manner and is therefore breaking the ToS, and anyone who publishes forks that connect to the Signal service is also breaking the ToS for "assisting others" to do so in an unauthorized manner. I am not a lawyer. |
|
The choice of client software does not make access to a server authorized or unauthorized. That would be like Google saying that you're not authorized to use google.com unless you do so with Chrome. That's not how the internet (or the laws surrounding the internet) works at all.
The ToS does not apply to those who publish software based on the Signal client source code, only the software license does. The ToS applies to users who connect to the Signal service. Do not confuse Signal the free software application (with a free software license that explicitly permits forking!) and signal.org the API and web service (which is governed by the ToS). |
Believe it or not, that is exactly what appears to be happening here. A Signal representative just said above that they do not want people who use unauthorized third-party clients to use "signal.org the API and web service (which is governed by the ToS)" because it could degrade the experience of those who use the official authorized clients: "Not only could the users using the forked version have a subpar experience, but the people they're talking to (using official clients) could also have a subpar experience (for example, an official client could try to send a new kind of message that the fork, having fallen out of date, doesn't support)." Signal's ToS says that you may not assist others to use or exploit their Services in an unauthorized manner. I still don't see how the use of an unauthorized client doesn't count as unauthorized use of the service, given what they've so clearly expressed above. In order to comply with Signal's ToS, it looks like anyone who decides to publish a fork should remove every connection to the Signal service unless they've been explicitly authorized to keep those connections. Again, I am not a lawyer. This conversation appears to be going in circles, and besides, this issue tracker is not meant to be used as a discussion forum. It might be best to move this over to the Signal community forum: https://community.signalusers.org/ |
Signal's ToS applies to users of the |
|
Anyway, ToS, opposite to Software Licence, have no legal value! If Google wanted google.com to be only reached through Chrome, they would have enforced it with some kind of checks and ban accounts who are using Firefox. Same applies for Signal, if they don't want a fork to appear and connect to the server, the have two choices :
I won't personnaly create any fork, nor FDroid team will accept any fork in official repo, because them and I don't want to be in conflict with Signal devs. But just wanted to clarify : there's nothing that prevents you from creating forks connecting to the server ! Neither the ToS, nor the Software Licence. |
That is entirely irellevant here, because the ToS are not in opposition to the License, as the License doesn't grant usage permission of the signal.org API. The License gives you permission to fork the code and change it as you desire. That is however, entirely separate from using that code with the signal.org API. The code is covered by the license, the signal.org API is covered by ToS. Otherwise I could legally fork the code of Signal or Matrix and could just implement a DoS-Tool in those codes and then neither Signal nor Matrix.org could complain that I DoS'ed them? That would be the consequence of what you stated and it is just plainly incorrect. |
One can have one or the other opinion on this issue, but this is plainly incorrect. The GPL covers the code, but the permission to change the code does not include permission to use specific services. They are covered by ToS, which in this case specifically state that you may not use modified clients. You absolutely may modify those clients and use them on your own installation, but not with the signal.org API. That is not covered by AGPL, as far as I am aware of the license. If there is a passage that I missed that explicitly states that AGPL overrides ToS, then I'd be curious to know. :) Th |
The ToS says no such thing. This is a commonly repeated falsehood. Go read it yourself: https://signal.org/legal/#terms-of-service |
|
I did, emphasis is mine:
They very explicitly say that. Alternatively, I'd like to see how modified clients count as authorized given every single statement that has been made by the Signal team in the past says otherwise. |
|
Yeah, the authorized manners are those set forth in the ToS. The ToS says nothing about forks or clients. You can of course make the legal argument that unauthorized manners are anything the service operator says is unauthorized. This is what the CFAA does, and it's been generally rejected by courts and industry. Fact of the matter is, this is actually off-topic for this thread. The only part that applies to the forking and publication is the software license - not the ToS. The ToS applies to users. That means that if you want to distribute a fork, including a fork that connects to official signal.org servers, the AGPL (the software license) says that yes, you can do that. |
|
So you are now not saying anymore that the ToS don't say that, but that the ToS are invalid? Just to understand your reasoning here. |
The ToS applies to those who connect to the service as users. The statements made by the Signal team to which you refer are aimed at developers who want to release software. The only terms that apply there is the AGPL license to the code. It's clear Signal doesn't want forks connecting to their service. A user using a fork is not however prohibited in the ToS, and a developer publishing a fork that talks to signal.org is not prohibited in the software license. Furthermore, even if Signal were to codify this preference into the ToS, it's unlikely that it would be enforceable, technically or legally. As I mentioned above, this would be like Google saying that anyone using google.com without using Chrome to access it is in violation of the ToS (and potentially the CFAA!). It's nonsense and the Signal people know that. |
I'm saying that:
|
That's not what "very explicitly" means. In fact, the part of the ToS you highlighted:
...is about as vague as something could be on the topic of modified client software. |
If you say the rules under the "Using the service" section don't apply to users, then I can't help feeling that this is primarily bending the words so they say what you want them to say. In which case I'm not sure if this would be a fact-oriented discussion. |
|
In fact, a developer publishing a fork connecting to signal.org API is breaking the ToS (kind of, the ToS said nothing about specifically modified client, but the Signal team stated that forks are unauthorized). The developer account could be banned or sued (but Signal is unlikely to win with such vague ToS). Using a modified client is not unauthorized. That's what I understood from your arguments |
From how I read the ToS it is, because everything but the official clients is not authorized and the ToS specifically state that one must not use the service in unauthorized manners, which such a client would be. That is under the "Usage" section, so I intuitively this statement applies (primarily even) to usage, otherwise it seems unlikely this section would explicitly carry the title "Usage". |
This assumes that someone forking the Signal client code and publishing their modifications is also a user of the Signal service and API, which, while practically is a safe assumption, is not guaranteed. You could find a developer who has never once used Signal and has no account (and thus the ToS does not apply to them) and pay them to fork the client, make any desired modifications, and publish them, leaving all API references pointing to the official signal.org servers. This is 100% permitted via the AGPL. |
Sorry to file this as a bug report -- after my original bug report was closed, as suggested there I posted on the Signal User Community forums and filed a pull request in May 2020, but haven't received a response and don't know how else to reliably get in contact with the team.
As per the User Community discussion, I have written some patches to Signal that stub out Google Play Services, Firebase Cloud Messaging and Machine Learning code, so Signal can build and run without these libraries, connecting via WebSocket. I mentioned this on the F-Droid forums and users were receptive to the idea of distributing a Signal build there that meets their FOSS requirements, however this has never worked out in the past; the last time this was mentioned Greyson indicated signing builds would be a holdup.
So, which approach would the Signal team prefer?
In any case, could Signal please merge the patch to remove a few unnecessary calls to GMS APIs? They're all one-line tweaks (usually using Signal's existing Util library code e.g. hex conversion) and that would make maintenance easier! I've signed the CLA; the best source is the latest branch on my GitHub with -FOSS in the name (currently 4.69.6.0-FOSS). Thanks :).
The text was updated successfully, but these errors were encountered: