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.
pgpznIDGDVaY6.pgp
Description: OpenPGP digital signature