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] https://gitlab.com/fdroid/fdroid-website/blob/master/_docs/Build_Metadata_Reference.md#AntiFeatures [2] https://redmine.replicant.us/issues/1629 > [1] https://gitlab.com/fdroid/fdroidclient/issues/564 -- Website: https://fossencdi.org OpenPGP: 0F30 D1A0 2F73 F70A 6FEE 048E 5816 A24C 1075 7FC4 Key download: https://wiedmeyer.de/keys/ww.asc
signature.asc
Description: PGP signature
_______________________________________________ Replicant mailing list Replicant@lists.osuosl.org http://lists.osuosl.org/mailman/listinfo/replicant
