Re: Unapprove F-Droid like Replicant?

[Denis 'GNUtoo' Carikli]

Note that I cannot speak for the Free software directory project, so
below is based only what I understand of it.

On Sat, 16 Sep 2023 21:38:25 -0400
bill-auger <bill-auger@peers.community> wrote:
> On Sat, 16 Sep 2023 23:19:48 +0200 Denis wrote:
> > 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  
> 
> that is another good point - i dont suppose that anyone tries to
> build the software before adding it to the FSD - it does seem like a
> good idea; but the only way to know if it builds with free software
> may be to try building everything before adding it to the FSD - that
> would require more skill than the FSF expects editors to have - the
> FSF wants the FSD to be an activity that non-techies can handle -
> IMHO, it would also require a policy change; because i doubt that
> compiling is part of the standard procedure now, or that there is a
> criteria about a fully free build or operating environment now
That is a very good point.

In many cases building the software can be avoided because it's
already packaged and built somewhere. In other cases looking at the
dependencies gives enough guarantees.

But in the case of Android software and/or software that pulls
dependencies from programming languages packages manager to be built, I
think that requiring the full and real dependencies could be a way to
deal with that.

Here this would have raised an issue here since the SDK is part of the
dependencies. 

It raises the same concern about software that only runs on other
operating systems than GNU/Linux or GNU/Hurd, so it maps well with
exiting more or less defined policies or future policies being reflected
on.

Note that sometimes software is packaged in distros by still using
programming language package managers to build the software.

An example is matterbridge that I added in Guix that has about 500
dependencies bundled inside its source code. I audited the license
of most of them though. Here an easy fix could be to treat the
dependencies as part of matterbridge and review their licenses along
with matterbridge.

> > Do you know if we need some decision to implement that or can we
> > start right away?  
> 
> over-all, that was my main point - treating these on a one-by-one
> basis is very inefficient and subjective - there should be some
> general guidelines, something of a checklist like we made for the
> FSDG - then no one would need to ask "is it OK for this specific
> program to have this specific behavior?" - there should be a standard
> answer for common concerns - either none may have that specific
> behavior or all may
> 
> in other words, i would drop the very specific "f-droid" from this
> conversation entirely; and decide which common general behaviors are
> acceptable, as a matter of policy
I agree with the goal but having "F-Droid" in mind also helps deciding
theses rules.

For instance we can test how a rule would apply to F-Droid, to a
software that runs only on a nonfree OS, to another software that has
lots of dependencies, etc.

And Here we do not even need to do that now as unlike
phoronix-test-suite, the F-Droid client doesn't run on GNU/Linux, so we
can continue to see the impact of potential rules on different
situations to see if they would fit well or not.

> for example:
> 1) may _any_ program suggest/recommend/utilize un-trusted third-party
> repos?
That can easily be handled with requiring to list/add the dependencies
of the program (and of the dependencies).

Some exceptions could be made for that for instance when the program is
packaged in some 100% free distro or repository.

> 2) may _any_ program require a non-free build environment to
> compile?
As I understand that counts as a nonfree dependency, so it seems to be
disallowed.

At least FSDG compliant distributions consider software like that as
nonfree (example: Freedos). And a good solution to manage to build that
software with free compilers and maintain that.

> 3) may _any_ program run only on a non-free OS?
If I understood well, a decision is planned for including programs that
run only on other OS than GNU/Linux and GNU/Hurd, so for now including
such programs seems to be discouraged until some official decision is
taken. The priority also seems to be software somewhat related to
GNU/Linux and GNU/Hurd (like software that runs on these OS).

In another hand we already have firmwares inside the directory, and
sometimes firmwares have custom OS or depend on free software OS, and
in these cases the line between an OS and a library is very blurred.

The Rockbox case is also interesting because at best it only works
under GNU/Linux under certain conditions and at worst the GNU/Linux
port could be unusable and highly incomplete.

Personally I'm mostly interested in adding firmwares not packaged in
FSDG distros and that I use as I need to know if what I use is
free or not, and adding them is a bit more work, but this makes that
work a lot more useful.

> i added "3" because presumably mobile must be written such that they
> are impossible to port to any other OS, in the way that windows
> applications normally could be - if "3" is "no", then that would
> preclude any iphone apps; and android apps would be acceptable only
> if they can run on replicant
As I understand Windows applications are not necessarily an issue if
they can run under GNU/Linux without any nonfree dependencies (with
wine, mingw, etc).

The same seems to apply for similar cases (free games that runs inside
free emulators, etc).

> again i dont know that the FSD includes any android or iphone apps;
> but that requirement would entail editors to try running all android
> apps on replicant
The question about Replicant is complicated as it cannot run in
emulators and depends on hardware with nonfree bootloaders.

The situation with the iphone also raises questions. Is the VLC that
runs on the iphone the same than the VLC that runs on GNU/Linux? The
VLC on iphone has a separate repository.

Maybe it's that complexity that makes it complicated to take a decision.

> in other words, i think the FSD criteria are intentionally more
> relaxed than they could be, as not to require any technical skills of
> the editors, but only licensing knowledge
I think it's also due to the fact that taking decisions on some of the
cases can be very complicated and time consuming. 

The best way to do that is probably to list corner cases in order to
better understand their impact, and to see how well proposed rules
could fit.

If we go too fast, we risk taking decisions that need to be changed
later on or too often, and that could end up in bad situations like
having to re-do a lot of the reviews, to remove lots of software, ban
perfectly legitimate entries, etc.

And in the meantime that can probably lead to tolerating or not
adding software that fits in these corner cases, at least for
now. And that is probably less perfect than if we had more specific
rules, but these rules also requires us to know about these corner
cases.

Though something that seems lacking is a way to collaborate to list
these cases or potential rules, and see how the rules would apply on the
cases. Maybe adding that in a bit more structured and summarized way to
the Free Software Directory wiki pages could help.

Denis.

pgp5885PxTBl0.pgp
Description: OpenPGP digital signature