5 ms·

Last I joined in on the discussion I got quite convinced by the argument "if Nvidia can use a propietary license for their Linux graphics driver, then Canonical

by DCKing 11y ago

Last I joined in on the discussion I got quite convinced by the argument "if Nvidia can use a propietary license for their Linux graphics driver, then Canonical can use the CDDL for their ZFS driver". Substitute for any other propietary modules that people like to load in their Linux kernels. Can anyone point me out why this argument is wrong? Googling around for this I was actually suprised that propietary kernel modules are in fact a debated topic (obviously to little success of the opponents), but doesn't the practical existence of propietary kernel modules at least show that no-one has had a problem with this for a long time, legally speaking?

mschwaig 11y ago
The problem is not the use per se, the problem is delivering them to the user as one blob of software together. This is not a problem with proprietary graphics drivers, since you can just download them after setting up you system. However, if you want to boot from a ZFS disk, you need the ZFS driver and the only way to obtain it at that point is effectively from the installation medium.
- DCKing 11y ago
  OK, fair enough. So distributions that ship the Nvidia drivers in their distro install image (AFAICT OpenELEC does this, not Canonical though) should be in trouble then? And Canonical would find a way around this by autodownloading the ZFS driver when the user select the "ZFS" option in the installer?
  - mschwaig 11y ago
    IANAL but as far as I can tell there is no legal precedent here and so the questions you raise can only be answered by a lawsuit. Sure there is 'technically' a difference between packaging the ZFS driver with Ubuntu and audodownloading it, but it all depends on how a court sees it, because as long as there is no precedent you can't get off on a technicality like this.
- fweespeech 11y ago
  This isn't quite correct. Nothing really prevents the LiveUSB distribution from writing to itself under ext3, build the ZFS during installation, then use the binary compiled from this process to set it up on the actual SSDs/HDDs. This is legally essentially the same binary blob Nvidia driver as you aren't distributing the binary. I'm assuming the reason this wasn't done was due to the convenience + you'd need to setup the USB like: https://help.ubuntu.com/community/LiveCD/Persistence https://help.ubuntu.com/community/LiveCD/Persistence But once you compiled it on the persistent partition, you'd be able to perform the installation just fine legally and technically is my understanding.
- dTal 11y ago
  Surely that ship sailed on Android a long time ago? Proprietary drivers, shipped to the user with Linux as a single blob, is the norm. It's the biggest problem facing Linux today, much bigger than no ZFS - it kills the concept of a "distro" on the biggest class of personal computers. How does this not violate the GPL?
jordigh 11y ago
nvidia is using parts of the Linux API that the Linux developers have explicitly declared to not activate copyleft. They have at times asked for more non-GPL APIs, which I think has been denied: http://linux.slashdot.org/story/12/10/11/1918251/alan-cox-to-nvidia-you-cant-use-dma-buf http://linux.slashdot.org/story/12/10/11/1918251/alan-cox-to... I don't know what the situation is with ZFS with regards to the APIs that it's using. There is also the question of how the software is being combined and distributed. If you receive ZFS and Linux as a "single work", which in SFC's view Ubuntu is doing by putting it all together in a neat little binary package, then the copyleft might activate.
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...

by DCKing 11y ago

mschwaig 11y ago

The problem is not the use per se, the problem is delivering them to the user as one blob of software together. This is not a problem with proprietary graphics drivers, since you can just download them after setting up you system. However, if you want to boot from a ZFS disk, you need the ZFS driver and the only way to obtain it at that point is effectively from the installation medium.

DCKing 11y ago
OK, fair enough. So distributions that ship the Nvidia drivers in their distro install image (AFAICT OpenELEC does this, not Canonical though) should be in trouble then? And Canonical would find a way around this by autodownloading the ZFS driver when the user select the "ZFS" option in the installer?
- mschwaig 11y ago
  IANAL but as far as I can tell there is no legal precedent here and so the questions you raise can only be answered by a lawsuit. Sure there is 'technically' a difference between packaging the ZFS driver with Ubuntu and audodownloading it, but it all depends on how a court sees it, because as long as there is no precedent you can't get off on a technicality like this.
fweespeech 11y ago
This isn't quite correct. Nothing really prevents the LiveUSB distribution from writing to itself under ext3, build the ZFS during installation, then use the binary compiled from this process to set it up on the actual SSDs/HDDs. This is legally essentially the same binary blob Nvidia driver as you aren't distributing the binary. I'm assuming the reason this wasn't done was due to the convenience + you'd need to setup the USB like: https://help.ubuntu.com/community/LiveCD/Persistence https://help.ubuntu.com/community/LiveCD/Persistence But once you compiled it on the persistent partition, you'd be able to perform the installation just fine legally and technically is my understanding.
dTal 11y ago
Surely that ship sailed on Android a long time ago? Proprietary drivers, shipped to the user with Linux as a single blob, is the norm. It's the biggest problem facing Linux today, much bigger than no ZFS - it kills the concept of a "distro" on the biggest class of personal computers. How does this not violate the GPL?

jordigh 11y ago

nvidia is using parts of the Linux API that the Linux developers have explicitly declared to not activate copyleft. They have at times asked for more non-GPL APIs, which I think has been denied: http://linux.slashdot.org/story/12/10/11/1918251/alan-cox-to-nvidia-you-cant-use-dma-buf http://linux.slashdot.org/story/12/10/11/1918251/alan-cox-to... I don't know what the situation is with ZFS with regards to the APIs that it's using. There is also the question of how the software is being combined and distributed. If you receive ZFS and Linux as a "single work", which in SFC's view Ubuntu is doing by putting it all together in a neat little binary package, then the copyleft might activate.

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...