ZFS isn’t in the kernel because of licensing concerns. I’m wondering how the ZFS release cycle would jive with kernel dev cycles. On the plus side, ZFS is stable, and the ZFS devs don’t strike me as the kind of people who would send features in an RC3 and then tell Linus to shove it when he says “this is not the Linux way”.
Will ZFS licensing ever become compatible with Linux? I’m not holding my breath.
Closing question: Do you think ZFS being out-of-kernel is, on balance, great or holds it back? What are pros and cons to being in-kernel vs out-of-kernel?
If ZFS stayed outside of kernel for so long so can bcachefs. At least until it matures enough. Or maybe until its developer matures enough?
As for ZFS, its in Oracle hands.
From there, Torvalds branches out into license concerns, another topic on which he’s accurate and reasonable. “Honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle,” he writes. “Other people think it can be OK to merge ZFS code into the kernel and that the module interface makes it OK, and that’s their decision. But considering Oracle’s litigious nature, and the questions over licensing, there’s no way I can feel safe in ever doing so.” Linus Torvalds says “Don’t use ZFS”—but doesn’t seem to understand it - Ars Technica
I personally dont understand why Oracle didnt do something about it yet.
Oracle develops and uses ZFS inside Oracle Solaris, which is proprietary OS.
But they also develop Oracle Linux which cant use ZFS until they do something about the licensing. So why Oracle doesnt offer their own ZFS filesystem in their own Oracle Linux operating system? Doesnt make sense to me.
But I also saw statement from Jim Wright, Oracle’s Chief Architect Open Source Policy that CDDL and GPL are actually compatible Reddit - The heart of the internet
So I really dont know.
But if Oracle allows company like iX to offer commercial product with combined ZFS and Linux kernel and doesnt sue them, then maybe its actually OK and Linus is just too cautious?
Product differentiation? Leaving aside that OpenZFS is not Oracle ZFS; the two diverged many years ago.
But if Linus’ concerns were valid, I think Oracle would have taken some action against Ubuntu or Proxmox by now. And as much as I tend to agree with its principles, GPL is pretty much a religion any more, so you definitely couldn’t incorporate work covered by anything other than the One True License.
I think GPL is one of the reasons why Linux is monolithic kernel.
If its in userspace it can be any license. MIT, proprietary, doesnt matter. Linux devs dont like that. But in kernel its only GPL. So obviously Linux devs put anything they can into kernel so more things are GPL.
For example filesystems. FS in userspace can be any license, but its very restrictive because Linux is monolithic and expects things like filesystems to be in kernel.
This forces filesystem developers into GPL and anything in userspace with different license cant compete.
If Linux were microkernel for example like Redox OS then filesystems could live fully in userspace without limitations and could have any license.
Putting in ZFS wouldnt be any problem.
I’m pretty sure I’ve seen emails, posts, and/or other communications from at least some of the ZFS devs saying they’re fine with it being userspace, and in fact they prefer it–that way (among no doubt other reasons) they aren’t locked into the kernel’s release cycle.
I think it is great, and for an actively developed file system, a much better choice.
The only real pro is that new Linux kernel releases more or less need to make sure that any kernel module code compiles. This also more or less implies that the kernel developers that make interface changes need to fix any kernel module that uses the prior kernel interface standard.
If OpenZFS were stable, and few changes being implemented, then it would be a pro to be included into the kernel source tree. However, because OpenZFS supports multiple OSes, Linux, FreeBSD, Illumos, MacOS & now MS-Windows, it is likely that the Linux kernel people would consider multi-OS file system code a problem. Then either want to remove the multi-OS code, or simply ban the file system from the kernel source tree.
Looking back, I think keeping OpenZFS out of the kernel is both appropriate and the best thing. Partly because of the multi-OS support and partly because this de-couples OpenZFS releases from Linux kernel releases. This means you can be running an older Linux kernel and yet have more recent OpenZFS.
Of course, at some point OpenZFS will deprecate older Linux kernels. Probably the same for FreeBSD.
As for BCacheFS being removed from the Linux kernel source tree, good. While I wish BCacheFS well and it would be nice to have more file system options, heavily changed code simply does not belong in the Linux kernel source tree. The exception to that, is if you have a version 1 of something that is stable. Then later want to introduce version 2, (like EXT2/3/4…), that can work by having the new version experimental until stable.
