[bug#45692] [PATCH v4 3/3] gnu: Add ZFS service type.

[raid5atemyhomework via Guix-patches via <guix-patches@gnu.org>]

Greetings Maxime,

> Maxime Devos schreef op do 02-09-2021 om 22:57 [+0200]:
>
> > Hi,
> > Some comments on the code. Spoiler: the code is presumably good,
> > but there's a GPL violation.
>
> Nevermind, it's apparently less of an issue than I expected?
> See the links to IRC at https://issues.guix.gnu.org/50347.

Note that this patch does ***not*** add ZFS to the Guix project.
Instead, this patch creates a convenient service that uses the existing `zfs` package and builds the user system so that the user downloads the ZFS source code, compiles it, and links it to the kernel on the system.

In #50347, you refer to this analysis: https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

I quote this part:

> ## Is The Analysis Different With Source-Only Distribution?
>
> ...
>
> Pure distribution of source with no binaries is undeniably different. When
> distributing source code and no binaries, requirements in those sections of
> GPLv2 and CDDLv1 that cover modification and/or binary (or “Executable”, as
> CDDLv1 calls it) distribution do not activate. Therefore, the analysis is
> simpler, and we find no specific clause in either license that prohibits
> source-only redistribution of Linux and ZFS, even on the same distribution
> media.

This is in line with the analysis already quoted in the documentation added: https://www.fsf.org/licensing/zfs-and-linux

Guix does ***not*** distribute any binaries; see the file `gnu/packages/file-systems.scm` in the **current** `master` branch of Guix:

>     `(;; The ZFS kernel module should not be downloaded since the license
>       ;; terms don't allow for distributing it, only building it locally.
>       #:substitutable? #f

Note that the above code ***predates*** this patch: fe338d7f009 (Efraim Flashner 2019-12-19 11:47:49 +0200 1188)
Also CCing Efraim here --- presumably he had some choice arguments about how `zfs` got into `gnu/packages/file-systems.scm` in the first place.

If the CDDL-GPL incompatibility is problematic, then why is it only being brought up now, why did it not get brought up in 2019, when Efraim was submitting the patch that put the ZFS package into Guix in the first place?

The code in this patch does not do anything that the user cannot do with their own scripts (indeed, I prototyped much of the code in my own `configuration.scm`).
The code in this patch also does not link, directly or indirectly, into the ZFS kernel module.
At worst, the code in this patch executes the binaries that are the output of compilation, but since it is invoked as a separate binary running in a separate process, there is no legal basis for considering this as "linking", as opposed to merely invoking a separate program (if merely invoking a separate program was enough to "link", then Windows cannot run any free software).

Your referred document then makes some speculation that even source distribution might be problematic.
However, Guix does *not* even distribute sources, by my understanding --- the Guix build downloads from https://github.com/openzfs/zfs/releases/ without going through any Guix servers, so this should be even less of a problem.
If anyone is at legal risk, it is github, not Guix, for distributing the sources --- and it would be very strange for Oracle to not go after github for distributing source code that is intended to be linked to GPL code, but go after Guix; Guix is a much more niche project than the openzfs/zfs project on github.
(my understanding is that Oracle implicitly allows the existence of openzfs/zfs, even has some maintainers of the project on their payroll, so it would be very strange to go after software that just downloads the source code from that project, compiles it, links it, and does ***not*** distribute it (`#:substitutable? #f`))

My understanding (and my argument) is that the already-existing code introduced in fe338d7f009 does not represent a distribution of any ZFS code, not even source:

* The existing fe338d7f009 code tells Guix to download from a github server, not from Guix.
* The existing fe338d7f009 code specifically tells Cuirass to not provide a binary substitute, so Guix end-users must download from github, not from any Guix servers.
  * Thus, even if source distribution is legally problematic, Guix does not even distribute the source; the existing fe338d7f009 code just downloads it from an existing distributor.
  * That Oracle tolerates the continued existence of https://github.com/openzfs/zfs undermines any legal argument Oracle might make if somebody else builds a script that downloads ZFS from https://github.com/openzfs/zfd and compiles it and links it to GPL code locally without redistributing; that project already contains human-readable instructions on how to download, build, and link ZFS to a Linux kernel, the existing fe338d7f009 code merely translated that text to a machine-readable program.
    If Oracle thinks this is legally problematic, they should have demanded shutdown of the https://github.com/openzfs/zfs project first, a much more popular project than Guix.
* The actual code in this patch does not directly invoke the ZFS kernel module.
  * The actual code in this patch does link the ZFS kernel module to the kernel of the *local* system, but does not make this linked version available to others; it is only available locally on the system of the user that invokes this actual code.
    Again, this is merely a translation (to machine-readable text instructions) of human-readable text instructions on how to link the ZFS kernel module to the Linux kernel, text available publicly on https://github.com/openzfs/zfs.
  * The actual code in this patch invokes the ZFS tools as separate programs, thus does not link with them.

Thanks
raid5atemyhomework