On Sun, 21 Nov 2021 11:54:15 +0100 "pelzflorian (Florian Pelz)" wrote: > Hello Denis. Thank you for your write-up. Hi, > raid5atemyhomework wrote patches to add ZFS to Guix > . I put them in CC. That there is > no decision on ZFS and their patches is bad. Maybe their patches > would be for the RFC model to decide? > > As for Denis’ arguments > : > > IANAL but I would dispute this: > > On Sun, Nov 21, 2021 at 02:33:24AM +0100, Denis 'GNUtoo' Carikli > wrote: > > If I take individual drivers from Linux which are under the GPLv2 or > > the GPLv2 or later, and I combine them in a new combined work on a > > new git repository with code under the CDDL license, this is not > > legal either. And here too I hope that there is some consensus on > > that too. > > If we are talking about source code, the GPLv2 files and the CDDL > files are not intertwined into a combined work at all. They are just > in the same git repo on the same file-system. Just adding GPLv2 and CDDL files in the same repository should not be a problem as far as I know. For instance you can have a kernel module under the GPLv2, and a userspace tool under the CDDL license that doesn't use code from the GPLv2 driver, and in that case both don't constitute a combined work. If the userspace tool uses syscalls from the kernel, the kernel headers license has an exception for that so it shound't be an issue either. However I've reviewed a bit the ZFS kernel driver and some files are under the CDDL license, and that driver also uses functions from the Linux kernel, and it needs to be directly linked to Linux to uses these functions. I didn't take into account the fact that the ZFS driver also has GPLv2(+?) code or the structure of the repository because having files under the CDDL licenses that are compiled in the ZFS driver and having that driver use Linux function (through linking) is sufficient to make sure that this is a combined work of Linux and that driver. And since Linux's GPLv2[1] and the CDDL[2] are incompatible, even in source code form the ZFS driver is not legal as it violates Linux's GPLv2 license. Adding extra layer(s) of indirection with code under GPLv2 compatible licenses won't change anything here as the ZFS driver links with Linux anyway and it uses functions in Linux. As for the GPLv2 in the ZFS driver, in the module directory of zfs-2.1.1, we have several files under the GPLv2 license or compatible licenses. If I "grep -i gpl" in the module directory, it gives several files, but all the files I found are OK with that are OK with regard with the GPLv2: - lua/lapi.c has 'ZFS_MODULE_LICENSE("Dual MIT/GPL")', so we can can probably assume that GPL is the GPLv2 and use it under the GPLv2 here. - The following files are under the GPLv2 or BSD 2 clauses, here we can use them under the GPLv2, so it's OK: - zcommon/zfs_fletcher_aarch64_neon.c - zcommon/zfs_fletcher_intel.c - zcommon/zfs_fletcher_sse.c - zcommon/zfs_fletcher_superscalar4.c: - zcommon/zfs_fletcher_superscalar.c - Finally, zstd/zfs_zstd.c is under the BSD 3 clauses, and also has "ZFS_MODULE_LICENSE("Dual BSD/GPL");" inside. In any case that BSD license isn't incompatible with the GPL, and we can use the GPL in "Dual BSD/GPL", so we're good in either cases. As for the problematic symbols, for instance dequeue_signal is exported by Linux and it's used by the ZFS driver. To find about that you can use the following command in a Linux git checkout to find the list of exported symbols: > git grep -P "EXPORT_SYMBOL(_GPL)?\(.*\);" And then the idea is to grep for them in the module directory, and check if they are reimplemented by the ZFS module or not. Another way to do that check would be to look at the module (the .ko file) with nm or a similar tool and look at the undefined symbols (U). As I understand from what Bradley Kuhn told me, the EXPORT_SYMBOL_GPL macro name is misleading and It doesn't mean that one can use symbols exported by EXPORT_SYMBOLS without having to abide by the GPL, and I need to look at EXPORT_SYMBOLS_GPL history to understand that in more details. But we don't need to do that either here as the dequeue_signal is exported with EXPORT_SYMBOL_GPL anyway (it's in kernel/signal.c Linux) and AFAIK it's not reimplemented by the ZFS driver either. And I didn't check how many symbols from Linux are used but one is enough to be an issue. References: ----------- [1] Many files that are being compiled in Linux are under the GPLv2 only or compatible licenses. [2] The ZFS driver has code under the CDDL license that is compiled in the ZFS driver. Denis.