On Mon, 20 Mar 2017 13:57:06 +0100 Wolfgang Wiedmeyer <w...@wiedmeyer.de> wrote:
> [...] > 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. The FSDG guidelines mention Good faith efforts, I guess that it would count as it. > 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? A simple script should be able to make it automatic, at the expense of having less application at the begining. We can separate the fix: - One part can be done in a script to produce an FSDG compatible repository, just by removing all software with anti-features. - Another part can be done by having Replicant users like me look at applications and report the non-compliant applications to either f-droid or Replicant, or to send a patch for the f-droid metadata repository. - The last part would be to have f-droid autodetect that it runs on Replicant (this is probably already the case) and instead of greying out applications with anti-feature it would select the repository that doesn't have any applications with anti-features. The user wanting them would then have to manually switch repository and enter addresses by hand. > 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. A simple script that only filters out applications with anti-features and produce a different repository is probably enough. It will have many false positive but the false negative could be handled by fixint the f-droid data repository. This way we need no blacklist and we don't need to maintain anything at first. F-droid would also have almost no maintenance burden. This is, supposing that the source is compliant that way. We probably would need to check that as well. > 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. Yes, as stated before, there are many false positive however, it can later be addressed this way: - Each specific anti-features are better understood, defined, and reviewed against the FSDG guidelines. - Applications (fdroid-data) are reviewe against each anti-feature definition. - Some anti-features could then be enabled back, based on the fact that they respect the FSDG guidelines or not. > Having our own blacklist would mean a lot > more flexibility when it comes to deciding which apps should be > hidden. I get the point, however can we find people willing to maintain it? Denis.
pgpBAQwNv4inV.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list Replicant@lists.osuosl.org http://lists.osuosl.org/mailman/listinfo/replicant