gnu-linux-libre
[Top][All Lists]
Advanced

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

Re: [GNU-linux-libre] Can we slow down?


From: Denis 'GNUtoo' Carikli
Subject: Re: [GNU-linux-libre] Can we slow down?
Date: Sun, 23 Jul 2023 16:27:42 +0200

On Tue, 18 Jul 2023 22:51:32 -0400
bill-auger <bill-auger@peers.community> wrote:

> On Tue, 18 Jul 2023 16:16:59 +0200 Denis wrote:
> > bad quality free software will tend to use it anyway.   
> 
> that is always an option - anyone can grab 'pip' or whatever from
> same repo maintainers where the hundreds of other bad software they
> want to use will be downloaded from - if 'pip' is not in the distro
> repos, it is only one more non-distro package to install, before
> installing the hundreds of others which is it's only purpose

Here I meant software that is known to be free but whose quality
prevents it from being easily packaged.

An example could be software with more than 500 dependencies that have
been audited for licensing but are not in any FSDG distributions,
software that bundle a lot of heavily modified libraries, software
that is badly written and that is unmaintainable, software with bad
build system practices, etc.

Users will want to use that kind of software if it's the only way they
can fullfil a use case they depend on with free software.

> RMS wants to allow TPPMs to slide for a few more years - that may
> allow some work to progress; but only existential crisis facing the
> FSDG and work-group - maybe that would be a fine option, if there was
> any hope that the FSDG will be enforceable someday
> 
> the only point of my last message is that it is not possible to
> convince distros that these TPPMs, in their current form, are against
> the guidelines, and therefore to remove them and/or help to liberate
> them - surely they would have reached that conclusion on their own by
> now - we must consider that question as essential; because today,
> distros are not obligated to follow the FSDG in any way
> 
> i would not want to obligate anyone to help do the work; but it would
> be nearly impossible even to suggest it, if there is no obligation to
> follow the FSDG in the first place, nor any consequences of ignoring
> pleas to follow it in the last place

The FSDG has the following:
> Commitment to Correct Mistakes
> ------------------------------
> Most distribution development teams don't have the resources to
> exhaustively check that their distribution meet all these
> criteria. Neither do we. So we expect distros to occasionally contain
> mistakes: nonfree software that slipped through, etc. We don't reject
> a distribution over mistakes. Our requirement is for the distribution
> developers to have a firm commitment to promptly correct any mistakes
> that are reported to them.

So it's possible to give time to people and distributions to fix
things, and if work is done to fix one of the third party package
managers, it also makes it really hard not to integrate that work
without really good arguments that don't go against the FSDG.

> and so finally, that i am reluctant to do any of that work, until i
> can see a complete clear path to the goal; because i have no interest
> in TPPMs otherwise
People that care about software using third party package managers or
about using software from these package managers can do the work
instead.

And people do work and the work progress. People from at least Guix,
Parabola, non-distributions projects (linux-libre, gnuzilla), GNU, etc
do work to free some third party package managers. So things are
progressing.

If we compare with the situation with firmwares, not enough people
work on nonfree firmwares, so we don't really have substantial
progress. If we had progress, at some point distributions like Debian
might want to join the list of FSDG compliant distributions. Instead
they are going in the opposite direction. So here enforcing the FSDG
about nonfree firmware makes more sense as the problem isn't going to
fix itself.

But we're not in this situation with the third party package managers,
so we also have other options as well.

Denis.

Attachment: pgpzYijwQnz_X.pgp
Description: OpenPGP digital signature


reply via email to

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