Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

[Denis 'GNUtoo' Carikli]

On Sun, 21 Nov 2021 11:54:15 +0100
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

> Hello Denis.  Thank you for your write-up.
Hi,

> raid5atemyhomework wrote patches to add ZFS to Guix
> <https://issues.guix.gnu.org/45692>.  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
> <https://lists.gnu.org/archive/html/guix-devel/2021-11/msg00101.html>:
> 
> 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.

pgpYS7M1uljPz.pgp
Description: OpenPGP digital signature