[Replicant] Website updates for Replicant 6.0 release
Denis 'GNUtoo' Carikli
GNUtoo at no-log.org
Thu Mar 23 14:21:27 UTC 2017
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>
More information about the Replicant
mailing list