3 ms·
If I may I'd like to share my understanding of the technical aspects which, I feel, makes the issue easier to comprehend. It also pays to be precise and lack t
by iam-TJ 11y ago
If I may I'd like to share my understanding of the technical aspects which, I feel, makes the issue easier to comprehend.
It also pays to be precise and lack thereof is why so many people are confused and conflicted about the licensing.
The Canonical Kernel Team has added the 'OpenZFS on Linux' source-code [0] in the ./zfs/ directory of the Ubuntu 4.4+ kernel tree [1].
The ZFS modules are built using the OpenZFS on Linux project's stand-alone build tools.
As I understand it from reading the code and following some ZFS project developer discussions the OpenZFS on Linux code is partitioned into common parts that are largely unchanged on all the operating systems it is ported to, plus (in this case) a Linux-specific glue layer that translates the Solaris API to the Linux API in the Solaris Porting Layer (SPL). Each part is built as separate modules; there are 8:
/lib/modules/${VERSION}/kernel/zfs/avl/zavl.ko
/lib/modules/${VERSION}/kernel/zfs/nvpair/znvpair.ko
/lib/modules/${VERSION}/kernel/zfs/spl/spl.ko
/lib/modules/${VERSION}/kernel/zfs/splat/splat.ko
/lib/modules/${VERSION}/kernel/zfs/unicode/zunicode.ko
/lib/modules/${VERSION}/kernel/zfs/zcommon/zcommon.ko
/lib/modules/${VERSION}/kernel/zfs/zfs/zfs.ko
/lib/modules/${VERSION}/kernel/zfs/zpios/zpios.ko
The licenses of each module:
$ find . -type f | while read F; do echo "${F} $( modinfo -F license ${F})"; done | sort
./avl/zavl.ko CDDL
./nvpair/znvpair.ko CDDL
./splat/splat.ko GPL
./spl/spl.ko GPL
./unicode/zunicode.ko CDDL
./zcommon/zcommon.ko CDDL
./zfs/zfs.ko CDDL
./zpios/zpios.ko GPL
These binary kernel objects (a.k.a. modules) are distributed in the Ubuntu linux-image-${VERSION}_${ARCH}.deb [2] according to Canonical's interpretation as an aggregate work as far as copyright is concerned.
That is, works from different projects in the same container, as in e.g. an ISO image.
As can be seen above the 'glue' layer (SPL) is under the GPL. 'zfs.ko' depends on 'spl.ko' (needs to dynamically link to it at run-time):
$ modinfo -F depends zfs/zfs.ko
spl,znvpair,zunicode,zcommon,zavl
The modules under the CDDL contain the core OpenZFS code which is not derived in any way from Linux.
This suggests to me that any conflict between the CDDL and GPLv2 occurs in the OpenZFS on Linux port/project itself, not between the Linux kernel project GPLv2 license and the OpenZFS on Linux CDDL.
In other words, if there is a violation of the GPLv2 as Software Freedom Conservatory (SFC) claim, it occurs in the distribution of the OpenZFS on Linux binaries themselves, since that will combine both CDDL and GPLv2 binaries, even if that was distributed as a stand-alone package (e.g. OpenZFSonLinux.deb) - regardless of whether those binary modules are aggregated with the Linux kernel or not.
I'm pointing this out since most commentary I've read seems to assume that when "GPLv2" is mentioned it means the Linux kernel licence, whereas this analysis suggests the conflict is in the OpenZFS on Linux project's use of CDDL and GPLv2 if distributed in binary form.
There may be an additional viewpoint: that the code in 'spl.ko' (The Solaris Porting Layer) is a derivative of the Linux kernel code; I'm not clear if that is the case or if it would have any impact on the SFC 'binary distribution' theory.
Moving on... once installed on a target system there is a kernel image, Linux mainline dynamically loadable kernel modules, and third-party kernel modules (ZFS, DKMS-based modules, etc.):
/boot/vmlinuz-${VERSION}
/lib/modules/${VERSION}/kernel/
/lib/modules/${VERSION}/kernel/zfs/
/lib/modules/${VERSION}/updates/
Assuming ZFS is in use as the root file-system the ZFS modules
will be copied into the initial ramdisk by the 'update-initramfs' tool scripts:
/boot/initrd.img-${VERSION}
At boot-time the kernel will dynamically load the ZFS modules from this initial RAM disk image; This is the point where dynamic linkage actually occurs.
This is also usually the focus of arguments about GPLv2 compatibility, as in, for example, the nvidia kernel module.
In the nvidia case, rather like OpenZFS on Linux, the core code is not derived from Linux but is stand-alone and common across other operating systems (Windows, BSD). An nvidia GPLv2 API translation module is dynamically built (using DKMS) to match the kernel installed/running version(s) on the target system to the nvidia 'common core' binary blob library.
The obvious difference (setting aside the nvidia vs OpenZFS licenses) is OpenZFS on Linux API translation (SPL) is pre-built and distributed as a binary by Canonical/Ubuntu.
[0] https://github.com/zfsonlinux/ https://github.com/zfsonlinux/
[1] http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/zfs http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/z...
[2] http://packages.ubuntu.com/xenial/amd64/linux-image-4.4.0-10-generic/filelist http://packages.ubuntu.com/xenial/amd64/linux-image-4.4.0-10...
- nkurz 11y agoI think everything you say is correct. I presume you've read it, but Eben Moglen and Mishi Choudhary give a fairly clear summary of the legal issues here: https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html https://www.softwarefreedom.org/resources/2016/linux-kernel-... The problem is solely with distributing in "object code or executable form" a "work" based on a GPLv2 program without also providing the source to that work under a GPLv2 license: http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html Practically everyone agrees that if the end user puts the GPL and CDDL pieces together (whether compiled from source or downloaded as separate binaries) that there is no legal problem. The issue is whether the conjoined pieces that Ubuntu plans to distribute constitute a single "work", for if so the GPL says that this "work" cannot be distributed with the ZFS source offered under the less restrictive CDDL. If Ubuntu's distribution is a single "work", there isn't that much dispute that it would be considered a derivative work of the constituent pieces. So the question becomes, does a compiled kernel plus an assortment of compiled kernel modules bundled together in whatever form Ubuntu offers constitute a "work based on the Program" as defined by the GPL license? Unfortunately, I don't think there is any clear answer possible. The technical logic of the matter is only relevant in so far as one side's lawyer can persuade one or several non-technical judges that their side has more factors in favor of their interpretation than the other side has in its. If it actually went to trial, the outcome (and possible appeals) would be a crap-shoot.
- iam-TJ 11y agoPart of your comment illustrates the confusion I was seeking - and apparently failing - to point out. You wrote: "The issue is whether the conjoined pieces that Ubuntu plans to distribute constitute a single "work", for if so the GPL says that this "work" cannot be distributed with the ZFS source offered under the less restrictive CDDL." My point is that the OpenZFS on Linux project contains individual components licensed by either the CDDL or GPLv2 is where the problem lies. As in, if I distribute binaries of the OpenZFS on Linux project to you on their own this apparent CDDL vs GPLv2 conflict arises. In that case bundling with the Linux kernel is irrelevant to the claimed issue of license incompatibility (unless the SPL is considered a derivative work of Linux [and that implies some further license interference pattern] - but equally it could be said SPL is a derivative of Solaris). Bundling would usually fall under the copyright aggregation definition, which in almost all jurisdictions does not cause license conflicts between the component parts of the aggregated works.