Hacker News new | ask | show | jobs
by temprature 3040 days ago
Actual lawyers have also read both licenses and came to the conclusion that they are incompatible: https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

The main debate over the incompatibility isn't about GPL vs CDDL; even Canonical isn't arguing that the licenses aren't incompatible. It's specifically about the Linux kernel vs ZFS; ie. does linking the ZFS module with the Linux kernel make the ZFS module a derivative work of the Linux kernel.

If yes, it has to be able to have the GPLv2 applied to it, which it can't. If no, then the incompatibility is irrelevant, and the kernel and ZFS can be distributed together and under their own separate licences. This is where opinions (by legal experts, not people on the internet) differ, the FSF and SFC's lawyers say this makes ZFS a derivative work and you can't distribute them together, Canonical's lawyers say it doesn't and therefore you can.

2 comments

The crux of the Software Freedom Conservancy argument hinges on their belief that there is no distinction between a statically and a dynamically compiled Linux module. Modules are, of course, a programming term referring to concerns that are separated into logically discrete functions (modules), while interacting through well-defined interfaces.

The Software Freedom Conservancy argues that not only is zfs.ko a derived work of Linux, but really any dynamically loaded Linux kernel module is a derived work (of Linux). To me that feels like a bit of a stretch, and one could make the opposite argument.

By virtue of the fact that zfs.ko is an optional module, rather than an integral part of Linux, it's not a derived work. ZFS.ko MUST be a separate entity from Linux in the first place; SINCE zfs.ko is a module, it MUST be logically discrete, while interacting with Linux through the standard, normal kernel interfaces. Further, it's likely that only if ZFS were distributed as a changeset against the Linux source code (rather than buildable as a distinct module) would it possibly be a derived work of Linux.

The statically vs. dynamically compiled (linking) distinction doesn't hold water as it is an arbitrary technical one that only has to do with how things are layed out on the filesytem and/or loaded into memory, since modules, plugins, add-ons, and similar things almost often can be either statically compiled in or dynamically loaded, of which there are many examples of in many existing software.

I'm surprised there isn't a one-click way for the user to build their own kernel with ZFS inside it.

As long as I don't distribute the resulting binary there should be no legal implications.

There is (at least on Debian) - enable contrib and use apt.

The problem is that neither your install or recover CD won't have it enabled by default, so if you have a problem, your hard-drive won't mount.

So extend the script to build you a recovery ISO or USB image too, and then insist that you reboot and test the recovery image.
For those interested, it appears the current generation of "running system to live image" is:

https://github.com/Tomas-M/linux-live

While the current generation of "make me a magic shiny debian image" is:

https://github.com/larswirzenius/vmdb2/

(I went looking for some tool I've used in the past, which may, or may not, have been "live-build").

In general though, just pulling down a dkms zfs module into any working recovery image via apt should work.

But not if you don't have net access [ed: or a lan apt mirror..].

Or install ZFS from your live recovery instance and load the mod. Not a big problem.
DigitalOcean[1] has a one–click option to compile FreeBSD kernel with ZFS configured (for what its worth).

edit: including my referral link here will probably result in negative karma, but i'm desperate for points!

[1]: https://m.do.co/c/8c882a721944

FreeBSD isnt GPL licensed but BSD and therfor has no licensing issues.
FreeBSD supports ZFS by default. FreeBSD is not the problem.
Freebsd already has ZFS enabled by default?