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

[raid5atemyhomework]

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