[Dev] Criteria beyond FSDG compliance for Parabola and third party repositories?

Denis 'GNUtoo' Carikli GNUtoo at cyberdimension.org
Thu Dec 22 04:34:26 GMT 2022


Hi,

There has already been extensive discussion on third party repositories
used by Parabola in the bug #1035[1], but I think it would be a good
idea to separate the discussion about a policy and the actual work
being done (for instance to remove pip, rubygems, etc).

The FSDG[2] has the following:
> Nor should the distribution refer to third-party repositories that
> are not committed to only including free software; even if they only
> have free software today, that may not be true tomorrow. Programs in
> the system should not suggest installing nonfree plugins,
> documentation, and so on.

So there is work in progress (that is tracked in the bug #1035 and in
other bugs) to either fix or remove software that use repositories that
have no commitments to include only free software.

The question is if Parabola should add policies that go further than
that or not.

As I understand Parabola already has these additional policies:
- The FSDG allows non-functional data (like game data for instance)
  under nonfree licenses if the license enable to copy and redistribute
  for commercial and non-commercial purposes. Parabola instead requires
  free licenses for non-functional data as well. I've no idea what the
  policy of other FSDG compliant distribution is with that.
- The packages needs to be built from source. Arch Linux often include
  binary files for Java programs in its packages for instance. Parabola
  has to remove or replace them with versions built from source.
- ARM computers officially supported by Parabola need to have some
  documentation in the Parabola wiki and to be able to boot with free
  software that is provided by Parabola (so if an ARM computer
  has a nonfree bootloader, it won't be supported officially).

I am also unsure if Parabola also has a rule that requires to have very
precise licensing information or not[7]? For instance if a software has
a given license (like the "expat license") but brings a lot of
dependencies under other licenses, do we need to list all the licenses
in a way that is maintainable (for instance list what is covered by
what license, like bsd-2-clause for this project, bsd 3-clauses for
this file, this modified X11 license for that file, etc).

For examples of distributions where it's not the case, both Replicant[4]
and Guix[5] allow less precise licensing information.

Other FSDG compliant distributions also have their set of policies
which differ. For instance unlike Parabola, Trisquel and PureOS probably
have rules requiring to recompile package from the upstream
distribution. 

Guix probably forbids cyclic dependencies (all the compilers are
bootstrapped, sometimes from binaries though), where in Parabola gcc
depends on gcc. 

Replicant requires the supported devices to have a removable battery
and to have an isolated modem to prevent the modem from being able to
take full control of the device.

If for instance we decide in Parabola that all the third-party
repositories should follow the same rules than Parabola, then we will
probably end up having to remove all the software that is configured to
use third party repositories, or at least disable the repositories.

The good side is that all software installed through Parabola will
adhere to the same set of criteria, so if we make the criteria clear,
users will have more consistency.

Though we might have to remove packages like "guix" (it needs to be
updated though), "guix-installer" (it's trivial to update),
"debootstrap" (it can install Trisquel, PureOS, and older distributions
like Gnewsense), and maybe software like "gnome-box" too if it can still
download FSDG compliant distributions (it's currently broken on x86_64
so I could not check).

We also have packages that makes it possible to install Hyperbola
GNU/Linux (hyperbola-archlinux-keyring hyperbola-keyring
hyperbola-mirrorlist hyperbola-pacstrap-config).

For browser addons, Parabola builds them so users won't be affected.

Another option would be to stick to the FSDG for third party
repositories and somehow inform users that different FSDG compliant
distributions have different policies (for instance by documenting that
on the Libreplanet wiki, and mentioning it in the Parabola wiki[6]).

Parabola has a document that explains what users should expect of
it[6], so in any case we can explain users what Parabola protects
against and what it doesn't protect against. For instance, in a lot of
cases Parabola will run nonfree software without asking users about it,
but it will not ship nonfree software.

Personally I would prefer if we keep FSDG compliant repositories as I
joined Parabola to work on packages like debootstrap, and a big part of
my work was in this area. The result is that Parabola x86_64 is
probably the FSDG compliant distribution that can install the biggest
number of other FSDG compliant distributions[3] (through
programs like debootstrap, pacstrap, Guix commands, etc).

In all these cases, the signatures are checked, so users don't take
unnecessary security risks when installing another distribution or
package manager with these tools.

Though at the end of the day I also need some clarity on the actual and
future policies of Parabola to know in which areas It's a good idea to
spend my time on, and in which cases a Parabola package needs to be
removed and/or replaced.

So whatever decision is taken, I think that the outcome will be
beneficial anyway. And at the end of the day I can still do that work
in other distributions like Guix (though it would require more work to
bring in pacstrap and so on) if Parabola doesn't want that kind of work.

References:
-----------
[1]https://labs.parabola.nu/issues/1035
[2]https://www.gnu.org/distros/free-system-distribution-guidelines.html
[3]https://libreplanet.org/wiki/Group:Software/research/CrossDistroBootstrap
[4]The Android build system doesn't use package definition, so the
   license of each component is in its git source code, so it's a mess.
   There has been various attempt to fix it though, but it's not as
   urgent as other things like fixing an FSDG compliance bug on
   Replicant 6.0 or making the new Replicant version usable.
[5]Matterbridge was added to Guix knowing that it bundled about 500
   dependencies that weren't in Guix. I've checked most of them on an
   older version of matterbridge but not all of them and so far I
   didn't find any nonfree software, so it's probably OK.
[6]https://wiki.parabola.nu/How_does_Parabola_protects_users_against_nonfree_software
[7]I've looked at Chromium in the blacklist repository, and apparently
   it's blacklisted because it "links to proprietary plugins" and has
   "unattended phone-home queries" and is "not entirely built from
   sources". So since something like "not precise enough license" isn't
   mentioned, I'm unsure about the status of a policy like that.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20221222/42086bc8/attachment.sig>


More information about the Dev mailing list