[Replicant] Website updates for Replicant 6.0 release

[Denis 'GNUtoo' Carikli]

On Mon, 20 Mar 2017 13:57:06 +0100
Wolfgang Wiedmeyer <wreg at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20170323/7d4923c3/attachment.asc>