I know it seem silly to care about licensing in this case, since it's about GPL incompatibility between two free licenses. However, the problem here is the precedent that it sets. If ZFS distributed this way, in binary form linked to Linux, does not infringe Linux's copyleft, then this could open the doors for other kinds of proprietary blobs to grow on top of Linux. That is SFC's analysis,
Indeed, Conservancy believes this situation is one
battle in a larger proxy war by those who seek to
limit the scope of strong copyleft generally.
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.
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?
"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."
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.
> 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:
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.
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.
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?
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.
I don't see how this is a relevant comparison in this context beyond
the trivial "Debian has had some packages built from source at install
time in the past".
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.
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.
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.
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.
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".
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.
$ yaourt -S zfs-git
Here is the source for the build script for the zfs-git package:
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.
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.
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...
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.
> 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 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.
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.
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.
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.