Re: [GNU-linux-libre] Developing free non-gnu operating systems

[Denis 'GNUtoo' Carikli]

On Wed, 6 Oct 2021 07:52:49 +0300
Jean Louis <bugs@gnu.support> wrote:

> This above is not case with Guix and it would be extremely difficult
> to convey Guix software on a physical object as it is dynamic
> distribution. Not relevant for the remark.
It's actually relatively easy to do that (see below) but Guix itself
probably doesn't ship physical objects with binaries on it.

> >     d) Convey the object code by offering access from a designated
> >     place (gratis or for a charge), and offer equivalent access to
> > the Corresponding Source in the same way through the same place at
> > no further charge.  You need not require recipients to copy the
> >     Corresponding Source along with the object code.  If the place
> > to copy the object code is a network server, the Corresponding
> > Source may be on a different server (operated by you or a third
> > party) that supports equivalent copying facilities, provided you
> > maintain clear directions next to the object code saying where to
> > find the Corresponding Source.  Regardless of what server hosts the
> >     Corresponding Source, you remain obligated to ensure that it is
> >     available for as long as needed to satisfy these requirements.
> 
> Above (d) is relevant for my remark. Problem is in the method of
> distribution and additionally access to binaries and sources beyond
> the method of distribution.
> 
> 1. User gets binary from Guix; normally by using Guix method, Guix
>    package manager; the method and GPLv3 are not quite aligned;
> 
> 2. Mostly, there are no clear directions where to get the
>    corresponding source on Guix or third party server; 
> 
>    But binaries are in general served over Internet, while Guix
>    management let users to get binaries through Guix package manager,
>    it is possible to get binaries from a network server. They are
>    available and in that case this remark is not at all satisfied.
With 'guix pack', as part of Replicant, we released binaries
made from pure Guix:
https://ftp.osuosl.org/pub/replicant/build-tools/repo/28-01-2021/

And we also published corresponding source code along the way and all
the commands used to make both the binary release and the source code
release.

So it's possible to get the source code in an automated way with the
exact same tools.

The question would be how different it is from Debian based
distributions where you can get the source code with apt source:
- The way to get full source code is less well known with Guix. I had
  to try and to ask around, but now at least I know how to do it and I
  can publicize it. I didn't check if that was also in the manual.
- I didn't check if both the source and the binaries came from "the
  same place" (which the GPLv2 requires if I remember well).

> 3. Guix does not maintain responsibility to remain obligated to ensure
>    that packages are available for as long as needed. They should host
>    source code in my opinion, but I think they don't.
>
> 4. Additionally, for every version of the package same is valid
>    above. Versions change constantly. One cannot provide source for
>    newest version while "forget" to provide source for some older
>    version. 
As I understand once a package is in Guix, its source will also be
hosted in Software Heritage on behalf of Guix. 

And you even have 'guix time-machine' that enables you to run guix
commands for a specific (older) commit of Guix.

So both combined gives some pretty good assurance that in the future
you will still be able to build old software because it will also have
all the source code of the dependencies and if it built at a given
git revision, it's likely to also build in the future at the same git
revision.

The issue here is probably that Guix does a lot of things, so it's not
always obvious how to do things with it. 

For instance there are several sections of the manual that I didn't
read yet.

Denis.

pgpHNIN_PMSEK.pgp
Description: OpenPGP digital signature