Guix and FSDG

Guix and FSDG

[Raghav Gururajan]

[-- Attachment #1: Type: text/plain, Size: 5129 bytes --]

Hello FSF and GNU!

I came across, a discussion, in #fsf IRC channel, regarding GNU Guix
project and it's non-compliance with FSDG. Here, in this email, I would
like to express my thoughts, about what the situation is and how it can
be rectified. Please consider reading this email to the end.

Guix, as a free software, doesn't pose any confusion. It is completely
licensed as free software and respects/provides all the four freedoms.
Guix, as a free system distribution, does pose some confusion, whether
or not it violates Free System Distribution Guidelines (FSDG). The
concerns regarding Guix and FSDG, floats around two aspects. (a)
Distribution of non-free information/code/program/software and/or (b)
Facilitation of non-free information/code/program/software.

(a) Distribution of non-free information/code/program/software:
Guix distributes two main things, that are, (i) Package Definitions
(Scheme Code) and (ii) Subsitiutes (Pre-Built Binary). If we take
Package Definitions, it does not include any definitions for non-free
software/programs and any definitions itself does not contain any non-
free code. If we take the Substitutes, it does not include any binary
for non-free software/programs. Therefore, Guix DOES NOT violate FSDG
in this aspect.

(b) Facilitation of non-free information/code/program/software:
As per FSDG, free system should neither steer users nor refer to third-
party repositories, to obtain information/code/program/software that
can contain non-free parts. Let's consider the same two main things
provided by Guix, that are, (i) Package Definitions (Scheme Code) and
(ii) Subsitiutes (Pre-Built Binary). If we take substitutes,they are
pre-built binaries, built on the guix build farm, where the source is
obtained, de-blobbed (if required) and compiled. Since guix provides
substitutes only for free software/programs, there is no facilitation
of non-free information/code/program/software here. If we take the
package definitions, that is were issue rises. When no substitutes are
available or when the program/software is chosen to be built, guix on
the user's system does this: downloads source directly from upstream
(along with non-free parts if it contains), then strips out non-free
parts (if any), then builds and installs binaries. So these package
definitions, contains information/lines-of-code, that steer users or
refer to third-party repositories, to obtain
information/code/program/software that can contain non-free parts.
Therefore, Guix DOES violate FSDG in this aspect.

But should the current FSDG be revised? Growth requires change.
The current FSDG was constructed based on conventional approaches to
free system distributions. That is, a conventional distrubution
distributes free source code (obtained from upstream and de-blobbed)
and/or pre-built binaries built from de-blobbed source code. So there
is no need for a free system to steer users or refer to third-party
repositories, to obtain information/code/program/software that can
contain non-free parts. But guix, instead of distributing free or de-
blobbed source code, it distributes package definitions and scripts,
which gives user the choice to either obtain pre-built binary from guix
or to build directly from source via de-blobbing, on the user's system.
Thus, due to this new approach, there is a need for guix system to
steer users or refer to third-party repositories, to obtain
information/code/program/software that can contain non-free parts.
However, this DOES NOT pose any threat to free software movement or to
freedom of users. In fact, the user is given more freedom of choice to
build programs directly from source and perform their computing (de-
blobbing and building) on their own system instead of soely relying on
distribution's build farm. This new approach by guix, provides users a
favourable platform and oppurtunity, to build a whole free system
completely from scratch, even when no/zero pre-built binaries are
available. This is not a threat to software freedom, this is excersing
software freedom in a higher level. Therefore, I request the FSDG to be
revised, to allow codes/programs in a free system to obtain source code
containing non-free parts, ONLY for the purpose of de-blobbing and/or
building; provided that respective codes/programs (1) are itself free
(2) gives output that are always a free
information/code/program/software and (3) should not contain options to
obtain non-free information/code/program/software as output (Eg. --
disable-cleaning or --skip-deblobbing).

I can see two ways to end the confusion between Guix and FSDG, once in
for all. Either the FSDG remains unchanged and Guix gets removed from
the FSD list (or) the FSDG gets revised and Guix remains on the FSD
list. I am inclined to the latter, however, I am open to hear how the
former could be a better option.

I request administration/management of FSF and GNU, to make a joint
conclusion, at the earliest convenience.

Thank you!

Regards,
RAGHAV GURURAJAN.
(Free Software User and Supporter)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Guix and FSDG

[ng0]

> Therefore, Guix DOES violate FSDG in this aspect.

If you search the mailinglist archives you can see that you
are not the first to try and roll up this argument. Ludovic,
Ricardo or any of the other Guix maintainers will probably
answer more in detail, but my short reply is that we've had
this discussion before.

Re: Guix and FSDG

[ng0]

Hi,

I'm sorry for my last reply. At least it makes sense to
get the definition right this time as this is a reoccuring
topic. So whatever comes out of this should hopefully be
enough to write about it.
What threw me off was yet another email which CC'd many lists
plus one individual person.

Re: Guix and FSDG

[Thompson, David]

Hi, just a quick note to begin: Please do not cross-post to multiple
mailing lists because it tends to cause confusion for everyone reading
those lists.  I have included only guix-devel in the CC list for this
reply.

On Wed, Nov 20, 2019 at 5:02 AM Raghav Gururajan
<raghavgururajan@disroot.org> wrote:
>
> (b) Facilitation of non-free information/code/program/software:
> As per FSDG, free system should neither steer users nor refer to third-
> party repositories, to obtain information/code/program/software that
> can contain non-free parts. Let's consider the same two main things
> provided by Guix, that are, (i) Package Definitions (Scheme Code) and
> (ii) Subsitiutes (Pre-Built Binary). If we take substitutes,they are
> pre-built binaries, built on the guix build farm, where the source is
> obtained, de-blobbed (if required) and compiled. Since guix provides
> substitutes only for free software/programs, there is no facilitation
> of non-free information/code/program/software here. If we take the
> package definitions, that is were issue rises. When no substitutes are
> available or when the program/software is chosen to be built, guix on
> the user's system does this: downloads source directly from upstream
> (along with non-free parts if it contains), then strips out non-free
> parts (if any), then builds and installs binaries. So these package
> definitions, contains information/lines-of-code, that steer users or
> refer to third-party repositories, to obtain
> information/code/program/software that can contain non-free parts.
> Therefore, Guix DOES violate FSDG in this aspect.

I believe this is incorrect and I will explain why.  This exact
circumstance was brought up in the early days of the Guix project when
FSDG compliance was a big topic of discussion because Ludovic and RMS
were making sure that Guix conformed to it.  It is true that Guix will
download source archives for packages that *may* contain files with a
nonfree license.  However, Guix has a special mechanism developed
specifically to deal with this issue.  In Guix, the <origin> data type
is used to store information about a package's source code.  In this
data structure there is a field called "snippet" which may contain a
custom procedure written by the person that wrote the package.  The
role of the snippet procedure is to *remove* any files in the source
archive that are not freely licensed.  The result is a new source
archive that contains only freely licensed files.  The most important
part of this process is that the original source archive is *never*
accessible to the Guix user via any Guix tools.  The original archive
is discarded and does not end up in the canonical location for Guix
data: /gnu/store.  Thus, running `guix build --source
problematic-package` will only ever return the cleaned archive, never
the original with nonfree files.  Therefore, Guix has taken sufficient
technical measures to avoid steering its user towards nonfree software
and thus Guix is compliant with the FSDG.

Hope this helps,

- Dave

Re: Guix and FSDG

[Raghav Gururajan]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

Hello David!

> I believe this is incorrect and I will explain why.  This exact
> circumstance was brought up in the early days of the Guix project
> when
> FSDG compliance was a big topic of discussion because Ludovic and RMS
> were making sure that Guix conformed to it.  It is true that Guix
> will
> download source archives for packages that *may* contain files with a
> nonfree license.  However, Guix has a special mechanism developed
> specifically to deal with this issue.  In Guix, the <origin> data
> type
> is used to store information about a package's source code.  In this
> data structure there is a field called "snippet" which may contain a
> custom procedure written by the person that wrote the package.  The
> role of the snippet procedure is to *remove* any files in the source
> archive that are not freely licensed.  The result is a new source
> archive that contains only freely licensed files.  The most important
> part of this process is that the original source archive is *never*
> accessible to the Guix user via any Guix tools.  The original archive
> is discarded and does not end up in the canonical location for Guix
> data: /gnu/store.  Thus, running `guix build --source
> problematic-package` will only ever return the cleaned archive, never
> the original with nonfree files.  Therefore, Guix has taken
> sufficient
> technical measures to avoid steering its user towards nonfree
> software
> and thus Guix is compliant with the FSDG.

I completely agree with you. The way you explained, does show that Guix
comply with FSDG. The thing is, the semantics used in current version
of FSDG does not explain things well. That's why I pointed out that
FSDG require revision, such that this new scenario is included in FSDG.
So that Guix or any future distros that gonna use same/similar
mechanism, does not pose confusion to readers of FSDG. That is all. :-)

Thank you!

Regards,
RG.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Guix and FSDG

[Thompson, David]

On Fri, Nov 22, 2019 at 2:20 PM Raghav Gururajan
<raghavgururajan@disroot.org> wrote:
>
> I completely agree with you. The way you explained, does show that Guix
> comply with FSDG. The thing is, the semantics used in current version
> of FSDG does not explain things well. That's why I pointed out that
> FSDG require revision, such that this new scenario is included in FSDG.
> So that Guix or any future distros that gonna use same/similar
> mechanism, does not pose confusion to readers of FSDG. That is all. :-)

Glad that we're in agreement. :)

- Dave

Re: Guix and FSDG

[Clément Lassieur]

Hi David,

"Thompson, David" <dthompson2@worcester.edu> writes:

> I believe this is incorrect and I will explain why.  This exact
> circumstance was brought up in the early days of the Guix project when
> FSDG compliance was a big topic of discussion because Ludovic and RMS
> were making sure that Guix conformed to it.  It is true that Guix will
> download source archives for packages that *may* contain files with a
> nonfree license.  However, Guix has a special mechanism developed
> specifically to deal with this issue.  In Guix, the <origin> data type
> is used to store information about a package's source code.  In this
> data structure there is a field called "snippet" which may contain a
> custom procedure written by the person that wrote the package.  The
> role of the snippet procedure is to *remove* any files in the source
> archive that are not freely licensed.  The result is a new source
> archive that contains only freely licensed files.  The most important
> part of this process is that the original source archive is *never*
> accessible to the Guix user via any Guix tools.  The original archive
> is discarded and does not end up in the canonical location for Guix
> data: /gnu/store.  Thus, running `guix build --source
> problematic-package` will only ever return the cleaned archive, never
> the original with nonfree files.  Therefore, Guix has taken sufficient
> technical measures to avoid steering its user towards nonfree software
> and thus Guix is compliant with the FSDG.

Unfortunately I think this isn't true.  For example this is what 'guix
build -S zpaq' outputs:

--8<---------------cut here---------------start------------->8---
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/k9g90yqfcz8c0lnz1mcfd9k53llyw8wh-zpaq715.tar.xz.drv
2,7 MB will be downloaded:
   /gnu/store/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip
substituting /gnu/store/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip...
downloading from https://ci.guix.gnu.org/nar/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip...
 zpaq715.zip  2.6MiB                  2.4MiB/s 00:01 [##################] 100.0%

building /gnu/store/k9g90yqfcz8c0lnz1mcfd9k53llyw8wh-zpaq715.tar.xz.drv...
/gnu/store/cnqpra8vr2l5fz00rr4yj4bp3hr00cfw-tar-1.32/bin/tar: Option --mtime: Treating date '@0' as 1970-01-01 00:00:00
zpaq715.zip/
zpaq715.zip/COPYING
zpaq715.zip/Makefile
zpaq715.zip/libzpaq.cpp
zpaq715.zip/libzpaq.h
zpaq715.zip/readme.txt
zpaq715.zip/zpaq.cpp
zpaq715.zip/zpaq.pod
source is under 'zpaq715.zip'
`/gnu/store/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip/libzpaq.h' -> `zpaq715.zip/libzpaq.h'
`/gnu/store/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip/zpaq.pod' -> `zpaq715.zip/zpaq.pod'
`/gnu/store/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip/Makefile' -> `zpaq715.zip/Makefile'
`/gnu/store/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip/zpaq.exe' -> `zpaq715.zip/zpaq.exe'
`/gnu/store/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip/libzpaq.cpp' -> `zpaq715.zip/libzpaq.cpp'
`/gnu/store/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip/COPYING' -> `zpaq715.zip/COPYING'
`/gnu/store/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip/zpaq.cpp' -> `zpaq715.zip/zpaq.cpp'
`/gnu/store/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip/zpaq64.exe' -> `zpaq715.zip/zpaq64.exe'
`/gnu/store/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip/readme.txt' -> `zpaq715.zip/readme.txt'
successfully built /gnu/store/k9g90yqfcz8c0lnz1mcfd9k53llyw8wh-zpaq715.tar.xz.drv
/gnu/store/ran43jk8ngc60zzxgzhzdhkrpyb9i0ji-zpaq715.tar.xz
--8<---------------cut here---------------end--------------->8---

Both /gnu/store/32xxhz1sf3v9wxkhlvf4b9493dy588gi-zpaq715.zip and
/gnu/store/ran43jk8ngc60zzxgzhzdhkrpyb9i0ji-zpaq715.tar.xz are
accessible.

The former allows me to access zpaq64.exe and zpaq.exe although the
snippet is:

--8<---------------cut here---------------start------------->8---
(snippet
 ;; Delete irrelevant pre-compiled binaries.
 '(begin
    (for-each delete-file (find-files "." "\\.exe$"))
    #t))
--8<---------------cut here---------------end--------------->8---

Clément

Re: Guix and FSDG

[Giovanni Biscuolo]

Hello,

"Thompson, David" <dthompson2@worcester.edu> writes:

[...]

> This exact
> circumstance was brought up in the early days of the Guix project when
> FSDG compliance was a big topic of discussion because Ludovic and RMS
> were making sure that Guix conformed to it.  It is true that Guix will
> download source archives for packages that *may* contain files with a
> nonfree license.  However, Guix has a special mechanism developed
> specifically to deal with this issue.  In Guix, the <origin> data type
> is used to store information about a package's source code.  In this
> data structure there is a field called "snippet" which may contain a
> custom procedure written by the person that wrote the package.  The
> role of the snippet procedure is to *remove* any files in the source
> archive that are not freely licensed.  The result is a new source
> archive that contains only freely licensed files.  The most important
> part of this process is that the original source archive is *never*
> accessible to the Guix user via any Guix tools.  The original archive
> is discarded and does not end up in the canonical location for Guix
> data: /gnu/store.  Thus, running `guix build --source
> problematic-package` will only ever return the cleaned archive, never
> the original with nonfree files.  Therefore, Guix has taken sufficient
> technical measures to avoid steering its user towards nonfree software
> and thus Guix is compliant with the FSDG.

[...]

can we please consider to add a specific section to the manual including
a properly redacted copy of this exact text?

I think that specifically stating that no non-free code will be saved in
store due to ``guix build`` is specifically addressed by the snippet
field in <origin> (other procedures?) *and* assessed [1] by guix
maintainers will be of great help in all future discussions on this
topic (and there will be other discussions :-) )

WDYT?

David whould you like to propose a patch if anouth consensus on this
topic is reached? If you cannot, I can help on this.


Thanks! Gio'



[1] it means that missing to remove non-free code is considered a bug
and treated accordingly to the FSGD

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

Re: Guix and FSDG

[Giovanni Biscuolo]

clement@lassieur.org (Clément Lassieur) writes:

[...]

> The former allows me to access zpaq64.exe and zpaq.exe although the
> snippet is:
>
> --8<---------------cut here---------------start------------->8---
> (snippet
>  ;; Delete irrelevant pre-compiled binaries.
>  '(begin
>     (for-each delete-file (find-files "." "\\.exe$"))
>     #t))
> --8<---------------cut here---------------end--------------->8---

please can you file a bug?
the bug could (should) be specific to the zpaq package

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

Re: Guix and FSDG

[Clément Lassieur]

Giovanni Biscuolo <g@xelera.eu> writes:

> please can you file a bug?
> the bug could (should) be specific to the zpaq package

No, it's common to all packages (use 'guix build -S --no-substitutes' to
reproduce easily).  And the documentation[1] doesn't say it shouldn't
behave this way.  It says:

--8<---------------cut here---------------start------------->8---
Some otherwise free upstream package sources contain a small and
optional subset that violates the above guidelines, for instance because
this subset is itself non-free code. When that happens, the offending
items are removed with appropriate patches or code snippets in the
origin form of the package (see Defining Packages). This way, guix build
--source returns the “freed” source rather than the unmodified upstream
source.
--8<---------------cut here---------------end--------------->8---

Indeed 'guix build --source' returns the freed source.  However, the
original archive does end up in /gnu/store, and its path in displayed
during the build.

[1]: https://guix.gnu.org/manual/en/html_node/Software-Freedom.html#Software-Freedom

Re: Guix and FSDG

[Ludovic Courtès]

Hello,

Clément Lassieur <clement@lassieur.org> skribis:

> Indeed 'guix build --source' returns the freed source.  However, the
> original archive does end up in /gnu/store, and its path in displayed
> during the build.

(Only if you build from source, without substitutes, etc.)

The spirit of the FSDG is that the distro must not provide, recommend, or
link to non-free code, and I think Guix is following that to the letter.

If you’re knowledgeable about Guix, sure you can find your way to the
original tarball that includes non-free bits.  But then, you can do that
more easily anyway: search for the package on the Web and you’re done.

For the record, this issue was discussed in the early days of Guix and I
don’t think anything has changed since then.  The current behavior of
‘guix build --source’ stems from those discussions (that was ca. 2015,
but I can’t find the links now).

Thanks,
Ludo’.

Re: Guix and FSDG

[zimoun]

Hi,

On Sat, 23 Nov 2019 at 19:00, Ludovic Courtès <ludo@gnu.org> wrote:

> Clément Lassieur <clement@lassieur.org> skribis:
>
> > Indeed 'guix build --source' returns the freed source.  However, the
> > original archive does end up in /gnu/store, and its path in displayed
> > during the build.
>
> (Only if you build from source, without substitutes, etc.)

If I read correctly, Clément just points out inaccuracies of the
David's answer [0]:

[0] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00376.html


<<
The most important
part of this process is that the original source archive is *never*
accessible to the Guix user via any Guix tools.
>>

Correct, even if Guix tools is vague. Is "guix repl" a Guix tools? :-)


<<
The original archive
is discarded and does not end up in the canonical location for Guix
data: /gnu/store.
>>

Incorrect, as Clément shows. And it is not a bug of the very
particular zpaq package, but a general feature of how Guix works.


<<
Therefore, Guix has taken sufficient
technical measures to avoid steering its user towards nonfree software
and thus Guix is compliant with the FSDG.
>>

> The spirit of the FSDG is that the distro must not provide, recommend, or
> link to non-free code, and I think Guix is following that to the letter.

We all agree on that. I guess.


In the initial Raghav's message, it seems that the argument is:
because Guix downloads non-free code in order to install free
software, then Guix does not follow the FSDG. This argument misreads
the current FSDG. For example, any GNU/linux distribution needs to
download non-free blobs and then removes them. Even, the FSDG webpage
[1] points to scripts [2] that remove these non-free blobs. The
keyword in the FSDG is "installable" and nothing is said about
"download", from my understanding.

[1] https://www.gnu.org/distros/free-system-distribution-guidelines.html
[2] http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/


> For the record, this issue was discussed in the early days of Guix and I
> don’t think anything has changed since then.  The current behavior of
> ‘guix build --source’ stems from those discussions (that was ca. 2015,
> but I can’t find the links now).

I have not found neither.

However, from my perspective, all this seems more a troll than a real issue. :-)



All the best,
simon

Re: Guix and FSDG

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]

Hello Clément,

Clément Lassieur <clement@lassieur.org> writes:

> Giovanni Biscuolo <g@xelera.eu> writes:
>
>> please can you file a bug?
>> the bug could (should) be specific to the zpaq package
>
> No, it's common to all packages (use 'guix build -S --no-substitutes' to
> reproduce easily).  And the documentation[1] doesn't say it shouldn't
> behave this way.  It says:

[...]

Oh I forgot this part of the manual, sorry!  That is the relevant part
of our documentation that explains the technical measures taken by Guix
to help packagers and maintainers in keeping Guix FSDG compliant.

Maybe (maybe!) that section can be expanded, i.e. incorporating a
reworked version of the explanation David Thompson gave us on Fri, 22
Nov 2019 12:03:36 -0500, but I'm not able to propose a patch to that
section of the manual: patches wellcome! :-)

Also, I misinterpreted the role of the snippet code in package
definition and that is why I asked for a bug report: nevermind! :-S

To be absolutely clear, I do _not_ think that downloading a source
containing some non-free code subset in order to automatically build a
freed package violates the FSDG, indeed it makes the liberating proces
_practical_; automating that the Guix way is also /cool/ \O/

I find this comment [1] on GNU-linux-libre by bill-auger interesting
(footnote added by me):

--8<---------------cut here---------------start------------->8---

[...]  most distros have tools to assist users in re-building packages
from source if they want to; and even trisquel, with a predominantly
non-technical user-base, publishes librification recipes for the curious
and enthusiastic - the icecat 'makeicecat' [2] script is no different in
this respect - does that put icecat outside of the FSDG?  [...]

--8<---------------cut here---------------end--------------->8---

The "Guix and FSDG" relationship is very clear to me (also thanks to
this thread) and I wish some sort of FSF FAQs on this specific topic in
order to prevent future threads like this in the future :-D

Sorry for the additional noise!

Thanks! Gio'

[...]

[1] https://lists.nongnu.org/archive/html/gnu-linux-libre/2019-11/msg00002.html

[2] https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/makeicecat

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]