> To fix it our current plan is to modify the f-droid client to filter > out applications that are problematic as per the FSDG. Once this is > been, we'll then have to upstream that feature in a way where it can > be enabled or disabled at compilation time. > > This way if that works we would have 0 maintenance on the f-droid > client side as we could then upstream a package definition for that > version with a different build configuration (and branding) so that it > would be automatically built by the f-droid upstream project. > > So practically speaking we'd share the upstream repository data and > the f-droid client code but the modified f-droid would not show any > problematic applications, and users could even install both f-droid > and the version with our modification at the same time if they wish > to, so upstream will probably not have any issue with our > modifications as it doesn't affect the stock f-droid.
Would it be sufficient? Debian separates nonfree and free software by putting them in different repositories but this approach is still not sufficient to make Debian FSDG-compliant. I understand there are some nuances like Debian directing users towards nonfree repos and having marginally different set of accepted free software license than the FSF. Does that mean you won't get away with making users pull packages from F-Droid repos that also happen to serve some FSDG-incompliant apps? I have no idea. Perhaps not? I just wanted to express my concern just in case... As to the problem of apps signed by someone else not being able to access data of their previous versions, this is indeed an unfortunate thing. While you discussed an interesting possibility of there being an FSDG-compliant way to re-use authors-signed app builds, why not go the opposite way? IIUC, it was Google's unethically-motivated idea to restrict apps from accessing their data this way. If this scheme is bad for users, perhaps the best response long-term would be to fight it instead of complying with it? You could move app validation into the package manager app and then promote use of a single publicly-disclosed private key for signing. Why something so drastic? No matter FSDG-compliance, having users run binaries coming from untrusted environments seems like a veeeery unwanted thing. In fact, being able to trust the binaries is among the main benefits of using a (proper) package manager and a proper distro. Unfortunately, the problem will not go away by itself. If you make the hard decision of using a different signing key than the author, it will create an inconvenience for users now but will make all subsequent updates problem-free. If you don't, you automatically sacrifice security&stability and risk having to make that decision anyway at some later point, breaking all the installs users made by then. Of course, serving both authors-signed and repo-signed versions of apps in parallel and suggesting the latter to users who install an app for the first time would also be a viable solution
pgpl9UR1ZyarB.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list Replicant@osuosl.org https://lists.osuosl.org/mailman/listinfo/replicant