It's probably best to continue this discussion on the issue
tracker[1][2][3]. I updated the issues and some the information there
already contradicts some of what I wrote below due to new findings.

Best regards,




Wolfgang Wiedmeyer writes:

> 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
>>>     Replicant).
>>>   This would fix the Replicant FSDG compliance issue, and not get
>>>   Replicant unlisted from the list of fully free (Android)
>>>   distributions.
>> 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
>> repo.
>> 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[1], 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[1] that at least clarifies the
> NonFreeAssets anti-feature and possibly the ads and tracking
> anti-features.
> 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[2], 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.
> Best regards,
> Wolfgang
> [1]  
> [2]
>> [1]

OpenPGP: 0F30 D1A0 2F73 F70A 6FEE  048E 5816 A24C 1075 7FC4
Key download:

Attachment: signature.asc
Description: PGP signature

Replicant mailing list

Reply via email to