[Replicant] F-Droid FSDG compliance issue (was: Website updates for Replicant 6.0 release)
wreg at wiedmeyer.de
Mon Mar 20 20:10:32 UTC 2017
Wolfgang Wiedmeyer writes:
> Denis 'GNUtoo' Carikli writes:
>> On Thu, 16 Mar 2017 00:01:37 +0100
>> - Would it also be possible to fix the FSDG compliance by:
>> - Making a script to filter out non-fsdg compliant f-droid packages,
>> by filtering out packages with anti-features
>> - Asking f-droid people to maintain a separate repository for
>> Replicant without the packages with anti-features.
>> - Asking f-droid people to use that separate repository on Replicant
>> (they can probably detect that the Android distribution running is
>> This would fix the Replicant FSDG compliance issue, and not get
>> Replicant unlisted from the list of fully free (Android)
> I need to look into this. At the OHSW workshop, we tried to build
> F-Droid using the Debian Android SDK, so it would be possible to work on
> the app without the need to install the Google SDK (among other
> reasons). But we were not successful at the time.
> An important aspect should be how easy it is to update such a setup. If
> the F-Droid maintainers are willing to maintain such a separate
> repository, would it be easy to move new apps into the Replicant repo
> and newly found non-free apps out of the repo?
> Detecting Replicant in F-Droid and then applying changes is probably the
> only way to get these changes accepted in F-Droid. The script could be
> done by us and we update it ourselves. Considering all of this, why not
> create a blacklist that is easy to update? The blacklist is created by
> the script and called by F-Droid during parsing of the app list of the
> We then only need to make merge requests to update the blacklist and
> otherwise help to improve their antifeature marks.
> I fear that by simply filtering out apps with antifeatures as it is
> currently planned in the upstream bug, too many are filtered that are
> actually free software. Having our own blacklist would mean a lot more
> flexibility when it comes to deciding which apps should be hidden.
Now that I have gone through the issue, I think that the blacklist is
not a good idea. It actually doesn't look that complicated. We need to
submit a change to their website repo that at least clarifies the
NonFreeAssets anti-feature and possibly the ads and tracking
Then we need to implement a feature for the F-Droid client that filters
out all the anti-features that are not FSDG-compliant and the feature
needs to be enabled when Replicant is detected. For now, it looks like these
non-FSDG-compliant features are NonFreeDep and NonFreeAdd. As you
already wrote in the issue, the other anti-features can probably be
categorized as informational or annoyances. I don't know yet if there is
already code in the F-Droid client that allows to filter for specific
anti-features. I only know that it has a setting that allows to grey out
all apps with anti-features.
I think it's a bad idea to filter all apps with anti-features. This is
just too broad. And even if it would solve the FSDG-compliance issue for
now, in practice users would just try to find ways to circumvent this
restriction, so it would have little actual effect. I would include
myself in this group of users.
But of course, we still need to verify if certain apps are correctly
tagged with anti-features. Emulators were such apps you mentioned.
>  https://gitlab.com/fdroid/fdroidclient/issues/564
OpenPGP: 0F30 D1A0 2F73 F70A 6FEE 048E 5816 A24C 1075 7FC4
Key download: https://wiedmeyer.de/keys/ww.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 818 bytes
Desc: not available
More information about the Replicant