Clearly ZFS is open source, Linux would profit by including it, but both ZFS and Linux have licenses that are, at this point, impossible to change for various reasons.
It seems that the people opposing this move by Ubuntu claim that by linking against the VFS stuff in Linux, that particular ZFS distribution becomes a derivative of Linux (weak claim IMO but argiuable) and therefore must be GPL'd. But it can't be. And we (or I at least) would like to see ZFS on Linux become easier.
I wonder if some brave soul could make a new, completely superfluous layer of glue on top of ZFS that's both GPL and CDDL? And then could link that glue to linux/vfs while leaving ZFS itself in a completely underived state? Would that satisfy people?
Ultimately we're talking about open source code with nice engineering, here. I think the whole computing community could benefit from a solution.
Sidenote: I wonder how many people here who claim copyright of an API (vfs) prohibits this integration felt the exact opposite way when it was Oracle v Google.
Imagine you have a small GPL program, that all it does is to load plugins, e.g. with dlopen and invokes some function, let's call it "main".
It clearly doesn't care what license the binary loaded that way has.
What i does is to load a binary in memory, locate an address and transfer control to it. If the GPL didn't allow this kind of thing to happen, then the GPL linux kernel couldn't possibly load any proprietary program.
Now, let's allow those "plugins" to do something more interesting: request some action by the plugin host. The "main" function receives a function pointer that serves as an entry point for "system calls". Again, it's perfectly legal to invoke such a function, regardless of whether you can see this as "dynamic linking", you can also see this as "providing an operating system system call".
If you're not convinced, let's call this "plugin host" an novel operating deepcloudstrumpfkernel operating system.
Now, this is a pretty hard to use interface. You probably want a library linked to your "plugin"/"program" that provides a more natural interface on top of this basic "syscall" interface. This library and it's headers will contain functions, constants etc.
This library doesn't have to be licensed with GPL; any license compatible with your "plugin" will do. Let's make it CDDL (or MIT).
Now, it would be very useful that this library, or parts of it (e.g. constant definitions), is shared with the "plugin host" a.k.a deepcloudstrumpfkernel; No problem again, whoever owns the copyright for this library can release it with both MIT and GPL license.
You can use the same trick to implement a loadable kernel module that doesn't violate the GPL. However there is a lot of work.
In order to properly abide by the GPL rules, you must be able to build a fully working kernel module without touching any line of GPL code (except header files and library objects provided by the compiler and your OS "primary interface").
This last part is what is tricky. If you want to create a kernel module, you need to include some helpers. If linux had a stable "driver API", somebody else could write a library that helps you build a compliant kernel module, but in order to be more agile, IIRC the linux kernel module subsystem is designed to be source compatible and not binary compatible between releases and the layer exposes a lot of linux internals, which are part of the kernel and it would be very hard to duplicate all this without being caught in a copy paste.
jbooth's suggestion was to write such a dummy layer that bridges the linux VFS interface with something else; thus not requiring the kernel module to use the internal linux API. However there is more to it than the VFS API: you also need the bare minimum to make your kernel module actually loadable by the kernel not depend on any GPL library that helps you adhere to that ABI.
Disclaimer: IANAL
The GPLv2 license governs the distribution of software licensed with said license. It forces anyone who distributes a GPL binary to also distribute the source code used to build that binary.
If in order to build that particular binary you had to include some other code, then you have to provide the sources for that code as well. Furthermore, that code you provide must be distributed in turn under the GPL license. Any such "added code" becomes part of the thing you distribute and thus constitutes "derivative work".
The key thing here is that it doesn't matter if the "added code" is just some bit of extra functionality of if it's the "whole thing" while the GPL code is just one header. When you build a kernel module, you have use some GPLd headers at the very least.
This last point technically taints a binary kernel module and forces you to release all the sources used to build it and release those sources as GPL.
However there are two interesting points here:
1. Distribution
Notice how the license only mentions distribution. You are allowed to do whatever you want with a GPL source that you hold on your hands: you can change it, add some code, link it with other code. There is absolutely nothing forcing you to immediately release your derivate work to the public and thus nothing forcing you to release the sources of your derivate work.
This means, that if you build a kernel module on your machine, from a mixture of sources with GPL and an other licence; you didn't violate the GPL (whether you violated the other license, it depends on that other license).
Please read very informative:
http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue
TL;DR: ^^^ In the case of the kernel, this prevents us from distributing ZFS as part of the kernel binary. However, there is nothing in either license that prevents distributing it in the form of a binary module or in the form of source code.
2. Exemptions
http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
This has a much less clear interpretation in the context of kernel modules. This clause is mainly intended to allow you to use GPL software on a proprietary operating systems as well as running proprietary software on GPL operating systems. You can compile it: which means you can include headers provided by the compiler and OS. And you can run it: which means you can invoke system calls and/or link it with possibly proprietary libraries that make up the main interface.I have no idea whether in the context of a kernel module, the kernel internal API can fall under this category, given that it's arguable that it doesn't make up the "main interface" of the linux OS.
----
How does this relate to the article from canonical ?
They are claiming something entirely different. They claim that the ZFS kernel module is "evidently" not a derivate work on the grounds that it's self contained and they cite existing exemptions for other binary drivers such as those by nvidia.
They don't explicitly mention the exemption on the aforementioned point in the GPLv2 license text.
Thus, it's not clear how this will affect the observation of the GPL license and whether it will set a precedent at least for all cases where one can argue that the binary blob is linked against an well define interface that is meant to provide an "execution environment". (e.g. plugins, kernel modules, binaries running inside an OS). Not sure if setting this precedent will eventually erode the general case of linking though.
The line is thin, but I would have preferred some more explicit reasoning instead of "we have concluded that we are acting within the rights " and "is clearly not a derivative work", and finishing with a "As we have already reached the conclusion, we are not interested in debating license compatibility".