[1] http://blog.hansenpartnership.com/are-gplv2-and-cddl-incompa...
"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."
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 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.
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.
However, there are other, valid examples like Linksys routers shipping with binary drivers for Broadcom NICs.
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.
> 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.
Ah yes, the bootstrapping problem.
We can bootstrap much more difficult things. For example booting from kernel source: http://www.bellard.org/tcc/tccboot.html
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.
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.
I will have a good laugh if Ubuntu is porting it over as a "headline feature".
OpenSolaris had that as part of its Gnome file manager. It's even open source.
Are you?
What?
$ yaourt -S zfs-git
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=zfs-g...
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 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.
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.
"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.
As Oracle has contributed to the Linux kernel as well, they are in a position to sue over GPL violation.
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.
But it's not a binary blob - the source code is supplied with the binary.
Isn't that good?
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.