Hello again Maxime, > > +OpenZFS currently only supports Linux-Libre and is not available on the > > +Hurd. > > + > > +OpenZFS is free software; unfortunately its license is incompatible with > > +the GNU General Public License (GPL), the license of the Linux kernel, > > +which means they cannot be distributed together. However, as a user, > > +you can choose to build ZFS and use it together with Linux; you can > > +even rely on Guix to automate this task. See > > +@uref{https://www.fsf.org/licensing/zfs-and-linux, this analysis by > > +the Free Software Foundation} for more information. > > That analysis says explicitely that the CDDL is incompatible with the GPL, > and that they cannot be legally linked together. E.g., see the second quoted > paragraph: > > ‘A copyleft license, including any version of the GNU GPL or GNU AGPL, requires > augmented versions to be free under the same license -- the same requirement it > applies to modification of the code.1 I wrote a copyleft license for GNU programs > to ensure that all users of all versions of them would get the freedoms I intended > to give them. > > It is not enough to require that the combined program be free software somehow. It > must be released, as a whole, under the original copyleft license, to ensure that: > (1) subsequent users get the exact same freedoms and (2) subsequent intermediaries > do not get more opportunity than first-stage intermediaries to make the program nonfree.’ I think the key word you miss here is "released", i.e. "It must be released, as a whole, under the original copyleft license." Looking at the GPLv2, the word "release" is never used, however I believe the "release" word in the FSF analysis would be considered as a synonym of "distribute" in this context. The GPLv2 mentions "distribute" many times, but provides no definition of the word. My understanding is that "distribute" used in GPL means "to provide or make available to at least one person that asks for a copy from you, via some medium". The GPLv2 imposes many restrictions on the ability to "distribute", so it seems reasonable to consider it an important point. Now, as I have pointed out, the existing package definition in `gnu/packages/file-systems.scm` specifically disables making a binary copy ("substitute" in Guix parlance) available. In addition, my understanding is that when compiling from source, the `source` field is what is used, and the `source` field in the `gnu/packages/file-systems.scm` refers to github.com, not any Guix server. There is no text in GPLv2 which restricts compilation. However, it can be argued that compilation is a form of translation from source code to machine-executable binary, and the text does mention "translation is included without limitation in the term 'modification'". GPLv2 restricts modification with three terms: a. You should have prominent notices on modified files. b. Extra restriction on copies you ***distribute*** or ***publish***. c. Extra restriction if the program is interactive and prints copyright notices normally. (a) does not apply since the linking process used (a form of dynamic linking) does not actually modify any files; presumably only in-memory tables or some such are modified. (b) does not apply if "distribute" is not what is being done by Guix here. (c) does not apply since the Linux kernel is not interactive (and even so, does not print copyright notices, not even in debug logs). On the CDDL side, neither "compile" nor "translate" is ever used, but for completeness let us consider compile == translate == modify. Modifications are specifically allowed under conditions in section 3. However, again, section 3 is titled "distribution obligations", meaning they only apply on *distribution*. So I think the issue here really is: Does Guix "distribute" the ZFS linked with Linux? My understanding is that the mere existence of code to perform that linking does not in fact *distribute* the code (linking is not the same as distributing); I believe the key point of "distribute" is that a third party gets a copy. And at least, the code I added in this patch does not provide any copy of the compiled code to anyone else; it just stores it on the local machine's disk, in a cpio archive that is used in the system's bootup. The copy, in the execution of the code I added, is never provided to anyone else, so I think my patch is unproblematic Quick question: does `guix publish` respect `#:substitutable? #f`? If `guix publish` respects `#:substitutable? #f` then it seems to me that even the point "Guix should make at least an attempt to warn users of possibly legal gray areas when distributing" does not apply, too: Guix by itself would not (should not, really; that should be the point of `#:substituable? #f`) publish the compiled code anyway, users who specifically want to publish ZFS and Linux linked together would need to modify the `guix publish` code, and such a user would be running a fork of Guix, not Guix itself, thus should be made aware of this. Indeed, if `guix publish` does *not* respect `#:substitutable? #f`, I think it would be more effective to protect users against potential legal gray areas for `guix publish` to respect that flag, and for us to then audit existing non-GPLv2-compatible kernel modules and ensure they are `#:substitutable? #f`, then to put up a warning; a warning might be overlooked, but an outright refusal to publish cannot. Thanks raid5atemyhomework