On Sat, 5 Aug 2023 08:44:12 -0400
bill-auger <bill-auger@peers.community> wrote:

> granted that this would be the final determination, in each case, the
> client would require patching, with one of two options:
> 
> A) patch the client to filter results per the metadata, and further,
> to filter additional packages based on the blacklist
> 
> B) patch the client to replace the upstream repo as a client source,
> with new libre-only repos, hosted for all distros to share

There are also more options (like to generate filtered out repositories
for Guix for instance).

For (B) distributions don't necessarily need to do any patching as
upstream could even release a modified versions of some of the packages.

So for instance with python, pip could be modified and replaced by some
pip-libre package by the upstream repository to have the URL of the
FSDG compliant upstream repository already configured in by default.

This gives many more advantages:
- It would enable other non-FSDG distributions to use these
  repositories as well and even package the liberated version of the
  packages managers.
- It would integrate well with existing distributions practices
  (packaging upstream software).
- It could even be packaged in the original repository. So for instance
  pip-libre could be installed with pip.

With (B) beside the initial work that is bigger than just making a
simple patch, it's probably difficult to predict if people will
contribute to it or not:
- (B) could attract contributions from new people (for instance people
  not being on FSDG distributions but still not wanting nonfree
  dependencies for a reason or another) and manage to lower the
  maintenance a lot.
- (B) could also attract contributions from FSDG distributions,
  especially if they are pushed to use these repositories. But if
  everybody waits somebody else to magically fix things, it will
  probably not work if there is nobody to maintain (B) or to do any
  work on (B).

Note that with (A) in some cases it doesn't really work well either. For
instance in Parabola, a lot of the patches to liberate packages are not
really maintained so we end up with old software that break at some
point, or in the best cases that lag behind (so we can have security
issues in some cases). 

In the case of (B), for distributions updating packages is really faster
and it might even be done by upstream distributions like Arch for
Parabola (if arch also packages pip-libre), or by automatic tools used
by maintainers if people write these tools.

Denis.

Attachment: pgpMSm99P1pmi.pgp
Description: OpenPGP digital signature

Reply via email to