But we believe the way to get around this issue is to build ZFS as a module with a CDDL license, it can still be loaded in the Linux kernel. Though it would be restricted to use the non- GPL symbols, but as long as that rule is adhered to there is no problem of legal issues.
I can't believe it really is that simple ? If so, why hasn't anyone mentioned this before ?
It's not really that clear cut. According to Linus, as long as they aren't writing a derivative work and they only use the public kernel interfaces then it's all good. That view isn't held by all of the contributors however.
The only people who would have standing to take any legal action however, probably aren't really going to care enough about it. If a Linux distribution decides to include it, I imagine a few high profile people will write angry blog posts, but that's about it.
One of the authors of DTrace explained the CDDL/Linux issue two years back so it's not surprising. http://blogs.sun.com/ahl/entry/what_if_machine_dtrace_port But you have to consider the politics of the situation: no Linux vendor will ship this code so very few people will take the effort to download and install it.
It's been taken up by a new maintainer, and works remarkably well (though I'm not sure I'd trust 'real' data to it). I've run it on a media server at home for the better part of a year, across hardware upgrades and linux installs, and so far, so good.
Indeed, there won't be any inclusion into the mainline tree unless Sun re/dual-licenses it to be GPL compatible. I'm just surprised that it's so far been FUSE-only, given that the non-GPL kernel module API exists. I guess it'll require distribution support for it to be practical, as compiling kernel modules to survive updates isn't exactly for the faint of heart.
> compiling kernel modules to survive updates isn't exactly for the faint of heart.
Nvidia's been doing fine so far. I know that distributions theoretically support them, but everyone I know uses envy-ng for some reason (new hardware support, problems with resolution, etc.) So even if the distribution is lagging behind, a good update script that is needed only during a system upgrade isn't that ugly... Especially if ZFS will be used by proper admins that will choose it based on what they really need.
Yep, but Nvidia has the necessary staff at hand. The situation for out-of-mainline modules is certainly getting better (thanks to symbol tables, etc.) but I still get that sinking feeling if I have to compile a kernel module.
I've had good experiences of using DKMS under Debian for 3rd-party proprietary driver modules that recompiles as necessary when updating to a new kernel.
Wait a minute, hasn't ZFS already been ported to FreeBSD? Why can't Linux just take the FreeBSD version, which I presume is BSD licensed? Ditto for stuff like D-Trace. Or does FreeBSD actually allow inclusion of non-BSD-licensed code?
FreeBSD does allow for the inclusion of other licenses. The GPL 2 and CDDL are two prominent examples (though they are actively trying to remove as much GPL code from the tree as possible). Users who are unhappy with CDDL licensed code still have the option of disabling it in FreeBSD's build.
We understand that we can distribute ZFS binary under a non GPL license, as long as it does not use GPL symbols.
Our plan regarding ZFS is to first port it to Linux kernel and then make its binary distributions available for various different distributions of Linux. These binary distribution will be in form of loadable kernel modules and commands.
Once we get ready with ZFS port then we will start sharing our plans for its binary distributions.
Feel free to contact us if anyone is interested in ZFS port on specific linux distribution.
I can't believe it really is that simple ? If so, why hasn't anyone mentioned this before ?