Skip non-FSDG-compliant apps on Replicant during repo data parsing

Replicant is committed to follow the GNU Free System Distribution Guidelines (FSDG). Apps with certain anti-feature flags in F-Droid violate these guidelines and thus shouldn't be available in the F-Droid client on Replicant. See the corresponding bug on the Replicant issue tracker.

#564 discusses this, although only the case of having apps with anti-features optionally filtered. To be compliant with the FSDG guidelines, all violating apps must not be accessible and there shouldn't be a setting to make them visible. Simply not saving them in the database seemed the easiest solution.

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.

A check on the system property os.version ensures that only on Replicant the apps are skipped.

added 1 commit

• 99db6ebd - Skip non-FSDG-compliant apps on Replicant during repo data parsing

Compare with previous version

added 1 commit

• 8f8afdb1 - Skip non-FSDG-compliant apps on Replicant during repo data parsing

Compare with previous version

Thanks for your contribution @wowie. I'm familiar with the discussion that occurred on #564. This change is of course a lot more severe, in that we are forceably preventing users from ever having the option of installing such apps. Is that really the end goal of FSDG compliance for replicant?

I suspect this is the relevant clause from the guidelines:

A free system distribution must not steer users towards obtaining any nonfree information for practical use, or encourage them to do so[1]. The system should have no repositories for nonfree software and no specific recipes for installation of particular nonfree programs[2]. Nor should the distribution refer to third-party repositories that are not committed to only including free software; even if they only have free software today, that may not be true tomorrow. Programs in the system should not suggest installing nonfree plugins, documentation, and so on[3].

[1] - Right now I think F-Droid has a good balance of "not steering users" towards nonfree software, because we actively highlight when there are issues the user should think about via anti features.

[2] - I guess this is where we fall down, because if Replicant includes F-Droid, and F-Droid includes software which fails the relevant tests, then Replicant is falling fowl of this.

[3] - F-Droid would be a "program in the system", and your MR here is trying to address this point.

My question is: What if the user chooses to install Firefox on their own fruition? I don't get the feeling the FSDG guidelines are trying to prevent this, just not provide it as an option when the user installs the distro. This change here forces all Replicant users to never be able to get such apps from F-Droid, even if they choose to. The only way is for someone to set up a separate repository which lies to the end user about the anti features to get passed this.

I'm familiar with the discussion that occurred on #564. This change is of course a lot more severe, in that we are forceably preventing users from ever having the option of installing such apps. Is that really the end goal of FSDG compliance for replicant?

I think your further comments clarify this already a lot more and I will try to answer the question below with the other one.

[2] - I guess this is where we fall down, because if Replicant includes F-Droid, and F-Droid includes software which fails the relevant tests, then Replicant is falling fowl of this.

[3] - F-Droid would be a "program in the system", and your MR here is trying to address this point.

My question is: What if the user chooses to install Firefox on their own fruition? I don't get the feeling the FSDG guidelines are trying to prevent this, just not provide it as an option when the user installs the distro. This change here forces all Replicant users to never be able to get such apps from F-Droid, even if they choose to. The only way is for someone to set up a separate repository which lies to the end user about the anti features to get passed this.

Point number 2 is important. If there would be a setting that unhides apps with FSDG-violating anti-features, then this would qualify as "specific recipes for installation of particular nonfree programs".

As Replicant lacks the infrastructure and maintenance power to host their own repositories, not saving any information about FSDG-violating apps from the F-Droid repos in the F-Droid client on Replicant seems a good solution for now. If the Replicant project could host their own repositories, all FSDG-violating apps would be removed from the repo which would have almost the same effect on the client side.

I think it's important to clarify that this is not about forcibly preventing users from obtaining such apps. Users are free to do what they want with their Replicant devices, including installing non-free software. In the end, that's what it's all about with free software, right? And you are right, the FSDG guidelines also don't mention that any such precautions need to be implemented.

It's about not giving the impression that Replicant encourages or approves the installation of such apps. If there would still be an "official" option (or recipe in the general sense) to install these apps, users could think that the project is still somewhat ok with providing such apps on Replicant although they are marked with anti-features. Besides, there is also the problem that users may not know which of the anti-features violate FSDG and which don't.

Replicant users would still be free to manually download an app from the F-Droid website and install it by enabling "allow installation from unknown sources" in the settings. There are no plans to prevent users from doing this and this would send a clear message to users that this is not a way of installation which is recommended by the project.

Of course, there are ways to trick the checks like setting up a repo that lies to the user about the anti-features, as you wrote. I hope that my comments above make it clear that this is not about finding ways to force users to not install these apps, so it doesn't really matter if it's possible to circumvent the checks.

Thanks!

I totally agree with the goal here, but the XML parsing is not the place to enforce this kind of thing. The XML should translate straight to the database, otherwise, we'll have a really messy, unmaintainable architecture. The places to enforce it are on the fdroidserver inputs, i.e. don't put non-free apps in the repo, or mark them accordingly, or in the fdroidclient view, i.e. hide all apps in the database with a given anti-feature.

Keep in mind that the f-droid.org community has decided to allow non-free apps in the repo, and that should be respected. Anyone can start their own repo with their own restrictions.

I totally agree with the goal here, but the XML parsing is not the place to enforce this kind of thing. The XML should translate straight to the database, otherwise, we'll have a really messy, unmaintainable architecture.

I already feared that this would be the case. There is also a test case that seems to compare the total number of apps in the XML with the number of apps in the database.

The places to enforce it are on the fdroidserver inputs, i.e. don't put non-free apps in the repo, or mark them accordingly, or in the fdroidclient view, i.e. hide all apps in the database with a given anti-feature.

Keep in mind that the f-droid.org community has decided to allow non-free apps in the repo, and that should be respected. Anyone can start their own repo with their own restrictions.

Would it then be ok to still use the replicantFSDGviolation() function as is and do the check in the needed place(s) where app lists are generated?

I first tried to implement it in this way, but I couldn't manage to completely hide a list entry. I got to the point where the entry would be blank but there still would be white space where the app would be listed otherwise.

Off the top of my head, this should be an option to the AppProvider.Helper method used to feed the lists to the adapters which power the app listing views. @pserwylo would know better than me.

Also, for the record: data about non-free apps is totally compatible with free software because pure data cannot be copyrighted. So storing data about non-free apps does not violate the 100% Free Software goal.

@eighthave: I'm not particularly fussed about this. If other people are happy to have Replicant specific code in F-Droid (I'm not particularly fussed, purely because I really like what they do), then it is no different to other information we throw away during the repo update. Think of various localizations where we just choose one to store, even though that will cause weirdness if the user changes their locale. I think the goal should be for us to pull what we find interesting from the index, and drop the rest.

Probably easier to just not add it to the database like this MR does.

So I'll leave this open for just a short time longer in case others want to comment, but if there are no further objections, I'm going to merge this towards the end of this week. If we are happy with the general concept of the official F-Droid client preventing apps with anti features from showing on Replicant devices (even if it was installed by the user, not preinstalled by Replicant) then I see no problem with this implementation of that feature.

merged

No objections, so merged. Thanks @wowie.

I already said in this thread that this is a bad, unmaintainable approach. Please revert. It won't even actually solve the problem it is trying to solve since it totally ignores the index-v1 code.

Yes, but then I said that your approach was even more problematic and this was actually a nice elegant solution (that is actually here, implemented, and ready to solve a problem that has been important to the replicant team for ages). I am intimately familiar with the database code, and it will be far more maintainable to do it this way.

I'm happy to propose a fix for index-v1 as that is clearly missing here. Apologies for missing that aspect of this MR.

I support the goal of a fully free mobile platform 100%.This is not an elegant solution, it is addressing the issue in the entirely wrong place, and it is very incomplete. To keep this maintainable, we need to have the same data structures throughout the project, without crazy little hacks at each step. I just spent months working towards achieving that, this fells like someone just took a shit on that work. If we make F-Droid shitty in the process of making more "pure" free software, that only serves to make free software look like it forces software to be shittier. This is a terrible strategy.

Instead, read up on the history of gcc. It was developed on Solaris and other non-free platforms. They focused on the things they could do well, and didn't just throw in ugly hacks to make it look like more free software. We need to do the same, or we will surely lose this fight.

I agree that this is a hack and we should think this through better. I especially agree because this is forced behaviour on Replicant. What if I want this behaviour on Lineage or another ROM? What if I don't want this behaviour on Replicant? etc.

Well, if my intentions were to make F-Droid shittier, I could think of a lot of easier ways to achieve this than to try to get familiar with the client source code and to try to find a solution for a long-standing issue. If I only wanted a quick hack, I would never have opened this merge request and I would just have forked the client and included some version of this patch.

I fully disagree with the notion that this is about making more "pure" free software or making it "look like more free software". The GNU FSDG guidelines are pretty clear and I think they make a lot of sense when thinking about the reasoning behind the guidelines. That being said, I personally like the Debian Social Contract and I'd love to see some parts of that in the GNU FSDG and vice-versa. It's important that a distribution has clear guidelines for inclusion of software.
An app is either free software according to certain rules or it's not. An app is either admissable in accordance to certain guidelines or it's not. I don't see where there is room for making something appear in certain ways.
I'm absolutely fine with when someone thinks that this is no big deal, but I don't like it when someone skews someone else's reasoning or intentions to make them look silly or like a non-issue.

I entirely agree. The problem was entirely the technical approach in this merge request.