> It's also crazy, nearly no distro has a problem shipping ultra-proprietary software (firmware), but has a big discussion about CDDL,
It's the difference between "mere aggregation" and "derived work". The kernel+ZFS can be considered a derived work from both, so it has to obey both licenses (GPL2 and CDDL) at the same time; on the other hand, the firmware is completely independent from the kernel, so the licenses (GPL2 and the proprietary license) apply separately to each component.
> Ubuntu has no problems with it...and i bet they have lawyers
On the other hand, Fedora has problems with it as a kernel module (but they do ship it as a ZFS FUSE module, see https://fedoraproject.org/wiki/ZFS), and they do have lawyers (Red Hat's lawyers review all the licenses for Fedora, and they consider the CDDL to be incompatible with the GPL: https://fedoraproject.org/wiki/Licensing:Main).
>You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice, which may contain terms different from this License, provided that You are in compliance with the terms of this License and that the license for the Executable form does not attempt to limit or alter the recipients rights in the Source Code form from the rights set forth in this License.
>To reiterate, executable forms of CDDL source code can be under ANY license you want.
That means your compiled ZFS module package can even be under GPL2 or 3 or beerware ;)
> no one of those project is derived from each other, ZFS is a module (on all platforms i think)
Once compiled, the ZFS module is a derived work from both the Linux kernel and ZFS.
> > You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice [...] does not attempt to limit or alter the recipients rights in the Source Code form from the rights set forth in this License.
> That means your compiled ZFS module package can even be under GPL2 or 3 or beerware
I trust the Red Hat lawyers on this matter more than someone who is not a lawyer (from that page: "While it's true that I am not a lawyer [...]"). And from what I understand (I'm also not a lawyer), that clause in the CDDL applies only to the compiled result; but the GPL requires that, if the compiled result is distributed as GPL, the corresponding source code also be available under the GPL. So you cannot distribute your compiled ZFS module package under GPL2 unless the corresponding source code can also be distributed under GPL2.
I have always been skeptical of the FSF dogma that dynamic linking of a module or shared library into a GPL program's address space propagates the GPL into that module. The choice of inter-module communication technique (dynamic linking, sockets, etc.) shouldn't have any bearing on licensing. Either components are independent or they're not. There's nothing magic that happens when you take an API that's intra-process and run it over a socket instead. If FUSE filesystems don't carry the GPL tag, neither should in-kernel modules logically decoupled from the kernel core.
You are right that the choice of inter-module communication technique does not have a bearing on the licensing unless the license explicit say so.
To be fair to FSF however, they have to my knowledge never actually said anything else. What they do say is that they will enforce the license at that distinction, a conclusion RMS arrived at many years ago when apple tried to make proprietary addons to GCC. The reasoning, as provided by a consulted lawyer Eben Moglen at the time, was that a judge would likely see it as creating a single derivative work out of the linked parts, and as such you need a copyright license. This story has been mention in a few talks because so far no one has yet to challenge FSF in court and prove it wrong, which is a fight that at least Eben Moglen have been all this years willing (and possible wanted) to take up if given the opportunity.
As a bright line in the sand the concept has served FSF well, but it is not a supreme court decision that defines what a derivative work is under software. It could be that the line should be drawn much more narrower, but personally my bet is the opposite. Courts are rarely on the side that want to abolish copyright control or limit its scope.
To make compiled ZFS module a derived work of Linux and ZFS, it would need to contain (ie include) parts of Linux source code, which is easily avoidable with a shim layer.
>Once compiled, the ZFS module is a derived work from both the Linux kernel and ZFS.
Really? So if i compile something with gcc it is a derived work from gcc and gcc is derived work from my bin? Or when i make a firefox extension it's a derived work of firefox? Compile the nvidia module...a derived work from linux?
>I trust the Red Hat lawyers on this matter more than someone who is not a lawyer
But he can read :) but hey whatever, really not interested if linux has something good like DTrace ZFS or Crossbow, they like the NIH-Syndrome and i am ok with that too.
> So if i compile something with gcc it is a derived work from gcc
Yes. This is why the "libgcc exception" (https://www.gnu.org/licenses/gcc-exception-3.1.en.html) exists. The issue is that parts of runtime libraries which come with gcc are statically linked into the compiled executable; without that exception, the result would have to be under the GPL.
The same issue happens with Linux kernel modules. Many functions they need are only defined as macros or inline functions in the headers (since ZFS is a filesystem, just take a look at how many inline functions there are in include/linux/fs.h). And even outside of these, many functions are so closely coupled to the internal data structures of the kernel (and the data structures themselves are also exposed to modules) that any module using them could be considered a derived work of the kernel.
Are data structures copyrightable? The headers are not, and macros can be easily avoided.
And in any case, there's an easy way to prove something does not constitute a derived work: just show that it can work outside of the codebase it's allegedly a derived work of. The reason NVidia is safe is that they provide the same driver for FreeBSD.
Criteria for whether a work is copyrighted are a bit more nuanced and the word “header” doesn’t figure in it. A work needs to be original and have creativity element in it. Code in header files can - and very often does - meet that requirement. Some kind of code (whether in headers or elsewhere) can be unoriginal, but that really has nothing to do with “headers”.
In Nvidia’s case, they have an open-source shim layer in between the kernel and the closed-source bulk of the driver. In theory, the shim layer is a derived work of the kernel, but the closed-source part is not. I’d say that’s a bit of a dubious argument, but who knows? It’s never gone to court. Search for “GPL condom”.
So, ZFS would be in the exact same situation as the NVidia driver - shim layer would be derived work, and the CDDL code wouldn't. It is dubious, sure, but then the whole idea of GPL virality is.
It's the difference between "mere aggregation" and "derived work". The kernel+ZFS can be considered a derived work from both, so it has to obey both licenses (GPL2 and CDDL) at the same time; on the other hand, the firmware is completely independent from the kernel, so the licenses (GPL2 and the proprietary license) apply separately to each component.
> Ubuntu has no problems with it...and i bet they have lawyers
On the other hand, Fedora has problems with it as a kernel module (but they do ship it as a ZFS FUSE module, see https://fedoraproject.org/wiki/ZFS), and they do have lawyers (Red Hat's lawyers review all the licenses for Fedora, and they consider the CDDL to be incompatible with the GPL: https://fedoraproject.org/wiki/Licensing:Main).