Big News for ZFS on Linux(dtrace.org)
dtrace.org
Big News for ZFS on Linux
http://dtrace.org/blogs/ahl/2016/03/07/big-news-for-zfs-on-linux/
23 comments
The door is already open - nVidia's graphics driver is closed source.
Besides it should be possible to easily distribute third party binary drivers for Linux and have some reasonable expectation that they work. The fact that you can't is one of the biggest reasons Android updates suck so much.
Besides it should be possible to easily distribute third party binary drivers for Linux and have some reasonable expectation that they work. The fact that you can't is one of the biggest reasons Android updates suck so much.
> The door is already open - nVidia's graphics driver is closed source.
The situation with the nvidia driver relies on the part of the API that the Linux devs have claimed is not GPL. When nvidia wants more API, the Linux devs have pushed back against that:
http://linux.slashdot.org/story/12/10/11/1918251/alan-cox-to...
I don't know how this compares to ZFS. But regardless, there's another thing at play here, the method of distribution. Nvidia doesn't ship Linux together with its blob. I think that if nvidia did that, we would have a situation more analogous to ZFS + Ubuntu.
The situation with the nvidia driver relies on the part of the API that the Linux devs have claimed is not GPL. When nvidia wants more API, the Linux devs have pushed back against that:
http://linux.slashdot.org/story/12/10/11/1918251/alan-cox-to...
I don't know how this compares to ZFS. But regardless, there's another thing at play here, the method of distribution. Nvidia doesn't ship Linux together with its blob. I think that if nvidia did that, we would have a situation more analogous to ZFS + Ubuntu.
> The situation with the nvidia driver relies on the part of the API that the Linux devs have claimed is not GPL.
You are referring to symbols marked EXPORT_SYMBOL that the kernel will use when linking non-GPL code as part of the module load. ZFSOnLinux uses only these symbols. The kernel will not make symbols marked EXPORT_SYMBOL_GPL available to it and there are no hacks to access them through the presently GPL licensed compatibility layer. Code that bypasses this when built as a standalone module will not be accepted by the project.
You are referring to symbols marked EXPORT_SYMBOL that the kernel will use when linking non-GPL code as part of the module load. ZFSOnLinux uses only these symbols. The kernel will not make symbols marked EXPORT_SYMBOL_GPL available to it and there are no hacks to access them through the presently GPL licensed compatibility layer. Code that bypasses this when built as a standalone module will not be accepted by the project.
A lot of people think that situation (public API) is even more true with the filesystem API than the graphics driver API. It's pretty hard to call ZFS a 'derived work' of Linux when it was originally developed for a completely different operating system.
NVIDIA doesn't actually release precompiled modules, only OS-agnostic blob and Linux-specific source which you are free to build yourself.
However, there are other, valid examples like Linksys routers shipping with binary drivers for Broadcom NICs.
However, there are other, valid examples like Linksys routers shipping with binary drivers for Broadcom NICs.
> then this could open the doors for other kinds of proprietary blobs to grow on top of Linux.
But it's not a binary blob - the source code is supplied with the binary.
But it's not a binary blob - the source code is supplied with the binary.
> then this could open the doors for other kinds of proprietary blobs to grow on top of Linux.
Isn't that good?
Isn't that good?
So, correct me if I'm wrong, but isn't the license incompatibility related to shipping binaries of zfs? If a user chooses to compile locally from zfs sources, then the license issues don't apply, correct? So this is not an issue for, say, Gentoo, Funtoo, LFS, etc, and only an issue for Canonical because they are not interested in a mechanism that allows users to build packages from source, am I correct? I'm thinking something something along the lines of "Here is a tarball containing the sources and a container instance you can spin up. It leaves a .deb behind." What part of this am I missing?
Two points to this:
First, it's not without precedent. qmail's license prohibited binary redistribution (as well as modified source code distribution), and Debian's solution was packages that, as part of the install, patched, built, and installed qmail from sources on the target machine.
Secondly, this is already an option. The ZFS on Linux project [0] provides packages which do exactly this, by:
1. Distributing kernel sources and building them against the currently install(ed) kernel(s) via dkms. This is actually a common mechanism for module distribution, and is also used by Virtualbox, or anyone else distributing kernel extensions, closed-source or not, which aren't included in the mainline kernel.
2. Providing the userspace binaries to interact with the custom-built ZFS kernel modules built on behalf of the user in #1.
The difference here is Ubuntu distributing binary versions of the modules in the base install, which is important for things like installing on ZFS root, or accessing ZFS filesystems during install.
First, it's not without precedent. qmail's license prohibited binary redistribution (as well as modified source code distribution), and Debian's solution was packages that, as part of the install, patched, built, and installed qmail from sources on the target machine.
Secondly, this is already an option. The ZFS on Linux project [0] provides packages which do exactly this, by:
1. Distributing kernel sources and building them against the currently install(ed) kernel(s) via dkms. This is actually a common mechanism for module distribution, and is also used by Virtualbox, or anyone else distributing kernel extensions, closed-source or not, which aren't included in the mainline kernel.
2. Providing the userspace binaries to interact with the custom-built ZFS kernel modules built on behalf of the user in #1.
The difference here is Ubuntu distributing binary versions of the modules in the base install, which is important for things like installing on ZFS root, or accessing ZFS filesystems during install.
I am one of the ZoL developers. I assume that you are referring to the PPA and EL repositories. The ZoL PPA and EL repository maintainers use DKMS there because there is no way that a third party can ship kernel modules at the same time a distribution ships a new kernel. That means that there would always be a window of time where the new kernel is available and the modules are not, which breaks things. Furthermore, keeping up with new kernels from upstream to publish binary modules is a burden that DKMS eliminates. if it were not for those things, the upstream project repositories would have had binary modules available years ago. Since Canonical is in the position to avoid the race, they are able to ship the binary modules that the upstream project could not.
> It's not without precedent. [...] Debian's solution [for qmail]
> was packages that, as part of the install, patched, built, and
> installed qmail from sources on the target machine.
At the time qmail was shipped in Debian's non-free section, and the resulting binary wasn't being linked to a GPL codebase to get around linking clauses.
So I can't see how this has anything to do with what's happening with ZFS here.
> modules in the base install, which is important for things like installing on ZFS root
Ah yes, the bootstrapping problem.
Ah yes, the bootstrapping problem.
An init script or the installer script could compile the module. Awkward but not hard.
We can bootstrap much more difficult things. For example booting from kernel source: http://www.bellard.org/tcc/tccboot.html
We can bootstrap much more difficult things. For example booting from kernel source: http://www.bellard.org/tcc/tccboot.html
Yes, the only incompatibility arises upon distribution of binary files compiled from both ZFS sources and Linux sources. As of version 15.10, Ubuntu already provides for downloading and compiling the ZFS sources using dkms[1]. However, binary distribution is unquestionably more convenient. Source distribution requires installation of a compiler, which may not be desirable in all environments. For example, in a Live CD linux installer, where space is at a premium, enabling installation onto a ZFS filesystem would require the ZFS sources, the appropriate Linux headers, and a compiler to build the ZFS kernel module all to be included on the disc, instead of just the binary module.
[1]: http://packages.ubuntu.com/search?keywords=zfs-dkms
[1]: http://packages.ubuntu.com/search?keywords=zfs-dkms
The attorneys advising members of the ZoL project and various ZoL users have consistently said that redistributing binaries is alright. The only reason few of us do it is because there are just too many binary kernel builds to reasonably support via published binaries.
The solution seems quite obvious to me in the case of the live cd:
Don't ship ZFS on it.
The overwhelming majority of users reliant on a CD-ROM drive to install a distro do not need nor want ZFS on their system.
Don't ship ZFS on it.
The overwhelming majority of users reliant on a CD-ROM drive to install a distro do not need nor want ZFS on their system.
I disagree. As one example, Apple ships Time Machine with their OS. With ZFS you could theoretically implement the same thing only better. Automatic snapshots enabled by default, with optional replication to an external hard drive for backup, could easily be a headline feature for a new version of Ubuntu. Not to mention ZFS compression enabled by default to get more use out of tiny laptop SSDs.
Certainly not everyone needs it, but I think there's a definite use case for ZFS (or btrfs, or any similar filesystem) on an ordinary desktop system, even if the user doesn't know what ZFS is.
Certainly not everyone needs it, but I think there's a definite use case for ZFS (or btrfs, or any similar filesystem) on an ordinary desktop system, even if the user doesn't know what ZFS is.
Not theoretically, since it has been done. It is called LifePreserver and originated with PC-BSD years ago; thus available on FreeBSD an FreeNAS as well.
I will have a good laugh if Ubuntu is porting it over as a "headline feature".
I will have a good laugh if Ubuntu is porting it over as a "headline feature".
> With ZFS you could theoretically implement the same thing only better.
OpenSolaris had that as part of its Gnome file manager. It's even open source.
OpenSolaris had that as part of its Gnome file manager. It's even open source.
Are you serious? You're not serious.
Are you?
What?
Are you?
What?
On ArchLinux, a user (big shout-out to demizer) maintains a set of ZFS packages on AUR that basically do this (build from Git). On Arch, installing ZFS is a one-liner, e.g.
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=zfs-g...
$ yaourt -S zfs-git
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=zfs-g...
Yes Arch is another one that treats building from source as a mainstream option. My root question, though, is whether or not that obviates the license issue. I think it does, but I'd like confirmation.
That's the position the Debian project is taking. They're planning to provide a package that builds locally on the users system.[1]
[1] http://blog.halon.org.uk/2016/01/on-zfs-in-debian/
[1] http://blog.halon.org.uk/2016/01/on-zfs-in-debian/
I think so too, but if even providing a script is too far then just provide an easy mechanism to preload kernel modules before the installer runs.
It seems like literally something as simple as defining an extra directory on the installation medium for which all files will be loaded into the kernel at startup. Or allowing the installer to be started from a live environment, so you could download/build sources and load the module and then start installation.
Perhaps it can't be Canonical who actually writes and maintains the script, but it seems like a problem you could hack around fairly easily while maintaining plausible deniability.
It seems like literally something as simple as defining an extra directory on the installation medium for which all files will be loaded into the kernel at startup. Or allowing the installer to be started from a live environment, so you could download/build sources and load the module and then start installation.
Perhaps it can't be Canonical who actually writes and maintains the script, but it seems like a problem you could hack around fairly easily while maintaining plausible deniability.
I think it does too, but it shifts responsibility/breach from the repo maintainer to the end user.
What it does is move the license issue from Arch to the user[1]. Instead of Arch infringing on the GPL, the user is infringing on the GPL. It's much harder for groups like the SFC to sue a bunch of users than it is to sue an organization, but it doesn't make the licenses compatible.
I feel for the SFC on this issue, but I wonder what they realistically expect the outcome will be. Ubuntu stops distributing ZFS? Ubuntu ships a means to install ZFS from source (which doesn't remove the infringement, just shifts it)? Oracle convinces everybody to change the license? The last seems wildly unlikely, so I just don't quite understand what they are trying to do.
[1] Of course, AUR is a community oriented repository, not part of Arch proper, so there is not really any question of Arch being involved at all. But you get the point...
I feel for the SFC on this issue, but I wonder what they realistically expect the outcome will be. Ubuntu stops distributing ZFS? Ubuntu ships a means to install ZFS from source (which doesn't remove the infringement, just shifts it)? Oracle convinces everybody to change the license? The last seems wildly unlikely, so I just don't quite understand what they are trying to do.
[1] Of course, AUR is a community oriented repository, not part of Arch proper, so there is not really any question of Arch being involved at all. But you get the point...
The user can't infringe on the GPL. Not possible.
Users already have (by the nature of copyright law) and are explicitly in the GPL given the right to do whatever they want with the code, short of distributing it.
Users already have (by the nature of copyright law) and are explicitly in the GPL given the right to do whatever they want with the code, short of distributing it.
Sorry. Yes, of course you are right. They would have to distribute it. It's strange how one can carry incorrect notions in one's head for a long time... Thanks for correcting me!
Gentoo ships ZFS kernel binaries via the LiveDVD. There are plenty of Gentoo derivatives that ship kernel binaries binaries too. It is not shipped on the minimal install media yet because I have not yet marked it stable in the tree because of the /dev/ZFS ABI being unstable. I am in the process of rectifying this. I have already put what should be the future stable ABI into the tree. Users found a few issues with it, so I need to resolve them. Once they are fully resolved and I am certain no more linger, I will mark it as stable and the modules should make their way onto the minimal install media like they had on the LiveDVD.
So you're implying that Oracle would use its standing as a Linux copyright holder to sue Canonical for violating the GPL by integrating the (Oracle copyrighted!) CDDL'd ZFS? On the one hand, I give points for the absurdity of the scenario -- and that it makes no sense would certainly not dissuade Oracle. But on the other hand, even this bizarre scenario is missing something that all of these litigation scenarios seem to lack: damages. James Bottomley explored this issue[1], and I continue to be amazed that others either ignore it or don't treat it explicitly, as it will be the first question that will be asked by any lawyer: where are the damages? I actually ask this earnestly: can those who fear litigation here at least take a swing at establishing the economic harm here?
[1] http://blog.hansenpartnership.com/are-gplv2-and-cddl-incompa...
[1] http://blog.hansenpartnership.com/are-gplv2-and-cddl-incompa...
https://www.softwarefreedom.org/resources/2016/linux-kernel-...
"Nominal statutory damages, divided among the thousands of copyright holders entitled to equal shares, scarcely lift the matter above the level of damnum absque injuria."
"Nominal statutory damages, divided among the thousands of copyright holders entitled to equal shares, scarcely lift the matter above the level of damnum absque injuria."
Copyright holders don't need to establish economic harm, they control whether you can distribute the software at all.
> I also fear about what Oracle could do, as they are copyright holders of parts of Linux
They have already published commits to Linux under the GPL, they cannot just "take it back". The worst Oracle does is stop contributing to the kernel, which they rarely do to begin with. The "worst" Oracle can do is sue third parties that violate the GPL on their part of the kernel - which would predominantly be proprietary vendors.
They have already published commits to Linux under the GPL, they cannot just "take it back". The worst Oracle does is stop contributing to the kernel, which they rarely do to begin with. The "worst" Oracle can do is sue third parties that violate the GPL on their part of the kernel - which would predominantly be proprietary vendors.
They are also the copyright holder of a huge chunk of ZFS' code. So they can also sue Canonical over their violation of the CDDL which oracle (as the copyright holder) has licensed ZFS under.
Can you point to the area in which Canonical is in violation of the CDDL? I can't see that they are. They may be in violation of the GPL, but the CDDL seems fine. Specifically[0]:
"1.3. Covered Software means (a) the Original Software, or (b) Modifications, or (c) the combination of files containing Original Software with files containing Modifications, in each case including portions thereof."
"Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License."
The binary module they are distributing is the 'covered software' and they are making the source code and their modifications to that source code available via CDDL. They appear to be meeting their CDDL license burden.
In other words, Linux Kernel developers could sue because the GPL license terms aren't met, but Oracle couldn't sue because the CDDL license terms are being met.
[0] - https://opensource.org/licenses/CDDL-1.0
"1.3. Covered Software means (a) the Original Software, or (b) Modifications, or (c) the combination of files containing Original Software with files containing Modifications, in each case including portions thereof."
"Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License."
The binary module they are distributing is the 'covered software' and they are making the source code and their modifications to that source code available via CDDL. They appear to be meeting their CDDL license burden.
In other words, Linux Kernel developers could sue because the GPL license terms aren't met, but Oracle couldn't sue because the CDDL license terms are being met.
[0] - https://opensource.org/licenses/CDDL-1.0
n other words, Linux Kernel developers could sue because the GPL license terms aren't met, but Oracle couldn't sue because the CDDL license terms are being met.
As Oracle has contributed to the Linux kernel as well, they are in a position to sue over GPL violation.
As Oracle has contributed to the Linux kernel as well, they are in a position to sue over GPL violation.
Indeed, but generally people seem to be coming at it from the Oracle suing over the CDDL side.
Additionally, if I understand correctly, in order to have a chance to sue, Oracle would have to show that the code in question violates their actual copyright, which is only in code that the wrote/contributed. So Oracle would likely need to prove that the ZFS code interfaces/touches/uses their copyrighted code, otherwise they would not have standing (in the US). I have no clue if that interaction occurs or not.
Additionally, if I understand correctly, in order to have a chance to sue, Oracle would have to show that the code in question violates their actual copyright, which is only in code that the wrote/contributed. So Oracle would likely need to prove that the ZFS code interfaces/touches/uses their copyrighted code, otherwise they would not have standing (in the US). I have no clue if that interaction occurs or not.
Thank you - I was mistaken in some of the clauses of the CDDL.
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?
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?
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.
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?
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.
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
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.
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
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.
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?
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...
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.
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.
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:
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):
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.):
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/ [1] http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/z... [2] http://packages.ubuntu.com/xenial/amd64/linux-image-4.4.0-10...
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
$ 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
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
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/
/boot/initrd.img-${VERSION}
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/ [1] http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/z... [2] http://packages.ubuntu.com/xenial/amd64/linux-image-4.4.0-10...
I 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-...
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
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.
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
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.
Part 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.
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.
I noticed your distinction, but didn't see the relevance at first. With your clarification, I think I understand your point, although I still think this is separate from the current kerfuffle with Canonical.
Mogen and Choudhary address come close to addressing this in a footnote:
I think you raise a good point, though, and I don't think there is yet any case law covering this. Is it legal to distribute a tar file that contains both GPL and non-GPL files? I'd hope so, and hope that a court would agree, although I fear it would depend on which court and which lawyers are arguing it.
Mogen and Choudhary address come close to addressing this in a footnote:
4. The phrase "derivative work" is also a term of art in US
copyright law, but is absent from most of the rest of the
world's major copyright systems. The idiosyncratic meaning
of "derivative work" in US copyright law is unrelated to
the use of the term by the kernel developers. This causes
confusion among US copyright lawyers, but the kernel
community's use of the phrase is consistent and clear
notwithstanding.
I think you raise a good point, though, and I don't think there is yet any case law covering this. Is it legal to distribute a tar file that contains both GPL and non-GPL files? I'd hope so, and hope that a court would agree, although I fear it would depend on which court and which lawyers are arguing it.
I was using the definition of 'derivative' from copyright.gov [0]
The most direct quote I can lift from there is:
"To be copyrightable, a derivative work must incorporate some or all of a preexisting “work” and add new original copyrightable authorship to that work. The derivative work right is often referred to as the adaptation right"
That document also defines what I term an "aggregate" work as "Collective" works (Compilations).
Software Freedom Conservancy (SFC) claims [1]:
"In the present case, the files containing the code of the ZFS filesystem are available under free software license, but the terms offered are CDDL, not GPLv2. So although complete and corresponding source code for the GPLv2-licensed kernel binary is available under free license, some files are available only under terms of CDDL, which is inconsistent with the literal meaning of GPLv2 section 2(b)"
So if OpenZFS on Linux's spl.ko is considered a derivative work of the Linux kernel it abides by 'GPLv2 section 2(b)'.
"b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." [2]
SFC seems to be trying to extend the 'derivative' definition to the independently developed CDDL OpenZFS Solaris code in zfs.ko et al. which is ported/portable across several operating systems.
Additionally, to get ever more precise in the analysis, bearing in mind the supposed issue here is triggering GPLv2 section 2(b) incompatibility at the point of distribution of binaries by Canonical (or others):
1. If I distribute OpenZFS on Linux binaries to you on their own I'm distributing effectively 8 compiled executable files which are either CDDL or GPLv2 licensed. Is this incompatible with GPLv2 section 2(b)?
2. If I distribute those 8 OpenZFS on Linux binaries to you in the same package as another GPLv2 licensed work that is a Collective Work; is this incompatible?
3. If I distribute both Opens ZFS on Linux and Linux Kernel binaries in the same package is this a Collective or a Derivative work, and if the latter, where does the reach of the GPLv2 end?
I cannot see any sustainable argument that the CDDL code (zfs.ko et al.) could be considered a derivative work since it is independent cross-OS code originally written for and targeted at Solaris.
At this stage of analysis consider the way SFC talks about the 'kernel' as a single 'work' in terms of copyright:
"But when essentially the same code is linked into kernel space through the LKM APIs, it becomes part of one work with the kernel, and a potential conflict of license terms results."
So now the issue seems to have switched from "it is incompatible to distribute the OpenZFS on Linux and Linux kernel binaries together" to "it is incompatible to link them at run-time".
Canonical is responsible for the former but the User is responsible for the latter.
SFC also makes the argument that the Open ZFS on Linux GPLv2-ed binaries are licensed "subject to the kernel copyright holders' interpretation of those terms".
But is (as I posited previously) spl.ko a derivative work of the Linux kernel, or of OpenZFS, or Solaris, or all, or none?
As SPL contains original creative copyrightable code wouldn't the 'interpretation' of the programmers who wrote the SPL code be more controlling than that of the programmers that wrote the Linux kernel API it calls?
Furthermore, at the point of distribution those binaries do not contain Linux kernel copyright code in the 'derivative' sense, but have place-holders for linking into the Linux kernel API that will be done by an executing kernel.
It's certainly a very intriguing case study of licensing; hopefully it'll eventually help more programmers clarify their understanding.
Personally I publish all my code under the GPL, version 3 for preference, which I consider a way of encouraging 'pay-forward'. I'd be extremely annoyed (to put it mildly) if an unconnected third party was making claims that implicitly marginalised my intentions when I chose the license.
On a final (perverse yet humorous) note - this entire discussion is based on the assumption of U.S.A. copyright law and its derivative legal theory. Canonical is a U.K. company operating under E.U./U.K. law. In strict legal theory if this 'incompatibility' were taken to its maximum extent it could end up being legal to distribute OpenZFS on Linux binaries everywhere but in the U.S.A!
[0] http://www.copyright.gov/circs/circ14.pdf [1] http://softwarefreedom.org/resources/2016/linux-kernel-cddl.... [2] https://www.gnu.org/licenses/gpl-2.0.en.html
The most direct quote I can lift from there is:
"To be copyrightable, a derivative work must incorporate some or all of a preexisting “work” and add new original copyrightable authorship to that work. The derivative work right is often referred to as the adaptation right"
That document also defines what I term an "aggregate" work as "Collective" works (Compilations).
Software Freedom Conservancy (SFC) claims [1]:
"In the present case, the files containing the code of the ZFS filesystem are available under free software license, but the terms offered are CDDL, not GPLv2. So although complete and corresponding source code for the GPLv2-licensed kernel binary is available under free license, some files are available only under terms of CDDL, which is inconsistent with the literal meaning of GPLv2 section 2(b)"
So if OpenZFS on Linux's spl.ko is considered a derivative work of the Linux kernel it abides by 'GPLv2 section 2(b)'.
"b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." [2]
SFC seems to be trying to extend the 'derivative' definition to the independently developed CDDL OpenZFS Solaris code in zfs.ko et al. which is ported/portable across several operating systems.
Additionally, to get ever more precise in the analysis, bearing in mind the supposed issue here is triggering GPLv2 section 2(b) incompatibility at the point of distribution of binaries by Canonical (or others):
1. If I distribute OpenZFS on Linux binaries to you on their own I'm distributing effectively 8 compiled executable files which are either CDDL or GPLv2 licensed. Is this incompatible with GPLv2 section 2(b)?
2. If I distribute those 8 OpenZFS on Linux binaries to you in the same package as another GPLv2 licensed work that is a Collective Work; is this incompatible?
3. If I distribute both Opens ZFS on Linux and Linux Kernel binaries in the same package is this a Collective or a Derivative work, and if the latter, where does the reach of the GPLv2 end?
I cannot see any sustainable argument that the CDDL code (zfs.ko et al.) could be considered a derivative work since it is independent cross-OS code originally written for and targeted at Solaris.
At this stage of analysis consider the way SFC talks about the 'kernel' as a single 'work' in terms of copyright:
"But when essentially the same code is linked into kernel space through the LKM APIs, it becomes part of one work with the kernel, and a potential conflict of license terms results."
So now the issue seems to have switched from "it is incompatible to distribute the OpenZFS on Linux and Linux kernel binaries together" to "it is incompatible to link them at run-time".
Canonical is responsible for the former but the User is responsible for the latter.
SFC also makes the argument that the Open ZFS on Linux GPLv2-ed binaries are licensed "subject to the kernel copyright holders' interpretation of those terms".
But is (as I posited previously) spl.ko a derivative work of the Linux kernel, or of OpenZFS, or Solaris, or all, or none?
As SPL contains original creative copyrightable code wouldn't the 'interpretation' of the programmers who wrote the SPL code be more controlling than that of the programmers that wrote the Linux kernel API it calls?
Furthermore, at the point of distribution those binaries do not contain Linux kernel copyright code in the 'derivative' sense, but have place-holders for linking into the Linux kernel API that will be done by an executing kernel.
It's certainly a very intriguing case study of licensing; hopefully it'll eventually help more programmers clarify their understanding.
Personally I publish all my code under the GPL, version 3 for preference, which I consider a way of encouraging 'pay-forward'. I'd be extremely annoyed (to put it mildly) if an unconnected third party was making claims that implicitly marginalised my intentions when I chose the license.
On a final (perverse yet humorous) note - this entire discussion is based on the assumption of U.S.A. copyright law and its derivative legal theory. Canonical is a U.K. company operating under E.U./U.K. law. In strict legal theory if this 'incompatibility' were taken to its maximum extent it could end up being legal to distribute OpenZFS on Linux binaries everywhere but in the U.S.A!
[0] http://www.copyright.gov/circs/circ14.pdf [1] http://softwarefreedom.org/resources/2016/linux-kernel-cddl.... [2] https://www.gnu.org/licenses/gpl-2.0.en.html
When it comes to the definition for 'derivative', its helpful to look at music videos as an example. They normally don't modify the song, but the video creates a adaption of the song by applying moving pictures to the music. Such adaptation requires additional copyright permission in most nations, even if someone already have permission to distribute the music unaltered.
When we talk about a kernel module in isolation, its like talking about the moving pictures in a music video without the sound. When we talk about the independently developed OpenZFS Solaris code, we are talking about specific still frames of the video. Each part is required to make the adaption that we call a music video, and each part can be a independent copyrighted work.
Copyright get interpreted by judges and juries who normally take a common sense approach to such problems. Did party X intend to create an adaptation, and if so, did they have permission to do so? I think everyone, including FSC, agree that the Solaris developers did not create an adaptation of the linux kernel. This leaves the people who created the linux module that combined the Solaris code with linux specific adaptation code, and ubuntu that distribute the combination of kernel and module. What decision a jury would decide is to me very uncertain, but one strong argument that sways me towards FSC conclusion is that judges don't like to rule based on technicalities. If something looks like a an adaptation, it is an adaptation.
Going back to the music video example, Youtube currently works by splitting videos into two parts, a video stream and a audio stream. If they argued in court that its the user that link them at run-time, I think they would loose the argument no matter how technically true it is.
When we talk about a kernel module in isolation, its like talking about the moving pictures in a music video without the sound. When we talk about the independently developed OpenZFS Solaris code, we are talking about specific still frames of the video. Each part is required to make the adaption that we call a music video, and each part can be a independent copyrighted work.
Copyright get interpreted by judges and juries who normally take a common sense approach to such problems. Did party X intend to create an adaptation, and if so, did they have permission to do so? I think everyone, including FSC, agree that the Solaris developers did not create an adaptation of the linux kernel. This leaves the people who created the linux module that combined the Solaris code with linux specific adaptation code, and ubuntu that distribute the combination of kernel and module. What decision a jury would decide is to me very uncertain, but one strong argument that sways me towards FSC conclusion is that judges don't like to rule based on technicalities. If something looks like a an adaptation, it is an adaptation.
Going back to the music video example, Youtube currently works by splitting videos into two parts, a video stream and a audio stream. If they argued in court that its the user that link them at run-time, I think they would loose the argument no matter how technically true it is.
Such adaptation requires additional copyright permission in most nations, even if someone already have permission to distribute the music unaltered.
It's a great comparison on a common sense basis, but could you be more specific? My impression is that in the US there still isn't any definitive "vidding" caselaw. Are you aware of some, or by "most nations" are you referring to the (primarily European) moral rights to the integrity of the work? [1]
[1] https://meta.wikimedia.org/wiki/Wikilegal/Moral_right_of_int...
It's a great comparison on a common sense basis, but could you be more specific? My impression is that in the US there still isn't any definitive "vidding" caselaw. Are you aware of some, or by "most nations" are you referring to the (primarily European) moral rights to the integrity of the work? [1]
[1] https://meta.wikimedia.org/wiki/Wikilegal/Moral_right_of_int...
Moral rights in EU is used to address a different problem, primarily about the association between the author and his work. For example, political advertisement would need to walk careful when using stock-photos or music repositories, since the integrity of the work could be seen as infringed on. It is normally seen as covered by defamation laws in the US, so its not part of US copyright.
What I am talking about is Synchronization rights[1]. If a musician has a deal with a publisher, they often want to be paid more if the song is played on a TV commercial then if its played on the radio or distributed on a CD. Most of this I just remember reading about years ago, but I remember that creative commons also address this concept[2]. An other example would be the agreement between NMPA and YouTube in 2011, where YouTube was granted the right to "reproduce, distribute and prepare derivative works (including synchronization rights)".
I have not memorized any specific cases where someone challenged this industry practice in court, and digging for one would take a bit more time that I have at the moment.
[1] https://en.wikipedia.org/wiki/Synchronization_rights
[2] https://creativecommons.org/licenses/by/3.0/legalcode
What I am talking about is Synchronization rights[1]. If a musician has a deal with a publisher, they often want to be paid more if the song is played on a TV commercial then if its played on the radio or distributed on a CD. Most of this I just remember reading about years ago, but I remember that creative commons also address this concept[2]. An other example would be the agreement between NMPA and YouTube in 2011, where YouTube was granted the right to "reproduce, distribute and prepare derivative works (including synchronization rights)".
I have not memorized any specific cases where someone challenged this industry practice in court, and digging for one would take a bit more time that I have at the moment.
[1] https://en.wikipedia.org/wiki/Synchronization_rights
[2] https://creativecommons.org/licenses/by/3.0/legalcode
I see now what you are saying, although I'm not sure if the granularity of licensing affects the legality of the redistribution. But that might be because I've been thinking about it solely in the context of noncommercial areas, where "fair use" rather than licensing is the gauge. Once under "fair use", there is no special treatment of synchronization, and there even exists a specific DMCA exclusion for non-commercial video mashups: https://www.eff.org/files/2015/02/09/2014-07_eff_remix_comme...
Thanks for the followup and the fine example!
Thanks for the followup and the fine example!
This was in the news before. What's the big new thing about this article? It reads like a writeup of the news of yesterday. Also, ZFS is not coming to Linux as such, it's coming to Ubuntu specifically and the article does not clear up the detail why this is now possible for Ubuntu but was not possible for the rest of the Linux community.
ZFS is not coming to Linux as such, it's coming to Ubuntu specifically
This is a faulty understanding of the issue. Other distros such as Debian are packaing 'ZFS on Linux'. Ubuntu is not the first one to offer the ability to have ZFS on Linux in the distros main repository. The difference is actually that the other distros distribute the ZFS code as source, then have the user compile it on their own computer, and then those distros consider that end product as non-redistributable. Whereas Ubunutu is doing the compilation on their own, then distributing the resulting binary work. That's the actual difference.
This is a faulty understanding of the issue. Other distros such as Debian are packaing 'ZFS on Linux'. Ubuntu is not the first one to offer the ability to have ZFS on Linux in the distros main repository. The difference is actually that the other distros distribute the ZFS code as source, then have the user compile it on their own computer, and then those distros consider that end product as non-redistributable. Whereas Ubunutu is doing the compilation on their own, then distributing the resulting binary work. That's the actual difference.
Sabayon Linux has been shipping binary modules for years. No one has ever complained.
It's a fair critique though I didn't write this because I thought I was breaking news. The Canonical announcement was honestly exciting for me, in particular because they evaluated the licensing issues and decided that they were within their rights to provide ZFS to their users. It seemed though that the voices of practitioners was being drowned out by those focusing exclusively on legal matters. I was hoping to provide some information for those unacquainted with both the technology and the legal miasma. Regardless, I'm excited that ZFS is about to have many more users.
I'd imagine there are people who consider the article relevant based on its author.
https://en.wikipedia.org/wiki/Adam_Leventhal_%28programmer%2...
https://en.wikipedia.org/wiki/Adam_Leventhal_%28programmer%2...
AFAIK they are saying that because it is a DKMS module and Linux is not a derivative work, they are not restricted from using it by the license. By Canonical's interpretation, it would only become an issue if they were to build the support directly into the kernel natively rather than using a standalone zfs.ko file.
Keep in mind IANAL and this is just my limited understanding of the issue.
Keep in mind IANAL and this is just my limited understanding of the issue.
Am I really reading this correctly, that the plan seems to be "ignore the possible license incompatibility and hope Oracle doesn't sue?"
Because of all ways to fill in the "Hope _____ doesn't sue" plan, "Oracle" must be in the top 5 worst companies to fill in the blank with in the tech industry.
Because of all ways to fill in the "Hope _____ doesn't sue" plan, "Oracle" must be in the top 5 worst companies to fill in the blank with in the tech industry.
I'm not a lawyer or an expert on the CDDL, however it could be that the license incompatibility is one-way: maybe only the GPL rightsholders have reason to sue.
Unfortunately, Oracle also holds copyright in Linux, so they can sue as a GPL rightsholder.
The real question is whether Oracle could convince a jury. It is hard to imagine what their argument would be. Then again, I would have never imagined that they would use copyright law over APIs to attack Google's use of Java.
The real question is whether Oracle could convince a jury. It is hard to imagine what their argument would be. Then again, I would have never imagined that they would use copyright law over APIs to attack Google's use of Java.
Agreed on the second point, but no one (to my knowledge) is contending that Oracle's copyrights or patents are being violated.
No, the plan was, "have the lawyers evaluate the possible license incompatibility, decide that the really isn't one, and release the module." The SFLC is essentially running a FUD campaign here by trying to paint Canonical as being reckless.
SFLC seem to think CDDL/GPL are ok:
https://softwarefreedom.org/resources/2016/linux-kernel-cddl...
Perhaps you are confusing them with SFC:
https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
https://softwarefreedom.org/resources/2016/linux-kernel-cddl...
Perhaps you are confusing them with SFC:
https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
I phrased it as a "possible license incompatibility" very carefully. I'm personally ambivalent about whether it is; I know enough to know I don't know. And even those who think they know will generally agree that you don't really know know until it is tested in court.
The real problem here is that Oracle is the sort of company that does "test it in court". Is Canonical really big enough to be able to afford this level of risk? Even if they win I would be surprised if they managed to talk the judge into awarding them lawyer costs from Oracle. There's definitely enough ambiguity here that it wouldn't be a stupid suit. Legally, anyhow.
The real problem here is that Oracle is the sort of company that does "test it in court". Is Canonical really big enough to be able to afford this level of risk? Even if they win I would be surprised if they managed to talk the judge into awarding them lawyer costs from Oracle. There's definitely enough ambiguity here that it wouldn't be a stupid suit. Legally, anyhow.
One nice thing about things "coming to Ubuntu specifically" is that a lot of people get used to what Linux is "like" through Ubuntu. So when Ubuntu does something, people start looking for that thing whenever they use Linux generally. It generates demand, which pushes changes through.
I suspect "Just ignore the licences and focus on the technology" is not going to fly with enterprise customers.
Totally correct. However, it may fly just fine with Ubuntu's "just install a damn Linux and get the app online" crowd. Ubuntu makes Linux easy to install and maintain, and that could be enough for some users. They only need one or two giant apps to grow here in order for it to be called a success.
Yep. It's all fun and games until the lawsuits start :-).
I don't understand people like this. If they were advocating using pirate copies of Microsoft Windows or other proprietary software, would they be saying "ignore Microsoft legal department and focus on how cool it is that I get a free copy of Windows ?
Stupid, stupid, stupid.
I don't understand people like this. If they were advocating using pirate copies of Microsoft Windows or other proprietary software, would they be saying "ignore Microsoft legal department and focus on how cool it is that I get a free copy of Windows ?
Stupid, stupid, stupid.
I don't think that's a relevant comparison at all. What we have here is two open source technologies that have traditionally been kept from being used together because of specific clauses in their licenses, and some lawyers who have looked at it and are vouching that it's not a problem. That's far from ignoring the proprietary closed source, for-profit licensing of a product where it's very clear cut. The lawyers may be wrong, and it's probably a good idea for enterprise customers to steer clear, but the whole point is that there is some valid contention over whether the technologies can be used together. There is not valid contention over whether you can use Windows without a license.
I think it's safe to say there's a world of difference between license violations for a piece of software that's closed source, proprietary and sold for profit and a license incompatibility on two open source projects caused by a single clause in licenses that are otherwise compatible.
You may have the chops and cred to call someone stupid that wrote dtrace but I'd certainly hesitate before doing so myself.
You may have the chops and cred to call someone stupid that wrote dtrace but I'd certainly hesitate before doing so myself.
People can be very smart technically, yet legally very naive. This is a very naive legal position, which I certainly feel justified in calling "stupid, stupid, stupid".
Certainly if I was a lawyer I'd probably feel comfortable using an insult like "stupid" to describe a legal position but I'm not. You might be, I don't know. But it's still unnecessarily negative.
Lots of people do exactly that. In fact, many companies even use software for which the licenses have lapsed or they never owned licenses in the first place. Sometimes it's by accident; in other cases it's a knowing acceptance of risk.
"As with anything, evaluate the technology, evaluate the risks, and move on."
I've been selling to enterprise customers for a little while now. All technology has risk, new technology and the status quo alike. Companies weigh those risks against the expected benefits. Some folks will obviously avoid the brouhaha completely; it makes sense. Others will decide that the benefits outweigh the risk; there's nothing less comprehensible about that decision.
I've been selling to enterprise customers for a little while now. All technology has risk, new technology and the status quo alike. Companies weigh those risks against the expected benefits. Some folks will obviously avoid the brouhaha completely; it makes sense. Others will decide that the benefits outweigh the risk; there's nothing less comprehensible about that decision.
No, the licenses are not ignored. Both, the GPL and the CDDL require the source available for any copy of the resulting program distributed. In that spirit, there is no license violation. There is some disagreement to which extend linking programs under those licenses is technically possible. But the verdict is still out, whether this is a problem at all. But for the goals both licenses aim for - open source which stay open source, is not violated. This is not a company shipping a closed source executable based on modified sources. They are just shipping precompiled binaries based on available sources.
The comments agree -
http://dtrace.org/blogs/ahl/2016/03/07/big-news-for-zfs-on-l...
http://dtrace.org/blogs/ahl/2016/03/07/big-news-for-zfs-on-l...
> Oracle holds a copyright on most of OpenZFS since it was forked from the original ZFS code base. It would be within their rights to decide to relicense ZFS under the GPL.
Why imply it should convert to GPL? It could become GPL compatible by making the license more permissive.
https://blogs.oracle.com/chandan/entry/copyrights_licenses_a...
"A common misconception is about CDDL and GPL incompatibility. (Incompatibility in the sense: to combine two source files, one under GPL and another under CDDL, to create a common executable.) GPL is incompatible with most licenses like Mozilla Public License, Apache, and CDDL. GPL wants you erase those licenses and use GPL in that place, where as these licenses do not permit erasing them. Hence the incompatibility deadlock."
Why imply it should convert to GPL? It could become GPL compatible by making the license more permissive.
https://blogs.oracle.com/chandan/entry/copyrights_licenses_a...
"A common misconception is about CDDL and GPL incompatibility. (Incompatibility in the sense: to combine two source files, one under GPL and another under CDDL, to create a common executable.) GPL is incompatible with most licenses like Mozilla Public License, Apache, and CDDL. GPL wants you erase those licenses and use GPL in that place, where as these licenses do not permit erasing them. Hence the incompatibility deadlock."
irrelevant politics, but if you aim to be included in the kernel at some point, you must go for GPL or live with "kernel tainted" messages.
which i think is great.
which i think is great.
Which is the core of the argument. ZFS is simply not aimed at being included in the kernel at some point. Linux user's just wish it were so.
What's the situation on btrfs? It was supposed to make ZFS not that big deal anymore on Linux.
There are lot of missing parts. Everything beyond using it for single disks or with RAID1 is still experimental. It's slow for a lot of use cases like VMs or OLTP ( http://blog.pgaddict.com/posts/friends-dont-let-friends-use-...) and using nodatacow does not count!
RAID1 is implemented to use the oddness of the pid to decide which disk to read from... RAID5/6 have huge performance problems in certain use-cases. Write hole is apparently still a thing.
Quota seems to be still broken or difficult to handle, the tooling is not exactly nice or intuitive (this may change in the future).
Hardware failure handling is nonexistent - it can't detect a broken drive.
Lot's of other gotchas. Just read the mailing list. I've been fighting against btrfs for a while and I'm happy when I'm not having to deal with it. Works probably fine for desktop usage but don't bother stressing it - at the moment it will break horrible.
RAID1 is implemented to use the oddness of the pid to decide which disk to read from... RAID5/6 have huge performance problems in certain use-cases. Write hole is apparently still a thing.
Quota seems to be still broken or difficult to handle, the tooling is not exactly nice or intuitive (this may change in the future).
Hardware failure handling is nonexistent - it can't detect a broken drive.
Lot's of other gotchas. Just read the mailing list. I've been fighting against btrfs for a while and I'm happy when I'm not having to deal with it. Works probably fine for desktop usage but don't bother stressing it - at the moment it will break horrible.
Lots of gotchas yes, but it's about as rare to see data loss on Btrfs as it is on say linux-raid@ list for mdadm or LVM and those are much more mature. More often is the case of some suboptimal behavior and the recommendation to get the data off the volume and onto a newly created one. Very inconvenient for some users to be sure, but also not data loss. About the worst I've seen lately that wasn't hardware related needed data scraped using btrfs restore (the tool the extracts data from an unmountable filesystem).
This hasn't been my experience. When an md array has lost a disk, I have added a new one and the array has transparently resynched in the background. No interruption in service or loss of data. When a Btrfs array has lost a disk, Btrfs oopsed the kernel, and stopped working. When I rebooted with the hardware problem resolved, it toasted both the outdated mirror and the up-to-date disk, causing irretrievable dataloss. Any attempt to boot the system led to Btrfs causing an immediate kernel panic. I had to put the disks into a system without Btrfs kernel support and use dd to zero out the Btrfs partitions before I could use them again.
That was admittedly a few years back, but it's still a long way from production use in many respects, while ZFS has been in production use for years and is well documented, has good tools, and is very robust. After several years of Btrfs problems, I gave up on it and moved to ZFS, initially on Linux and then on FreeBSD due to it being better integrated.
That was admittedly a few years back, but it's still a long way from production use in many respects, while ZFS has been in production use for years and is well documented, has good tools, and is very robust. After several years of Btrfs problems, I gave up on it and moved to ZFS, initially on Linux and then on FreeBSD due to it being better integrated.
Just incidentally, 'wipefs -a' should clear out the partitions in a much speedier manner.
Single, raid 0, 1, 10 are stable on stable hardware. Where ZFS is definitely more mature is parity raid. If you need parity raid and a snapshotting Cow filesystem and you're not a tester, then you'd want to pick ZFS. But Btrfs is ~ 6 years behind ZFS maturity wise? Maybe in some sense longer because ZFS had a more aggressive start?
There are definitely things Btrfs can already do that ZFS cannot, like read-writable snapshots, no parent-child dependency (you can create a snapshot and immediately delete the original), growing pools is easier/faster without having to build new arrays or sequentially replace devices and resilver, etc. And just in the last week there's an experimental encryption patch for per subvolume encryption (eventually per file similar to f2fs and ext4), so the situation is heavy development.
There are definitely things Btrfs can already do that ZFS cannot, like read-writable snapshots, no parent-child dependency (you can create a snapshot and immediately delete the original), growing pools is easier/faster without having to build new arrays or sequentially replace devices and resilver, etc. And just in the last week there's an experimental encryption patch for per subvolume encryption (eventually per file similar to f2fs and ext4), so the situation is heavy development.
An often missed feature is the seed device. Any Btrfs volume can be flagged as a read-only seed. Mount it, you can add a 2nd device, and now re-mount. It's a union filesystem like thing. Changes only go to the 2nd device. If you used 'btrfs remove" on the 1st device, data is migrated to the 2nd device and the 1st is removed, so it replicates the filesystem. The seed setting can be applied to multiple device volumes. So you can add this 2nd device, make that volume a read-only seen, and add a 3rd device for read-write, and so on.
Another is Btrfs is quite usable on embedded systems, e.g. 32-bit ARM. I'm curious if anyone would use ZFS in such a case?
I can confirm that btrfs has major problems with tons of snapshots. The entire system will hang for minutes on random intervals and go completely unresponsive for hours when using admin commands. The many snapshots use case is pretty common when dealing with containers, even it everything works fine for simple setups.
How many is tons? I've not had such problems with hundreds of snapshots. There are reports on the btrfs list with problems involving many thousands. I have no idea how ZFS snapshots perform when there are hundreds to thousands.
The other thing that matters a ton is kernel version, the development is so heavy there are thousands of insertions+deletions per kernel cycle that even in a year it's ordinary to consider those kernels "old" on the list. Most distros by default use old kernels by Btrfs development standards. The exception is Fedora, and openSUSE who do lots of backports explicitly to support Btrfs.
The other thing that matters a ton is kernel version, the development is so heavy there are thousands of insertions+deletions per kernel cycle that even in a year it's ordinary to consider those kernels "old" on the list. Most distros by default use old kernels by Btrfs development standards. The exception is Fedora, and openSUSE who do lots of backports explicitly to support Btrfs.
Yeah, I'm talking 10k+, so this is only specific types of applications. In basic benchmarks, ZFS seemed to perform fine well into with 10s of thousands of snapshots. This is still far more snapshots than basic containers will create, so it's really only a problem for situations where you're doing tons of checkpointing.
Yeah I've been using Docker on Btrfs and haven't had issues. I do wonder why it takes so long (maybe 4 seconds) to delete containers, when deleting the snapshot for that container is instant. I haven't found dm based containers to be any faster.
Maybe the application is ignoring the SIGTERM?
https://docs.docker.com/compose/reference/stop/
No I mean when I use 'docker rm' when the container isn't even running.
It would if done, but it's not quite there yet.
Depends on which mailing list you read, the usual consensus I see is it's kinda production ready, though openSUSE has switched to Btrfs as its main file system.
[Disclaimer: I work for SUSE]
SUSE Linux Enterprise also uses btrfs by default. There's also a bunch of features like booting into snapshots and snapper (snapshots taken before zypper transactions and on regular intervals with decaying granularity) which are in both OpenSUSE and SLE.
SUSE Linux Enterprise also uses btrfs by default. There's also a bunch of features like booting into snapshots and snapper (snapshots taken before zypper transactions and on regular intervals with decaying granularity) which are in both OpenSUSE and SLE.
My favorite quote from the piece: "And it is the height of delusion to think that Oracle would grow ears to hear, a heart to care, and a brain to decide." And this is coming from a former Oracle employee.
> Canonical had their lawyers review the licenses and deemed their use of Linux and OpenZFS to be in compliance.
So Canonical, a tiny desktop-focused Linux company, have discovered something that Red Hat's well paid lawyers have missed?
So Canonical, a tiny desktop-focused Linux company, have discovered something that Red Hat's well paid lawyers have missed?
Red Hat have $billions more to lose.
What about Proxmox?
They are a commercial slightly modified Debian distro who have been shipping ZFS with their ISOs and ready to use out of the box, even from the installer wizard for zfs on root installs for around a year now.
Nobody has said anything about them doing this or sued them or tried to stop them.
They are distributing the ZFS on linux binary kernel module pre-instated as Canonical is about to do with Ubuntu.
They are a commercial slightly modified Debian distro who have been shipping ZFS with their ISOs and ready to use out of the box, even from the installer wizard for zfs on root installs for around a year now.
Nobody has said anything about them doing this or sued them or tried to stop them.
They are distributing the ZFS on linux binary kernel module pre-instated as Canonical is about to do with Ubuntu.
Who?
Edit: Oracle seems to have very little reason to do anything for precedent. Canonical is both competition and a largish business, that would be done for the money, suing proxmox would look like being a bully.
Edit: Oracle seems to have very little reason to do anything for precedent. Canonical is both competition and a largish business, that would be done for the money, suing proxmox would look like being a bully.
"Ignore pedants who would deride your pragmatic use of technology as heretical or immoral."
That sounds like bad advice.
That sounds like bad advice.
Why ZFS on Linux when FreeBSD ships with ZFS by default, without any legal quagmires? Also, we need a real open-source, non-GPL competitor to Linux if there's any hope of not being taken hostage by overzealous GPL enforcement by SFC and other GPL right-wingers.
"Lawyerly cosplay" ROFLMAO
And here I was hoping (somewhat) that big news by now would be Oracle relicensing OpenZSF under GPL :))
And there is an appreciable performance difference between using ZFS and BtrFS ?
Massive under certain use cases, and major reliability and feature differences too. A lot of BtrFS is still "in progress" like the copy-on-write stuff and fault detection.
Actually I'm using BtrFS on a few Ubuntu server 14.04 virtual machines. It's very nice when I need to add extra hard disk space, and I only need to add or expand de the virtual hard disk, and indicate to the filesystem to append the extra new space. Also, transparent compression comes very useful, on special when our applications are very dependent on I/O performance and need to store a lot of write single time/read a lot of times data.
I hope this fixes the "read only filesystem" issue.
on by default != default filesystem right?
zsf?
Real useful
Hug of Death on the site as of 1250 CST
Can I have big news on ZFS (or BTRFS) for Windows now? I've heard how awesome this filesystem is, but I still can't use it.
Seems unlikely that either will ever come to windows guess you should check out ReFS or install Linux
https://en.m.wikipedia.org/wiki/ReFS#/search
https://en.m.wikipedia.org/wiki/ReFS#/search
The O3X project lead has joked about porting ZFS to Windows after he finished the Mac OS X port. That is the only discussion of porting it to Windows thus far, although there was one guy who tried reimplementing it as a userspace filesystem on Windows, but that did not get far.
https://github.com/maharmstone/btrfs
This guy is writing a windows driver for Btrfs
This guy is writing a windows driver for Btrfs
ZFS on Linux. No, thank you. I'll continue to use ZFS natively under FreeBSD, which is arguably a far better OS for what ZFS users would be wanting anyway. Been using *BSD since the late 90s. Never a real issue short of HW failure. I cannot say the same for the painful times I was forced to use Linux.
ZFS is indeed a lifesaver, but we in the BSD camps have know this for many moons.
ZFS is indeed a lifesaver, but we in the BSD camps have know this for many moons.
This is a relatively useless contribution to the discussion. Given that there are obviously reasons why Linux has been successful while BSDs have seen less popular usage, it must be the case that Linux or its ecosystem offers features not found elsewhere.
Adding ZFS to Ubuntu is a benefit to everybody, and a smug, holier-than-thou attitude really does nothing to further the conversation about the technology.
Adding ZFS to Ubuntu is a benefit to everybody, and a smug, holier-than-thou attitude really does nothing to further the conversation about the technology.
Nope. Adding a legally licensed copy of ZFS to Ubuntu is a benefit to everybody. Oracle haven't seen fit to do that, and they're the only ones who can.
Sticking a hack-licensing-job into Ubuntu is damaging to the Linux ecosystem, certainly not a benefit.
Sticking a hack-licensing-job into Ubuntu is damaging to the Linux ecosystem, certainly not a benefit.
they're the only ones who can.
This is true, in the same way that it's true that the US could vote in a constitutional amendment to allow a dictatorship.
First, Oracle only has the copyright to the original ZFS code as it existed in 2010 when they stopped working on OpenSolaris.
Second, the AUTHORS[0] file from the 'zfs on linux' project that was imported into ubuntu lists 73 authors not including the Oracle developers, which appear to be both individuals (gmail accounts, etc) and multiple individual businesses (nexenta, ovh, etc). So Oracle cannot naively relicense those 6+ years of contributions, since they have no copyright over that new code. Thus changing the license of the original ZFS code would have no effect because all of the years of contributions since then would still be licensed as CDDL.
Third, Oracle does have exactly one 'option'. The details of the CDDL license specifically state that is 'auto upgrades' if a new version comes out, and an older version is not specifically mentioned. So theoretically, they could release a CDDL license version 1.3 that has radically updated text in order to be GPL compatible. However, since that effects all CDDL licensed code, they would end up relicensing every bit of CDDL code (related to Oracle or not) in the entire world. Is that something that Oracle should reasonable be expected to do? I think this is as likely, and as reasonable, as GPL v4 coming out with the text of the MIT license, thus affecting any GPL code in the world that says 'or any later version'. In other words, it's just not reasonable to use this 'one weird trick'.
So there is no remotely reasonable way in which Oracle can have an effect on this issue.
[0] - http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/diff/z...
This is true, in the same way that it's true that the US could vote in a constitutional amendment to allow a dictatorship.
First, Oracle only has the copyright to the original ZFS code as it existed in 2010 when they stopped working on OpenSolaris.
Second, the AUTHORS[0] file from the 'zfs on linux' project that was imported into ubuntu lists 73 authors not including the Oracle developers, which appear to be both individuals (gmail accounts, etc) and multiple individual businesses (nexenta, ovh, etc). So Oracle cannot naively relicense those 6+ years of contributions, since they have no copyright over that new code. Thus changing the license of the original ZFS code would have no effect because all of the years of contributions since then would still be licensed as CDDL.
Third, Oracle does have exactly one 'option'. The details of the CDDL license specifically state that is 'auto upgrades' if a new version comes out, and an older version is not specifically mentioned. So theoretically, they could release a CDDL license version 1.3 that has radically updated text in order to be GPL compatible. However, since that effects all CDDL licensed code, they would end up relicensing every bit of CDDL code (related to Oracle or not) in the entire world. Is that something that Oracle should reasonable be expected to do? I think this is as likely, and as reasonable, as GPL v4 coming out with the text of the MIT license, thus affecting any GPL code in the world that says 'or any later version'. In other words, it's just not reasonable to use this 'one weird trick'.
So there is no remotely reasonable way in which Oracle can have an effect on this issue.
[0] - http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/diff/z...
> So theoretically, they could release a CDDL license version 1.3 that has radically updated text in order to be GPL compatible. However, since that effects all CDDL licensed code, they would end up relicensing every bit of CDDL code (related to Oracle or not) in the entire world.
Though of course since laws are made by lawyers and not nerds, the new license may well be invalid and nothing would change at all except for lots of confusion.
Which makes you even more right.
Though of course since laws are made by lawyers and not nerds, the new license may well be invalid and nothing would change at all except for lots of confusion.
Which makes you even more right.
Note that regardless of lawyers vs nerds, the CDDL is quite clear about what happens if a new version of the CDDL is released.
Note that these two combined (regardless of lawyer or nerd) give a compelling case that it's plausible that Oracle could take that action. They won't, and I don't think they should, and I find it hard to see that it as remotely reasonable that they should be pressured to. However, if they did, then it's likely that it would be legal since each other CDDL contributor accepted the license, and relicensed their own code with the same possibility.
Obviously some lawyer would make the case that it's not a new version since it has drastically different text, but at that point we're well into moot, counterfactual realms.
4.1. New Versions.
Sun Microsystems, Inc. is the initial license steward and may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. Except as provided in Section 4.3, no one other than the license steward has the right to modify this License."
4.2. Effect of New Versions.
You may always continue to use, distribute or otherwise make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. If the Initial Developer includes a notice in the Original Software prohibiting it from being distributed or otherwise made available under any subsequent version of the License, You must distribute and make the Covered Software available under the terms of the version of the License under which You originally received the Covered Software. Otherwise, You may also choose to use, distribute or otherwise make the Covered Software available under the terms of any subsequent version of the License published by the license steward.
Note that these two combined (regardless of lawyer or nerd) give a compelling case that it's plausible that Oracle could take that action. They won't, and I don't think they should, and I find it hard to see that it as remotely reasonable that they should be pressured to. However, if they did, then it's likely that it would be legal since each other CDDL contributor accepted the license, and relicensed their own code with the same possibility.
Obviously some lawyer would make the case that it's not a new version since it has drastically different text, but at that point we're well into moot, counterfactual realms.
> Obviously some lawyer would make the case that it's not a new version since it has drastically different text,
That's exactly what I meant with lawyers<->nerds: publishing a radically different version is a nice hack, but may not hold up legally.
> but at that point we're well into moot, counterfactual realms.
That's what I meant with confusion. If the legal situation isn't entirely clear, the kernel team, distros and related companies might very well decide to play it safe.
That's exactly what I meant with lawyers<->nerds: publishing a radically different version is a nice hack, but may not hold up legally.
> but at that point we're well into moot, counterfactual realms.
That's what I meant with confusion. If the legal situation isn't entirely clear, the kernel team, distros and related companies might very well decide to play it safe.
I guess Oracle owns CDDL license stewardship now. It would be really interesting if they released CDDL-2.0 that just lets you relicense things under the GPL. The might do that, after all, execs from their predecessor, Sun, liked the GPL. Also they put Berkely DB under the AGPL.
I do not think it is a benefit to everybody. In fact, I think it will tarnish ZFS as a technology.
ZOL still has some very clunky usability integrations (zpool status vs spare, sudo requirements, device name instabilities etc). I'm running ZOL on production servers, and sometimes it feels like back in the day when I tried to get the first ZFS patchsets against FreeBSD7 to run on my P3 with 1.5GB RAM. Sometimes worse.
The majority of Ubuntu users will not attribute these deficiencies to the ZOL port, but to "ZFS". We will see a lot of "So $XYZ has ZFS, well, I have tried it on Ubuntu and it s".
ZOL still has some very clunky usability integrations (zpool status vs spare, sudo requirements, device name instabilities etc). I'm running ZOL on production servers, and sometimes it feels like back in the day when I tried to get the first ZFS patchsets against FreeBSD7 to run on my P3 with 1.5GB RAM. Sometimes worse.
The majority of Ubuntu users will not attribute these deficiencies to the ZOL port, but to "ZFS". We will see a lot of "So $XYZ has ZFS, well, I have tried it on Ubuntu and it s".
Do you commonly find content-free insults to be an effective form of advocacy? I've used (Free|Open)BSD over the same time period and can point to specific areas which were better (e.g. NFS client stability) or worse (e.g. package management, video drivers) compared to Linux, and both would need to be mentioned in the context of specific versions. If you want to do anything more than make people dislike BSD fanboys, try stating something specific and be prepared to back your assertions up with evidence.
Not a fanboy, thank you, just a happy IT pro. We use and prefer BSD and attendant software because we prefer the BSD/CDDL(ZFS)/MIT and similar licenses. The GPL is off-putting for what we do, so we avoid using Linux or other GPL'd software where equivalent BSD (or similar)-licensed software is extant.
So that's great as a concrete reason for why you choose to do this — doesn't it seem far more useful as a thing to talk about than the vagaries of “a far better OS for what ZFS users would be wanting anyway” or the unspecified “painful times I was forced to use Linux”?
https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
I also fear about what Oracle could do, as they are copyright holders of parts of Linux (btrfs) and might decide to make things difficult for Canonical. Oracle has misused copyleft aggressively in the past, trying to strong-arm people into buying GPL exceptions for MySQL when they didn't need one, although in this case, they probably do have a good case for why a GPL exception would be necessary.