Re: Unapprove F-Droid like Replicant?

[Denis 'GNUtoo' Carikli]

On Sat, 16 Sep 2023 01:13:05 -0400
bill-auger <bill-auger@peers.community> wrote:

> some observations:
> 
> * if the software in the f-droid repo was never all libre, but the
> server and client were once accepted into the FSD, that suggests to
> me that the software in the third-party repos is not relevant to the
> FSD, only the server and client are - ie: if non-free software in
> some repos is a justification for removing a client which can
> potentially access it, then it should not have been added in the
> first place - but it was; and i do not believe any new information
> has come to light since that time - so fundamentally, this is not
> really asking about one specific entry; but it is really asking "what
> is our policy about third-party package managers?" - i dont believe
> that the FSD has any policy about that
If I recall well, phoronix-test-suite that was either not added or
removed from the directory because of issues with the test repository
(by default it uses a repository with tests, and some of them use
nonfree software (like demos of nonfree games)).

But there is also also another issue with the Android F-Droid client: we
don't know if it has nonfree dependencies or not.

To know that someone would need to build it without nonfree
dependencies like the nonfree Google Android SDK.

There are various ways to do that: Use PureOS, Use the Replicant 4.2
SDK, use Replicant 6.0 or 11 to build the F-Droid client, etc.

The same also applies to the applications provided by F-Droid.

Emacs is probably fine though as it is known to compile with SDKs older
than the one for Replicant 4.2, with documented modifications.

It might also be possible to have other FSDG compliant and recent SDK
quite easily by building them from the Android source code and by
accepting bug reports about freedom issues (if they are found).

Making sure it builds with free software in a somewhat clean way
(with 100% free software and good dependencies management
practices) would help a lot in having an FSDG compliant F-Droid version
(people refused to work because they didn't manage to build it in a
clean enough way).

> * the entry itself is rather confusing - it describes the server, the
> client, and the f-droid repos with equal emphasis - reading the
> description alone, one could not guess which one of those three that
> the entry is actually for - is is common for FSD entries to pertain
> to multiple applications? - i suppose that this entry is for the
> server software - so probably, it does not need to mention the client
> or the third-party repo
That is a really good point.

For instance Guix packages both the server and fdroidcl (It looks like
a program that can control the Android client remotely), which are not
the Android f-droid client (they are written in python and the Android
client is written in Java).

As I understand it is possible to use the server components to build
Android applications. 

To do that there are various ways too. For instance you can provide a
free software SDK or have your 100% free software Android application
use a Makefile and PureOS to be built, etc.

This fdroidserver can be used to package 100% free software Android
applications in F-Droid.

> i would also remove mention of the "The F-Droid Repository" entirely
> - if my assumptions are correct, then that entry is for the server,
> not the client or the third-party repo, so to mention the repo seems
> to be irrelevant - presumably, the server software has no relation to
> "The F-Droid Repository" - the FSD also describes the repo as
> "catalogue of free software applications", which i think we all agree
> was never true, even when that was written
I think it makes sense to do that too, more precisely to:
- Rename that entry to "F-Droid Server" and/or fdroidserver. It's the
  name of the server component and the Guix and pypy package[1].
- Adapt it to only be about that server software. Maybe mentioning
  that it can be used to package software for the F-Droid client can be
  relevant, in the same way Mingw-w64 entry tells that it's a
  "Development environment targetting 32- and 64-bit Windows".

Do you know if we need some decision to implement that or can we start
right away?

References:
-----------
[1]https://pypi.org/project/fdroidserver/

Denis.

pgppqyE1JBdzK.pgp
Description: OpenPGP digital signature