directory-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU-linux-libre] Criteria for Android applications


From: Denis 'GNUtoo' Carikli
Subject: Re: [GNU-linux-libre] Criteria for Android applications
Date: Mon, 4 Oct 2021 00:32:40 +0200

On Sat, 2 Oct 2021 12:26:32 -0400
bill-auger <bill-auger@peers.community> wrote:

> the FSD is not an "app store", where to download and install
> binaries - the FSD should only list software for which source
> code is available, and always present the source code - it
> should not have any concern for binaries, who compiled them,
> nor from which repos they can be retrieved, nor if any such repos
> exist
I start to understand the point here: If we take a given software under
a lax free software license, or a weak copyleft license, and/or that is
also available in the App Store (which has restrictions incompatible
with free software), the fact that there are nonfree version or
binaries that somehow contain nonfree software doesn't make the
source code nonfree, especially if there are multiple ways to compile
the software.

However it could still steer users toward nonfree software if that very
same project also publish nonfree binaries. And I do understand that
not every project can or want to solve all the freedom issues out there
in that same project.

In that case we could just make it clear that the Free Software
Directory doesn't review binaries and point to gnu.org/distros for a
solution (as FSDG distributions do care about the license of the binary
being distributed).

In Replicant, we handle the fact that we aren't able to solve all the
freedom issues that affect smartphones and tablets users by having
technical documentation that explains the limits of Replicant[1].

We hope that users and contributors will read it and become aware of
the limitations. And even if not everybody reads it, it still helps a
lot the contributors as we tend to forget less about the problems that
Replicant didn't solve. As a bonus, it also helps new contributors
understanding the hardware and software architecture along the way.

Though a shorter and less technical version is probably needed to make
sure more users and contributors are aware of the situation.

I've started to work on something like that for Parabola[2], though I
need to finish it and we probably also need some consensus and/or
contributions to it as I'm only 1 person with my own bias and views on
things.

The issue is that even if we warn users, the general concern about being
able to build and run that software with free software[3] is probably
still relevant somehow.

If for instance the software requires a nonfree compiler then we could
consider that compiler as a nonfree dependency. If some software only
runs on a nonfree OS, then we'd also have nonfree dependencies somehow.

And here I can also understand the decision of the free software
directory project not to try to deviate too much from what they are
already doing since it could raise many complicated questions along the
way.

But if one day some Android only applications are added, or if there
are already some, I think this is very relevant.

I'm new to the Free Software Directory, so I don't have opinions on how
it should work, but if it starts handling Android only applications,
users will probably make assumption about the freedom of such
applications, so that indirectly impacts Replicant users and
contributors.

And here what I'm interested in is making sure that if there is such a
list being made there, that the process of reviewing the applications
doesn't have systemic flaws.

Years ago we had the Java trap[4] for instance. And if today we have
dependencies that we think are free software but aren't (because there
is no source code or that the source code is missing some parts), it's
not very different. 

And as I understand it, Maven Central doesn't give us any assurance
that the binaries that we get from it have any corresponding source
code somewhere.

So if we have a dependency named foo, it might be way easier to look
for the website of foo and find its source code there and to try to
build foo somehow rather than trying to get foo from Maven Central and
then trying to understand from which source code these binaries were
built.

So if foo has no other dependencies, we could simply review foo source
code and add it. But then if we add an application that depends on foo,
I think that's somehow relevant, because we have no assurance at all to
get the (potentially modified) source code of foo.

If people add the application directly and don't add foo in the Free
Software Directory, it could be even worse, as source code could be
completely missing.

So while I do understand that the FSDG distributions or the Free
Software Directory are made by humans and that humans make mistakes
from time to time, I think we also need to think critically to avoid
and/or detect potential large scale issues.

If for instance we find out that almost none of the free software
Android applications are really free software, because of some systemic
issue with Maven Central, and that lot of Android applications were
added in the Free Software Directory, and that people relied on that
list to know if they were really free, that would be an issue.

And here this is especially important because of the reputation of the
Free Software Directory. For instance if a distribution known to ship
nonfree software claims that it's fully free, not everybody will believe
it, especially because it's not in the list of free GNU distributions.

But projects like the FSDG compliant distributions already have a
reputation of being stricter than other distributions, and I would also
expect that of the Free Software Directory unless there is some
official documentation that tells me otherwise.

And unfortunately the issue I described probably also applies to Java
software using Maven Central in general. 

And as I understand it it might also be an issue in some programming
language package managers[5][6], but as I understand in the most well
known ones it probably affects a minority of packages, whereas with
Maven Central it looks like a massive issue.

References:
-----------
[1]https://www.replicant.us/freedom-privacy-security-issues.php
[2]https://wiki.parabola.nu/Talk:Main_Page#How_does_Parabola_protects_users_against_nonfree_software
[3]I was trying to express something like that before but I didn't find
   the right words. We probably don't want to require people to run
   Libreboot on computers whose every firmware is free to test software
   for instance. And at the same time we probably need to make sure that
   there are no nonfree dependencies somehow that would prevent
   packaging such software in FSDG compliant distributions. And using
   distributions without any nonfree software for building software
   makes sure that nonfree dependencies aren't automatically used when
   found. Though that could also be checked by hand by reading the
   source code.
[4]https://www.gnu.org/philosophy/java-trap.html
[5]https://hpc.guix.info/blog/2021/09/whats-in-a-package/
[6]https://labs.parabola.nu/issues/1035

Denis.

Attachment: pgpVwf94Np5YO.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]