Closed YellowApple closed 6 months ago
For reference, there is an issue over at F-Droid to handle this situation: https://gitlab.com/fdroid/fdroiddata/-/issues/2973
@vitorpamplona that basically makes Amethyst non-free, which means we'd have to unlist it at F-Droid. While I can see why you don't wish Amethyst being used that way (and I'm with you there), forbidding/restricting its use in such a way is taking away freedom.
By the way: to regulate those things is the task of the law. One shouldn't use any means to do "illegal stuff" – but it's not in our powers to enforce that.
I am confused. Why are we mixing the license with the terms of use? These two files are separate legal matters. The Privacy is used by the Play Store to manage the distribution of the executables. The MIT license relates to the source code only.
Why are we mixing the license with the terms of use?
Whether or not software is FOSS is dependent on the full set of conditions under which users can use/modify/distribute the software. That would include terms of use which users are required to accept before they can use the app.
The Privacy is used by the Play Store to manage the distribution of the executables.
Gotcha; I'm guessing you're referring to this requirement?
Privacy policy
Adding a privacy policy to your app's store listing helps provide transparency about how you treat sensitive user and device data.
The privacy policy must, together with any in-app disclosures, comprehensively disclose how your app collects, uses, and shares user data. This includes the types of parties with whom it’s shared. You should consult your legal representative to advise you of what is required.
- For apps that request access to sensitive permissions or data (as defined in the user data policies): You must link to a privacy policy on your app's store listing page and within your app. Make sure your privacy policy is available on an active URL, applies to your app, and specifically covers user privacy.
- For apps that target children: You must link to a privacy policy on your app's store listing page and within your app, regardless of your app's access to sensitive permissions or data. Make sure your privacy policy is available on an active URL, applies to your app, and specifically covers user privacy. Note that even apps that do not access any personal or sensitive user data must still submit a privacy policy.
Add a privacy policy
- Open Play Console and go to the App content page (Policy > App content).
- Under "Privacy Policy," select Start.
- Note: If you’ve previously added a privacy policy and want to make changes, you’ll see and select Manage instead of start.
- Enter the URL hosting the privacy policy online.
- Save your changes.
It doesn't seem like the paragraphs at issue are required to be part of the privacy policy for the app to be compliant. Was the Play Store rejecting the app without those paragraphs present?
In any case, is that something that can be controlled with a build flag, so that Play Store builds get the Play-Store-required privacy policy while F-Droid builds get the intended MIT license? Alternately: can acceptance of the privacy policy be made optional, and/or can it be moved to an "About" page (or similar) in-app instead of being part of the out-of-box experience?
Yes, those were specifically added to comply with software distribution laws worldwide from the Play Store reviewers. I am surprised F-droid doesn't require the same thing. Rights to use the source are different from the rights to use the distributed binaries (which in some cases I am liable for, in some others F-Droid itself is liable).
In other words, the MIT license removes any author liability from the misuse of the code. But when the author is also providing the system as binaries (which is an additional service in every jurisdiction I know of), there are many other legal issues that the source code license won't cover.
And I don't know about you, but I am not comfortable allowing people to use the Play Store version or the FDroid version for these activities written in the Privacy statement. Most of them are local crimes that should not happen anyway.
This has nothing to do with the source code license, which people can still download, compile and use in nefarious ways.
This has nothing to do with the source code license, which people can still download, compile and use in nefarious ways.
So it does not apply to the APK produced and distributed by F-Droid. Maybe you could phrase it that way? I vaguely remember we had a comparable case not that long ago, and solved it by such a rephrasing.
I updated the PRIVACY.md to clarify that the terms of use is for the distributed applications and not the source code.
Let's hope it helps
@vitorpamplona so what did change, apart from "Amethyst" => "the Amethyst app for Android"? I guess changing "you cannot" to "you should not" would help more (and would be more true as well, as technically "cannot" is not correct even :wink:).
No, the first line now reads:
Effective as of Jan 20, 2023 for the distributed applications in the Play Store and the F-Droid Catalogue
Ah, so now it explicitly applies to F-Droid. Forgive me if I ask if that's not just the wrong direction taken? I thought exactly that was what we wanted to avoid? You wrote:
the terms of use is for the distributed applications and not the source code.
Now someone (here: F-Droid) takes your source code, which is under a FOSS license and thus got the 4 freedoms granted – and you say
for the distributed applications in the Play Store and the F-Droid Catalogue
thus taking one of the 4 freedoms away again. Explicitly. That way you force F-Droid to take your app down, as it violates the inclusion criteria – because you contradict the very license (MIT) you've applied to the source and thus (at least partly) render it moot. Quote from the MIT (emphasis mine):
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so
"Without restriction" doesn't match "You cannot use Amethyst to …" IMHO. If you apply that to the APK you distribute at Play, that's one thing – but you cannot apply it to what a 3rd party compiles of the MIT licensed code. That's absurd, if I may say so.
Apologies if this sounds harsh, no offense meant – I just try to clarify why that is, IMHO, a no-go.
Oh, PS: that would then also apply to your app in my repo, correct?
You are still confusing distribution (the key word in the new sentence) with the source code license.
F-droid is not distributing source code. It's distributing a binary as a service. That has nothing to do with the openness of the source code.
So you say "to deal in the Software without restriction" does not apply to dealing with the software? If I can deal with the source code without restriction, how does that not include the binaries I produce from it? Sure that it's me confusing things here? I admit I'm not a lawyer – but "without restriction" sounds pretty clear to me. Dealing with the source *without restriction" also includes compiling it. And distribution is explicitly mentioned.
Besides, it's not only my personal understanding (as you can see by the other participants here). I won't argue that anymore – I just tried to find a solution both sides can live with. Unfortunately that doesn't seem to be possible – so I'm afraid F-Droid will have to remove Amethyst then. But that's not my personal decision either, it's for the F-Droid team to decide. Feels sad, though – after all the work you, your team and I invested to get your app in. It's your app, so the decision of the terms of course is yours. Still, I'm disappointed. I had a little hope there, but that's gone now.
Nevertheless, I wish you the best for you and your project. Maybe one day… well.
Yep you can compile it and distribute it. You cannot use the version we compile and distribute for whatever you want. Very different legal frameworks between the two.
Does f-droid require that the code is FOSS or that the distribution is FOSS? (I have never ever seen something requiring distribution to be FOSS, it doesn't even make legal sense). Those are not the same thing.
We pass all of these requirements: https://f-droid.org/en/docs/Inclusion_Policy/#:~:text=All%20applications%20in%20the%20repository,application%20from%20the%20published%20source.
I don't know where the restriction to publish on f-droid comes from.
All applications in the repository must be Free, Libre and Open Source Software (FLOSS)
Applications. And note it says "FLOSS", which includes the L for "libre". Don't confuse that with "code openly available". You've decided for "reproducible builds" – so after F-Droid builds the APK and compares the results with yours, it indeed ships yours when the two match – which gives extra trust for those using the app (F-Droid checked it, you signed it) and the possibility of cross-updates (should one channel fail, e.g. your app get blocked at Play, they can seamlessly update from another).
But yes, F-Droid requires that everything is F/LOSS. Even down to the tools used to create the APK. That also includes the software used to maintain the repo (server), and the website (client). Can all be found at GitLab under https://gitlab.com/fdroid
But I'm tired discussing that if the outcome is already clear, we're both wasting our time now Vitor. You won't change your mind, and F-Droid won't change its rules.
We match all of that, @IzzySoft It's not about changing my mind... I am happy to do so.
What else do you want me to add to the Privacy to make this right?
As pointed out above: it's Google who forces this upon you, so please apply that only there. And as I already suggested: turning the "you cannot"¹ into "you should not" would make the problem vanish. But I cannot tell if that would satisfy Google. If not, I personally would blame it on them (trying to monopolize again; I'm pretty sure they know about this implication). In that case, if your intro says
Effective as of Jan 20, 2023 for the distributed applications in the Play Store
(and leave F-Droid out there), it can only be applied to Play, so the sting has been removed as well. I guess one of the two should do, both together I'm pretty sure should do (at least that would totally convince me – but again, IANAL :wink:)
¹ you cannot control that anyway :wink: and neither you, me nor F-Droid are "legal forces".
Thanks for chiming in "over there", @vitorpamplona! I'll leave further discussion to the team then (especially as I won't have time to participate in it for the next week or so, being bound to other tasks). :crossed_fingers: for a good outcome!
Thanks Izzy.. I hope we can keep the app on f-droid. I just need some clarity on who goes to jail when a user uploads illegal content through the version shipped by F-Droid.
I understand your position Vitor. But have you ever heard that a car maker was held responsible when one of their cars was involved in, say, a bank robbery? The contracts don't have such a clause there. To me it should be clear that, whenever you use anything to do something illegal, blame is on the evildoer, not on the tool. So "You cannot use Amethyst to…" to me even sounds like the wrong angle. The point is, you should not do these things anyway, at all. And it's not the software developers task to take care for that.
But again, I understand your point. Nowadays, you can rob people of all their personal data and spy on them all you want if you're a company big enough – but forget a tiny little checkbox in your app as a single dev of a small project, and you're potentially screwed…
So the question "who goes to jail" is for a lawyer to answer I'm afraid. And would be a question for the other 4k apps at F-Droid as well; I didn't hear (but neither check) that any of those established such a TOS. :man_shrugging:
But have you ever heard that a car maker was held responsible when one of their cars was involved in, say, a bank robbery
Social media is different. There are regulations in place for marketplaces and apps that capture and share users content.
It's similar to banks. If you are making illegal transactions, your bank is indeed liable.
Yes yes, that's what I mean by "IANAL". Exactly that part is what my mind refuses to grasp, it's different rules depending on the "medium": why would the software developer be held responsible for the use of their tool – but not the factory producing kitchen knives?
But btw, the bank is liable for different reasons (I'm working for one, so I get that stuff "indoctrinated" twice a year): it is a service (not an app). So it's not the "app maker" (here: of the banking app) who's held responsible in such a case, but the service provider (bank) which must keep eyes open for "patterns" indicating illegal transactions¹. It won't be held responsible if it had no means to detect a certain fraud – only if it had but did not.
So in the case here: you as the developer of the app have no means to control its usage – those who run the relays might have. So if at all, it would be on the relay operators – not on the app developers. But again, IANAL…
¹ "fraud detection", e.g. a credit card normally only used for few big payments suddenly used for massive shopping sprees; an account that usually receives salaries of monthly 2k suddenly receives multiple 1k payments a month and immediately spends 90% of that to some accounts abroad, etc.
it's different rules depending on the "medium": why would the software developer be held responsible for the use of their tool – but not the factory producing kitchen knives?
It's not about the developer, but the shipper. The problem with us is that the shipper and the developer are the same. So the confusion.
When you make an app available in a market, you are "servicing" that market and must comply with local laws as a "service" provider. Putting code on GitHub is not servicing a market, but placing an app in a store or a catalog is the definition of servicing the market. Thus all these other requirements.
For instance, F-Droid is technically required to evaluate every app's content ratings in many jurisdictions like the US and Europe, and in case of Europe, make sure they comply with GDPR. They don't do this right now, but if they have any legal staff, that would be one of the first things to solve.
It's not about the developer, but the shipper.
So the downtown store selling the knives gets sued? :thinking: Or the website operator where the banking app (not the banking service) is hosted? Never heard that. But then again, IANAL – and there might be a place where they have such crazy rules.
They don't do this right now
Sure? You were there when I reviewed your app :wink: You couldn't publish a single web browser if you were held responsible for the websites visited with it. And guess what: yes, we had "legal contact" in the past, where the other side claimed "illegal activities". That was either defended/repelled – or at worst the app was taken down when justified. Full stop. :man_shrugging: Would we on the other hand refuse to take down a clearly illegal app when notified, that'd be a different case altogether.
Oh, and to fill the last gap: where the app intended especially for illegal use, the case would of course be different – and a weapon seller of course is obliged to take certain precautions as well, as a tobacco shop owner is :wink:
So the downtown store selling the knives gets sued? 🤔
Believe it or not, in banking, healthcare, and now social media, it's actually a very common threat. Every subsector has a regulatory agency that creates rules for entering the market. In the US, for instance, you don't see that with knives, with definitely with guns. Guns shops get sued all the time for selling to folks they cannot sell to. But in other countries, they may add protections for knives as well. The manufacturer of the knife is usually not targetted (author of the code), but the seller/the service provider is.
You couldn't publish a single web browser if you were held responsible for the websites visited with it
Web browsers are not social media apps to regulators because domain names are registered with the government and thus separate the liability from the browser into the domain name owner. Nostr pubkeys are not registered... yet...
@vitorpamplona It sounds like:
Many of the things you're saying I am unable to verify:
Web browsers are not social media apps to regulators because domain names are registered with the government and thus separate the liability from the browser into the domain name owner.
Where would I look to see if this is true? I know the last part isn't true in the United States (Section 230), but I can't falsify the rest because I don't know who "regulators" are.
When you make an app available in a market, you are "servicing" that market and must comply with local laws as a "service" provider. Putting code on GitHub is not servicing a market, but placing an app in a store or a catalog is the definition of servicing the market. Thus all these other requirements.
What additional requirements? Where are they written?
Social media is different. There are regulations in place for marketplaces and apps that capture and share users content.
What have you seen that makes you say this? What are the regulations?
Thanks Izzy.. I hope we can keep the app on f-droid. I just need some clarity on who goes to jail when a user uploads illegal content through the version shipped by F-Droid.
In the United States, users are responsible for user-generated content.
As a point of comparison, Infinity (another social media app on F-Droid - in this case for reddit) does not include such prohibitions in the privacy policy linked within the app's Settings page. If Infinity doesn't need them, then I'd be surprised if Amethyst does.
Guns shops get sued all the time for selling to folks they cannot sell to.
In this analogy, F-Droid is the gun shop, and you're Smith & Wesson.
I am primarily concerned with laws and regulations that include a line or two that may invalidate Section 230 or similar protections worldwide. For example, in the US, a set of laws called FOSTA/SESTA basically says that anything having to do with "assisting, facilitating, or supporting sex trafficking" means that Section 230 immunity doesn't apply. So, I want to add that specific sentence (you cannot "assist, facilitate, or support sex trafficking" through the use of the app) to the app's terms of use. The current terms are basically a compilation of those things.
To be clear, I am not a lawyer. But I have had some guidance on this in the past.
As a point of comparison, Infinity (another social media app on F-Droid - in this case for reddit) does not include such prohibitions in the privacy policy linked within the app's Settings page. If Infinity doesn't need them, then I'd be surprised if Amethyst does.
Thank you for this reference. It feels like they are quite loose on their terms.
But I did notice that they say: "These Services do not address anyone under the age of 13". To me, this means that people under 13 cannot use the app, which from the first post, would break their FOSS status. But I hope we are beyond this point now.
FOSTA/SESTA are tricky, since the definition of an interactive computer service could be construed to mean a browser.
But I think you're a step removed there. The interesting section is this:
Whoever, using a facility or means of interstate or foreign commerce or in or affecting interstate or foreign commerce, owns, manages, or operates an interactive computer service (as such term is defined in defined in section 230(f) the Communications Act of 1934 (47 U.S.C. 230(f))), or conspires or attempts to do so, with the intent to promote or facilitate the prostitution of another person shall be fined under this title, imprisoned for not more than 10 years, or both.
This reads to me as saying you'll be liable if:
The definition of interactive computer service is based on a pretty weird definition of "access software provider" that could be read to include Amethyst (and a browser!):
(4) Access software provider The term "access software provider" means a provider of software (including client or server software), or enabling tools that do any one or more of the following: (A) filter, screen, allow, or disallow content; (B) pick, choose, analyze, or digest content; or (C) transmit, receive, display, forward, cache, search, subset, organize, reorganize, or translate content.
So I can see why this might be a concern. But the second clause ("intent to promote or facilitate prostitution...") seems like a very tough bar to meet in for something like Amethyst, since Amethyst could be used with any relay. How would one show any such intent with such a setup? Terms of Use along these lines feel like they would be something relays would want to think about, rather than authors of clients.
FWIW, it seems like FOSTA-SESTA has only been used once since it was signed in 2018. It seems most of the cases in the study linked from that article were prosecuted on standard trafficking charges.
IANAL, but in case folks forgot, the MIT license disclaims liability for how the software is used:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Another reference: Hacki (a client for Hacker News, on F-Droid) also includes an EULA which does not (as far as I can tell) include non-free license terms. It does include the worrying provision that said EULA can be changed at any time, but unless/until that mechanism is used to introduce non-free terms, I don't think that would be an issue.
But have you ever heard that a car maker was held responsible when one of their cars was involved in, say, a bank robbery? The contracts don't have such a clause there.
How about a gun used in the comission of a crime? Might depend on the jurisdiction, but anyone who pays attention to the political environment knows of the pressure to make firearms manufacturers liable for illegal use of their products.
To me it should be clear that, whenever you use anything to do something illegal, blame is on the evildoer, not on the tool.
That statement simply doesn't reflect (legal) reality. In an era where we have governments suing auto manufacturers for making vehicles "too easy" to steal, I would expect (at any time) the criminalization of "facilitators" for a wide range of "unapproved" activities ("spreading misinformation" or "copyright violations," for example, but of course, a large number of other things, as well).
I would not write any software for use by others at the present time. And wihle I don't believe for a moment that the disclaimer that Vitor wants to include would protect him in any way (not a lawyer, but I have taken law classes, and one can not absolve oneself from statuatory liability simply by disclaiming said liability), allowing such terms of use (in my opinion) seems like the absolute minimum that open source licenses should tolerate as an effort to attempt to protect the authors of open source software to the maximum degree possible.
Closing this discussion since we found a way to "dual license it" (play and fdroid) months ago.
Describe the bug
PRIVACY.md
includes the following:This means that Amethyst is non-free software, contrary to the MIT License specified in
LICENSE
.Beyond that, the license text is also unclear:
Such ambiguities make compliance with the license terms difficult, even if I did consent to them (which I do not; what I choose to send to or receive from a relay is solely the business of myself and the relay).
The paragraph following it is also concerning:
The ability to introduce new potentially-non-free license terms to which all users of all versions of Amethyst are automatically bound without any apparent mechanism to notify users and obtain explicit consent means that even if Amethyst is currently free software, that could change at any time without warning.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Removal of the offending license terms (or explicit permission for derivative works to remove them), or clarification in
LICENSE
and elsewhere that Amethyst is not actually subject to the MIT License (and consequent removal from e.g. F-Droid's default repositories).Additionally, pointing the "terms of service" link to the MIT License (or whatever other license) as it exists in the actually-installed version of the app would alleviate concerns around users of older app versions being unexpectedly bound by new license terms for which they had no opportunity to refuse consent.
Video and Screenshots
N/A
Device (please complete the following information):
Bounty (in Bitcoin sats) offered for a solution
N/A