Re: [GNU-linux-libre] review of uruk

[Denis 'GNUtoo' Carikli]

On Tue, 28 Mar 2023 21:49:18 -0400
bill-auger <bill-auger@peers.community> wrote:

> On Wed, 29 Mar 2023 02:31:57 +0200 Denis wrote:
> > That said, there may or may not be requirements that are not in
> > the FSDG (for instance if the FSDG is not complete, or because no
> > one though of new problematic cases or issues, or just because some
> > class of problems usually never happens for one reason or another).
> 
> its probably all of those things - i prefer to be as rigorous
> as possible though - at least to sort things out, make some
> determinations, and most importantly, to docujments them and
> apply them, rather then leaving unnecessarily vague things remain
> vague and contentious - arguments about the vagueness of the
> FSDG, account for the majority of time spent on this mailing
> list - it is very inefficient
I also agree with that.

Here I insisted on having the right justification for that because even
if the result is the same in this case, the justification has
real impacts: for instance if infrastructure self-hosting was inside the
FSDG, then it would also have implications for existing distributions.

If we instead ask for things with the rationale to simplify the review,
it has no impact on existing distributions that were already reviewed.

And generally speaking that keeps things simple and we don't have to
think about the consequences of interpreting the FSDG differently.

> On Wed, 29 Mar 2023 02:31:57 +0200 Denis wrote:
> > And I think that not self-hosting your own infrastructure is not
> > necessarily a binary situation: for instance Guix doesn't control
> > all its infrastructure (because GNU, not Guix controls part of it)
> > 
> > A requirement like that would also forbid using savannah for hosting
> > your source code, forbid secondary mirrors managed by the project,
> > etc.
> 
> to sort that out: there is a huge difference between GNU
> managing the infra for GNU projects, vs relying on a completely
> unrelated third-party, which has no obligation to provide those
> services to the project - GNU is obligated to GNU projects -
> pureos is not obligated to uruk in the same way (not in any way,
> in fact) - pureos has every right to obstruct uruk users from
> accessing their servers
Good point. The CHATONS and even states also reason like that where they
try to understand compatibility with their charter or their laws,
with other entities terms of services, state laws, with the business
model of the entity, etc.

In this case non-gnu Savannah is probably OK too even if it's not GNU
(depending on the usage of Savannah, more on that later).

> likewise, hosting your source code on a third-party forge is
> still very different - i would recommend against that; but still,
> the project has sufficient autonomy using forges - they can
> decide what goes in or out of it, fix bugs, and so on - i would
> consider that as sufficiently providing and maintaining that
> source code - but in this case, the majority of the software in
> uruk, is literally "not provided" nor maintained by that distro
> - the distro maintainers have zero control over the majority of
> the software that their users use
I think that here a "SASS" criteria fits way better because it really
depends on how you use a forge.

If you use the forge as git hosting (that could also include mirroring
your git repository across different forges for backup purposes only),
then the project might not need to be able to modify the way it works
(as long as it doesn't bring in other issues like surveillance, nonfree
JavaScript, etc).

If somehow the project depends on computing done in the forge, then
SASS applies and it's a good idea to have the project be be in control
of the forge somehow.

There are also ways to deal with untrustworthy forges in some ways,
like to sign the commits with gpg signatures for instance, but that
seems to be out of the scope of the FSDG as the FSDG also accepts
distributions with known security issues that aren't fixed (like
Dynebolic or Replicant 6.0).

Anyway I've started to document the status of security in various
FSDG distros to inform users and encourage security, but I also need
help:
https://libreplanet.org/wiki/Group:Software/FSDG_distributions/Security

> i think that discrepancy is very significant - the distro should
> have complete autonomy over all distributed software - all that
> uruk would need to do, is to mirror the pureos repos, to gain
> complete autonomy to filter it, or replace packages with
> bug-fixed versions, etc
>
> that may be a adequate clarification, what i would add to the
> "complete distros" section:
> 
> > Distro maintainers must have complete autonomy over all software
> > that they distribute.
> 
> i really dont think that is expecting too much - i would tend to
> see it as essential, if i were choosing a distro
If the question here is to make the review faster, I don't see any
issue so far.

If instead the question here here is what is FSDG compliant, there
is the issue of defining that precisely. 

If a distro runs a VM, does it need to control the underlying hardware?
What if the computer runs a nonfree boot software like an UEFI? What if
it runs a fully free boot software but the machine it runs on doesn't
have free software microcode updates and that the community doesn't
work to fix bug fixed by microcode updates in some other ways?

The CHATONS charter that I mentioned in my previous mail has language
that can be used to define that, but it probably requires more work to
define that precisely.

So right now, to make the review faster, we could also look at how it's
done for other distros and have uruk do roughly the same thing and
try to spot the biggest issues (like nonfree JavaScript).

Here's so far what I know about other FSDG compliant distros:
* Guix: Git and mailing lists uses the GNU infrastructure.
* Parabola: Self hosted in a VM that probably runs in a common VM
  provider, probably on hardware that isn't running only free software.
* Proteanos: the website and git looks self-hosted.
* Replicant: Part of it (git repositories, contact address, IRC
  bridge, DNS) runs in a VM that runs inside the FSF infrastructure that
  is administered by Replicant and backuped by the FSF. The OSUOSL runs
  the mailing list, the Redmine instance and the only FTP / mirror. The
  dependence on OSUOSL for redmine hosting, the mailing list need to be
  fixed, and additional mirrors need to be found. 
* Trisquel: they run their own gitlab instance, and also seems to run
  their own mailing lists. I've no idea where that runs.

Some of the distribution infrastructure is also administered by the FSF.

So if we remove what is a bug from that, most of the other
distributions either self-host or ask help from the FSF to help them
manage their infrastructure. And a common VM provider may be OK.

I probably need to create an article on the Libreplanet wiki about
all that to document that as well, because as you point, it's an
important criteria of choice between distros.

> despite my preference on this topic, i would like to concede
> this for now - i have offered a proposal to accommodate this
> situation, as something of a concession - maybe that would
> satisfy everyone
A possible way to deal with it would be to ask uruk to make a choice
between:
- Doing roughly what other distributions do and have their
  infrastructure described as well as part of the review. The FSF would
  then decide if that's OK.
- Having the perfect infrastructure to maximize the probability of
  being accepted, and also have that described. The FSF would then
  probably have no issues with that.
- Not improving their infrastructure, and having their infrastructure
  described. The FSF then may have to discuss about that and there is
  also the risk that either the discussions would take too much time or
  that they would decide that it requires too much time for to little
  gain and postpone the review of the distribution, probably until some
  document detailing a policy are done, or even indefinitely.

> On Wed, 29 Mar 2023 02:31:57 +0200 Denis wrote:
> > Though for now it's probably easier to just focus on the review of
> > uruk right now and for things that are not inside the FSDG, to
> > request changes like that on the basis of making the review faster.
> 
> its really all we can do now - my concern now is only of the
> future - it appears to me, that this review of uruk is going to
> get snagged against the past unresolved problems with the FSDG
> itself - it has already gotten snagged on the mis-management
> problem; but there are others lurking ahead on the path - the
> kernel in that repo is another major unresolved conflict for
> this work-group
Since the FSF has the final say about Uruk, then it's pretty easy for
us: we could just advise Uruk about what we think is the best (and we
could also do mistake as we are humans) and we'd just describe the
situation in the final report for the FSF.

And if it takes us too much time to review for us, we could also ask
uruk not to do things that takes us too much time, else we would
likely never finish the report.

Denis.

pgpUMLN_ZLDzv.pgp
Description: OpenPGP digital signature