Project

General

Profile

Feature #1878

Feature #1629: F-Droid does not respect the GNU free system distributions guidelines

Make f-droid be FSDG compliant again to be able to include it again in Replicant

Added by Denis 'GNUtoo' Carikli over 1 year ago. Updated 22 days ago.

Status:
New
Priority:
Immediate
Assignee:
-
Category:
Freedom
Target version:
Start date:
04/23/2018
Due date:
% Done:

0%

Estimated time:
Spent time:
Resolution:
Device:

Description

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.


Related issues

Related to Replicant - Feature #1895: Implement a self-update system for RepWifiClosed09/26/2018

Actions
Related to Replicant - Issue #1887: Use F-Droid's signed build of RepWifi so that it can be easily updated in F-DroidClosed08/26/2018

Actions

History

#1

Updated by Denis 'GNUtoo' Carikli over 1 year ago

  • Category set to Freedom
#2

Updated by Kurtis Hanna over 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.

#3

Updated by Kurtis Hanna over 1 year ago

there's movement happening here: https://gitlab.com/fdroid/fdroidclient/issues/843

#4

Updated by Denis 'GNUtoo' Carikli over 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 over 1 year 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 over 1 year ago

After thinking about it, I think the most sensible approach would be to go the reproducible builds way, as f-droid seem to work on it too:
#7

Updated by Kurtis Hanna over 1 year 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."

https://gitlab.com/fdroid/fdroidclient/issues/843#note_88730028

#8

Updated by Kurtis Hanna about 1 year 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ä about 1 year 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 about 1 year 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ä about 1 year 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.

#12

Updated by Denis 'GNUtoo' Carikli about 1 year ago

I'm in favor of removing it until we find a good enough solution.

Denis.

#13

Updated by Kurtis Hanna about 1 year 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 about 1 year 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 about 1 year 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ä about 1 year 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 about 1 year 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 about 1 year 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.

https://gitlab.com/fdroid/fdroidclient/merge_requests/452#note_99672180

#19

Updated by Fil Bergamo about 1 year ago

  • Related to Feature #1895: Implement a self-update system for RepWifi added
#20

Updated by Fil Bergamo about 1 year ago

  • Related to Issue #1887: Use F-Droid's signed build of RepWifi so that it can be easily updated in F-Droid added
#21

Updated by Hans-Christoph Steiner 11 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:
https://matrix.to/#/!HwocBmCtBcHQhILtYQ:matrix.org/$1545320484336698ckpkZ:matrix.org?via=f-droid.org&via=matrix.org&via=t2bot.io&via=disroot.org

#22

Updated by Hans-Christoph Steiner 11 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.

#23

Updated by Hans-Christoph Steiner 11 months ago

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.

#24

Updated by Fil Bergamo 10 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.

Fil

#25

Updated by Denis 'GNUtoo' Carikli 10 months ago

Thanks a lot for working on this.

#26

Updated by Denis 'GNUtoo' Carikli 8 months ago

  • Target version changed from Replicant 6.0 0005 to Replicant 6.0 0004
#27

Updated by Denis 'GNUtoo' Carikli 8 months ago

At the FOSDEM me and Fil Bergamo worked on a better way to deal with
the issue.

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
repository.

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
Replicant devices.

The downside of this approach is that it fully depends on F-Droid to
accept and merge our patches.

Denis and Fil

#28

Updated by Denis 'GNUtoo' Carikli 7 months ago

This was also sent upstream in the following bug report: https://gitlab.com/fdroid/fdroidclient/issues/564

#29

Updated by Denis 'GNUtoo' Carikli 25 days ago

  • Subject changed from Remove f-droid from replicant until it we find a way to make it FSDG compliant again to Make f-droid be FSDG compliant again to be able to include it again in Replicant
  • Target version changed from Replicant 6.0 0004 to Any version
#30

Updated by Denis 'GNUtoo' Carikli 25 days ago

I've changed the title of the bug and removed if from the Replicant 0004 release target version: f-droid has been removed already, after the Replicant 0003 release.

#31

Updated by Denis 'GNUtoo' Carikli 22 days ago

  • Tracker changed from Issue to Feature

Also available in: Atom PDF