Issue #1629: F-Droid does not respect the GNU free system distributions guidelines
Remove f-droid from replicant until it we find a way to make it FSDG compliant again
It's several been years that f-droid is not FSDG compliant (anymore?).
The easiest solution would be to:
- Remove f-droid in Replicant source code
- Write a blog post on why it was removed
Once removed it will probably create more incentive to look for acceptable solutions.
#2 Updated by Kurtis Hanna about 1 year ago
Here are some thoughts from Jeremy_Rand and I, sensiblemn, on the Replicant IRC:
Jeremy_Rand: how much work is it actually to add a feature to F-Droid that hides apps from searches if they have specific antifeature tags? It sounded to me like the F-Droid folks would be happy to merge such a feature, and it also sounded like it wouldn't be that hard since the database already handles that. If we assume that no GUI is needed (i.e. you would enable/disable specific antifeature hiding via setpref or something like that), is this something that would be straightforward?
Seems rather unfortunate to remove F-Droid completely when such a minor feature request is all that's needed, and the F-Droid devs are willing to merge it
the impression I have is that fixing the relevant issues in F-Droid would probably be a couple of days of work max for someone who's familiar with Android app development
So it seems to me that removing F-Droid from Replicant is not really an effective use of Replicant development effort/time. But maybe I'm unaware of something that would change that calculus.
sensiblemn: seems like no one followed up with F-Droid about this proposed solution to the FSDG issue https://gitlab.com/fdroid/fdroidclient/issues/843
Jeremy_Rand: sensiblemn_: maybe I'm misinterpreting that issue, but wouldn't that approach require that Replicant maintain their own F-Droid repo? That seems like an unnecessary time sink, given that F-Droid's repos already work just fine for the FSDG once the antifeature-containing apps are hidden
FWIW, my Java skills aren't great, but I wouldn't mind trying my hand at adding the relevant hiding code to F-Droid once my thesis is out of the way.
sensiblemn: i think that we should formulate a plan of action and then approach F-Droid with our various suggested fixes. the gitlab issue that I linked to is one of a few different paths by which this issue could be fixed. fixing the issue upstream seems like the best solution. it'd be great if F-Droid could have two seperate main repos, with one of them being FSDG compliant. it would also be great if F-Droid could see, in a privacy respecting way, if the client is using Replicant and, if so, use the FSDG compliant repo. i haven't seen this suggested to F-Droid yet.
Jeremy_Rand: yeah, so the proposals to maintain a separate repo and/or detecting Replicant and behaving differently are, in my opinion, not really good options. The reason for this is that different users might prefer to filter different antifeatures. For example, maybe I'm on Replicant but I want to blacklist the "tracks users" antifeature, which doesn't have anything to do with FSDG. Or maybe I'm on LineageOS
because I require GPU acceleration, but I don't trust apps on F-Droid that are nonfree so I want to filter out those things without having to install Replicant.
It's a lot more flexible to simply have the F-Droid app check a config file that lists which antifeatures to filter
That way power users can edit it to their liking without switching OS and without recompiling F-Droid. And the users who don't edit the config file will still get the FSDG-compliant results on Replicant.
sensiblemn: maintaining separate repos seems like a quick and dirty fix, i agree. if it comes down to removing F-Droid from Replicant and having them start maintaining a seperate repo that is FSDG, it seems like a good option. i agree that your solution is a better long term fix.
#4 Updated by Denis 'GNUtoo' Carikli about 1 year ago
Edit: workaround formatting issues.
I don't see an easy solution. Here are the possible solutions I could think of: * Not enabling anti-features by default(user changable) when Replicant is detected (+) No maintenance needed (-) Not very fine grained (-) Would f-droid have anti-features? (-) May not be FSDG compliant: How does that compare to a deactivated nonfree repository in a common GNU/Linux distribution, where the user just has to press a button in the settings to enable nonfree? (I) Users will be able to easily switch (-) non-fsdg applications would probably be kept: Users should at least be informed of the issue. * Adding an FSDG metadata and hidding by default(user changeable) non-fsdg applications when Replicant is detected: (+) No maintenance needed (-) Would f-droid be non-fsdg compliant? (-) May not be FSDG compliant: How does that compare to a deactivated nonfree repository in a common GNU/Linux distribution, where the user just has to press a button in the settings to enable nonfree? (I) Users will be able to easily switch (-) non-fsdg applications would probably be kept: Users should at least be informed of the issue. * Making our own repo with the existing tools: (+) It is super easy according to someone I know who did it for some shcools in France. (-) All applications are re-signed. Users will loose their application data/settings because of that: many users already have applications comming from the official f-droid repository, switching to Replicant repository means that you have to uninstall your applications (and loose their data) and reinstall from Replicant repository. (+) Default repository settings can probably be shipped by Replicant. * Hosting only the FSDG compliant apk and generating the repo XML: (+) Uses the same repository: Users would be able to switch to Replicant repository quite easily (-) According to that same person, there is no standalone tool to generate the repo XML. So some work is needed to do that. (I) Users will be able to easily switch repository (+) Default repository settings can probably be shipped by Replicant. * Building the APK reproducively with the default tools and swapping/adding the signature from the f-droid repository: (+) Uses the same repository: Users would be able to switch to Replicant repository quite easily (+) Might be easy if we can swap the signature afterward. We also need to check how reproducible are f-droid builds. Maybe they already have tools to swap signatures for reproducible builds. (I) Users will be able to easily switch repository (+) Default repository settings can probably be shipped by Replicant. * Upstreaming changes to the f-droid client to totally hide the non-fsdg applications: (+) Uses the same repository: Users would be able to switch to Replicant repository quite easily (-) Requires some work: This could be done by adding changes that totally hide the non-fsdg applications to f-droid and and upstreaming it as a build flag. Then the modified f-droid could be build along the normal f-droid and be distributed in the same repository. (-) Users will not be able to see all applications again easily as the main f-droid client would then not be FSDG compliant and not visible. This will be a big issue for upstream. * Forking f-droid client to totally hide the non-fsdg applications: (-) The f-droid in the officieal repository will be signed with a different key. It could be updated by making a Replicant repository just for f-droid. (+) Same repository for the rest of the applications As I see it: * We could ask for advises on the gnu-linux-libre mailing list to see if and how the anti-feature or an fsdg button would be acceptable * Swapping the signatures might be the best option, however I've no idea how much reproducible is f-droid.
#5 Updated by Dylan Erdahl 12 months ago
What's the point of trusting the "free" apps on F-Droid anyways?
F-Droid devs can't even sign apps properly; we've been waiting on a completely free implementation for a long time, BUT...
- crickets **
Supposedly this is why @moxie0 wouldn't release an official build on F-Droid for the notorious signal messaging app
EDIT: moxie asked them to drop Signal, f-droid devs laughed at his reasoning but complied.
#6 Updated by Denis 'GNUtoo' Carikli 11 months ago
#7 Updated by Kurtis Hanna 10 months ago
Oh, here's an update from F-Droid:
"we don't want to allow external factors to override the f-droid.org repo."
"A very slightly modified whitelabel build seems like the way to go for Replicant, but then you have to publish your own F-Droid releases."
#8 Updated by Kurtis Hanna 9 months ago
Hans-Christoph Steiner from F-Droid wrote:
"We just had a big discussion related to this in #1494 with the final result of that discussion in !705
One key thing that came up in that discussion is that we don't want to allow external factors to override the f-droid.org repo. F-Droid promising only free software by default, but if a ROM could override the default repo, then it could break that promise while still looking just like F-Droid. For example, CyanogenMod could include a repo of their proprietary apps by default.
In whitelabel builds, the default repos can be anything you want. A very slightly modified whitelabel build seems like the way to go for Replicant, but then you have to publish your own F-Droid releases."
Here's some things that come to mind after reading this:
What are people's thoughts on F-Droid's suggestion that Replicant create a slightly modified version of a whitelabled F-Droid?
I assume that adding Replicant artwork to a whitelabled version of the F-Droid App would be the easy part, and taking on the responsibility to maintain our own app repo from here on out would be the harder part.
Maybe it would be good to have a discussion about how much time and energy it would take to publish our own app repo in order to solve this Freedom related issue that occurs due to the fact that we use vanilla F-Droid in Replicant.
Do you all think that we could automate a lot of the maintenance of hosting our own app repo by using F-Droid's app repo upstream?
Would we also have to add our own F-Droid build system to our infrastructure that signs the built apps with our own key or could we simply have apps with F-Droid's signature in our Replicant flavored F-Droid App, but have some sort of script that totally hides the non-fsdg applications?
Dylan mentions that "F-Droid devs can't even sign apps properly". I don't recall ever hearing this complaint before. Are there ways that Replicant could sign apps better than F-Droid does?
#9 Updated by Joonas Kylmälä 9 months ago
- Forking f-droid client to totally hide the non-fsdg applications:
(-) The f-droid in the officieal repository will be signed with a different key.
It could be updated by making a Replicant repository just for f-droid.
(+) Same repository for the rest of the applications
or we can upload our fork of F-Droid to the official F-Droid repository and then mirror it to our FSDG compliant repository which Replicant users will then use. This way we don't need to build anything or sign anything, therefore reducing the amount of work needed to do by us.
#10 Updated by Kurtis Hanna 9 months ago
- Target version changed from Replicant 6.0 to Replicant 6.0 0005
I'm asking the F-Droids moar questions about this whole thing: https://gitlab.com/fdroid/fdroidclient/merge_requests/452#note_98249014
#11 Updated by Joonas Kylmälä 9 months ago
It looks like it's going to take some time to reach a consensus which way to solve this issue, be it fork, changes in upstream, our own repository, or something else. Which ever way we are going to go for it's also going to take some time to implement it. Therefore, I'm in favor of removing F-Droid until the issue has been resolved.
If you are in favor or not in favour of removing F-Droid from Replicant for the time FSDG issue is not resolved please state so here.
#13 Updated by Kurtis Hanna 9 months ago
I feel like this is important to point out: "Not all anti-features in F-Droid violate the FSDG guidelines, so no need to filter all of them. Currently, it looks like the anti-features Tracking, NonFreeAdd, NonFreeDep and NonFreeAssets are incompatible with the FSDG guidelines." https://gitlab.com/fdroid/fdroidclient/merge_requests/452
#14 Updated by Kurtis Hanna 9 months ago
I was just looking at F-Droid's Yalp Store webpage and it has no warnings related to it having "features you may not like" or "anti-features", like it does when you pull it up on the F-Droid app. https://f-droid.org/en/packages/com.github.yeriomin.yalpstore/
It seems like they are trying to fix this: https://gitlab.com/fdroid/fdroid-website/issues/158
Also, even when users say that they are running Replicant and, presumably, are viewing the Yalp store from withing the F-Droid app, they still get confused about whether the Yalp Store violates their software freedoms. https://redmine.replicant.us/boards/9/topics/14953
#15 Updated by Denis 'GNUtoo' Carikli 9 months ago
I'm aware that not all anti-features conflict with the FSDG. My point in not making packages with anti-features available was to fix the issue faster:
1) If we remove f-droid, then the issue is fixed.
2) If having all anti-features disabled enables us to get back an FSDG compliant F-droid faster, then it would be a good start
3) Ideally we should indeed only remove non-compliant applications, but that can be done later if we get a compliant f-droid faster.
#16 Updated by Joonas Kylmälä 9 months ago
F-Droid repository contains non-free software (https://f-droid.org/wiki/page/Category:Apps_with_NonFreeAssets_antifeature) and we cannot refer to it as FSDG say "Nor should the distribution refer to third-party repositories that are not committed to only including free software"
So that would leave us with starting to host our own repository or find some other application repository that is FSDG compliant.
I tried to raise the non-free assets issue on #fdroid IRC channel but I think that might have been the wrong channel to go about it because I got no replies.
#17 Updated by Kurtis Hanna 9 months ago
It seems like it would be a good idea to increase the amount of dialogue we have with F-Droid about this whole thing, but I'd like to be fairly intentional about how we do it. My thoughts are that we should open tickets upstream in F-Droid related to:
0) Can vanilla F-Droid be used in Distributions that seek FSDG compliance? Maybe we could even ask Donald Robertson, the Licensing and Compliance Manager at the FSF, to weigh in once we and F-Droid start a discussion in the ticket if we still are confused about anything. I don't think we should make the assumption that F-Droid wouldn't want vanilla F-Droid to be in FSDG compliant distros. There have been discussions in the F-Droid issue tracker related to distributions that want to mess with F-Droid default repos by adding some nonfree repos as well, but I don't think our specific situation has been discussed very thoroughly by the F-Droid devs. https://gitlab.com/fdroid/fdroid-website/issues?scope=all&utf8=%E2%9C%93&state=closed&search=fsdg
1) What sort of changes F-Droid would accept upstream so that distributions that ship F-Droid can optionally choose to read a config file from the system partition that says what antifeatures to blacklist from displaying in the app. This is needed because F-Droid rejected the way in which Wolfgang tried to do it: https://gitlab.com/fdroid/fdroidclient/merge_requests/452 This could be helpful regardless of how ticket 0 plays out because perhaps other distributions would benefit from it.
If upstream ticket 0 results in us having to decide between FSDG compliance and F-Droid, Replicant will be choosing FSDG compliance. We then, at that point, should create an upstream ticket about how to fork a whitelabled F-Droid in the least painful way (where we could minimize the amount of new code that needs to be written, utilize upstream F-Droid as much as possible, figure out if we can utilize their Verification Server and Reproducable Builds, and ensure that we can get app updates released at the same time or very shortly after F-Droid does).
Just for context, here's the list of Antifeatures types and the amount of apps in F-Droid's main repo that have labels with these specific types of Antifeatures: https://f-droid.org/wiki/page/Antifeatures
I really don't want to unilaterally open these tickets in F-Droid without getting some feedback on my overall gameplan here, so please respond with your thoughts.
Lastly, I think that we shouldn't remove F-Droid from 6.0 0004. I think that release should be focused exclusively on getting upstream security updates in user's hands as soon as the new builds are thoroughly tested.
#18 Updated by Kurtis Hanna 9 months ago
Here's a question I posted on F-Droid last week:
@eighthave I volunteer with the Replicant project. To be compliant with the FSDG guidelines, Replicant must ensure that all violating apps must not be accessible and there shouldn't be a setting to make them visible. What sort of merge requests can the Replicant devs work on upstream in F-Droid to make this a reality?
Here's the response:
To meet that strict requirement, sounds like you'll need to host your own repo that is a subset of f-droid.org. We have mirroring in beta now, so that would make the process a lot easier. Basically, you'd mirror f-droid.org, then programmatically delete APKs based on the Anti-Features, then publish that to your own repo. We can of course add that repo to the built-in list, where it would be disabled by default but available to all. Then the Replicant ROM could include the new add_repos.xml file !705 to auto-add the Replicant repo and enable it in F-Droid.
If filtering is enough, then you could implement filtering based on Anti-Features. There is the skeleton of that already in place.
#21 Updated by Hans-Christoph Steiner 5 months ago
I want to revisit this topic since I think no one in F-Droid actually wants non-free things in the repo. The hard part is doing the work of finding all the non-free things, and either a) building without the non-free bits, or b) removing them to f-droid.org in a responsible way.
It would be nice to have an F-Droid "non-free" repo that was off by default, like in Debian, but then I guess FSF doesn't consider that to be 100% free. In any case, its all in open question. More discussion here:
#22 Updated by Hans-Christoph Steiner 5 months ago
Jeremy_Rand and I had a great conversation at 35c3 about how to solve the non-free issue in the f-droid.org collection. He proposed doing it via full fledged AntiFeatures filters that can be controled by a config file in the /system partition. That would let the ROM set antifeatures to entirely hide, including in the preferences. We worked through the details of that idea, and could find no blockers besides someone doing the work. From my point of view, the only downside is that the f-droid.org app collection would still have non-free stuff in it. But he made the good point that this approach gives more flexibility, for example, Replicant can decide separately on the NonFreeNet antifeature.
To comply with the FSF's specs, in JJeremy_Rand 's idea of AntiFeature filters with the system config file, F-Droid in Replicant would by default not show any non-free apps at all, and there would be no GUI preference to make non-free apps visible. There would be the option of sending a config file to F-Droid to enable non-free apps on Replicant, if the user wanted to do that.
About handling new antifeatures for Replicant, you could have a whitelist of allowed antifeatures so new anti-features are automatically filtered until the whitelist is updated. That would mean existing Replicant installs would have to manually update the Replicant whitelist on their device if new any ones are added. Antifeatures get added like once ever 1-3 years, so not often, and we have no plans for adding any. So I think it would be best for Replicant to use a blacklist and just watch the F-Droid changelog for changes in anti-features. F-Droid would also try to notify you.
So this means that the f-droid.org index file would still contain metadata about non-free apps but F-Droid client could be setup to never act on them. The upside of Jeremy_Rand's approach is that it can be solved by one developer implementing it, and the UI concept of stronger AntiFeatures would be welcomed, and has been discussed in the past as something we should do. I still would like to see the f-droid.org collection actually be fully free without needing to be filters. That is not something that one person can decide on, that has to be a community consensus on that, so it requires lots of discussion
About @wiewo's previous implementation of the filters, they added a hack to some of the core security sensitive code, it needs to be a different approach that happens on more the UI side. Adding complexity to the most essential part of the code that is already complex is not the right way.
#24 Updated by Fil Bergamo 5 months ago
Hans-Christoph Steiner wrote:
Jeremy_Rand and I had a great conversation at 35c3 about how to solve the non-free issue in the f-droid.org collection. He proposed doing it via full fledged AntiFeatures filters that can be controled by a config file in the /system partition. That would let the ROM set antifeatures to entirely hide, including in the preferences. We worked through the details of that idea, and could find no blockers besides someone doing the work.
I like the approach you described, and I think it's a much more sensible and sustainable one, compared to completely removing F-Droid from Replicant.
In theory, this shouldn't even be hard to implement, and I can say by now I can work on this.
I will contact Jeremy Rand to coordinate with him, but at a first glance this seems to me like a feasible and reasonable solution.
I should add: we didn't work out a plan for who will implement this. There isn't anyone lined up to do it on the F-Droid side. We would welcome merge requests on this. There are also F-Droid core devs available for hire for this kind of thing.
As I said, I can work on that, and coordinate with the Replicant Staff to then upstream our changes if we ever get the work done.
For now, thank you very much for your proposal.
#27 Updated by Denis 'GNUtoo' Carikli about 2 months ago
At the FOSDEM me and Fil Bergamo worked on a better way to deal with
As the Replicant project cannot guarantee to always have enough time
to maintain a fork of f-droid data and f-droid, we are looking for a
solution that has the minimum amount of maintenance cost for the
Replicant and F-droid projects.
The idea here would be to make and upstream patches to f-droid that
would add the ability to have whitelists and blacklists of
anti-features that can be configured at build time.
Replicant would then ship a custom build of f-droid that:
- Whitelists anti-features that are not in contradiction
with the FSDG guidelines.
All the other anti-features would be blacklisted by
default to give us time to analyze new anti-features
when they are introduced, which would probably not
be that often.
- Changes at least the logo, and name of the application
to make it clear that this is not a stock f-droid and
that it has clearly been modified.
As I understand from what Fil told me, f-droid source
code has already a functionality to do that, that is
called "whitelabel builds".
As f-droid data can be used to automatically build packages
at each new release, we would then add the Replicant
whitelabel build to the f-droid data as well.
As the stock f-droid is not compliant with the FSDG
guidelines, we would then need to upstream the ability
to blacklist specific packages or class of packages in
order to Blacklist the official f-droid client and
other whitelabels builds:
In the Replicant whitelabel build we would then blacklist
the official f-droid client build.
As f-droid and Replicant whitelabel builds will be different
application, with different namespaces (org.replicant.[somename]
and org.fdroid.fdroid) both could hopefully still coexist.
If this is not possible then we would need to blacklist the
Replicant whitelabel build in the official f-droid client
and other whitelabel builds that uses the default
The core mechanism of this approach (which is also its advantage) is
that Replicant would only have to maintain a build recipe for the
F-Droid client, as opposed to maintaining a full fork.
This could hopefully allow for merging any upstream updates in an
automated way, thus our "custom" client would be constantly tracking the
upstream F-Droid client, and would auto-update itself once deployed on
The downside of this approach is that it fully depends on F-Droid to
accept and merge our patches.
Denis and Fil