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.

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.

> modules in the base install, which is important for things like installing on ZFS root

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

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

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.

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

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

Are you serious? You're not serious.

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.

   $ yaourt -S zfs-git

Here is the source for the build script for the zfs-git package:

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/

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.

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

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.

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.