There's no contradiction here. FreeBSD was never the primary contributor to (Open)ZFS (it was an Illumos thing), but we had the resources to make it a first class citizen on FreeBSD at a time when Linux wasn't doing that (mostly for licensing reasons).
It seems like the Linux world has gotten over the licensing problem one way or another, and at the end of the day Linux has something like 100x-1000x more developers to bring to bear at the problem. So between that, and illumos' imminent death, ZoL is the active upstream. FreeBSD is happy to benefit from the ZFS improvements in ZoL, especially given the collaborative spirit we've seen from the ZoL team so far. If anything, kudos to the ZoL folks for the huge amount of effort they've put in over the last handful of years.
Rumours of our death are, of course, greatly exaggerated.
If I understand correctly, the developers were saying there are specific parts of Linux where anything using them is considered a derivative work, and therefore even distributing source would be a violation of GPL. An instance of this is the crypto layer that was added in recently with the native dataset encryption. SPL actually reimplements this logic because the ZoL maintainers claim they can't use the Linux crypto subsystem without violating GPL.
I believe that comment by Matt/Kip reflects more of a personal opinion about how things should be (he's a stalwart FreeBSD contributor), rather than how they actually are in practice.
They continue to port code to Illumos (i.e. KVM, continued work on Pluribus port of bhyve, etc.).
SmartOS is what their data centre orchestration solution gets built on-top of.
You can see their changelog for SmartOS they are quite active: https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/s...
Development of SmartOS and Triton Datacentre occur under their joyent organisation on GitHub.
On the flip side, I'm glad I saw this when I did. I really don't want to have to know all about ZFS tooling, and hoping that they get the UI/UX in place for a clean NAS experience, and may just buy a prebuilt from iX later next year.
guess I have some additionally learning to do :-)
That can still be somewhat true due to the licensing mess. ZoL will never be in the tree for linux. The best you can hope for is the Canonical solution which at least ensures a supported version for the distro kernel.
My theory on how this might happen is an independent implementation of BtrFS that extends from ZFS code, sharing it whenever possible.
Should such a thing emerge and surpass current BtrFS, what else could Oracle do but throw in the towel?
From my understanding both Linus and ZoL team prefer to be separate.
But it's unlikely they'll do it. In recent years they've relicensed-under-GPL some things (like the DTrace userspace utilities) but I have doubts they'd ever do it for something like ZFS.
I sincerely doubt that. If Oracle would relicense/dual license ZFS as GPLv2 compatible then I feel convinced that the ZoL contributors would happily do so as well.
I can't think of a single reason why they would not want to be in mainline Linux, and I have seen nothing indicating that the Linux kernel devs would be anything but happy to have it 'mainlined' as it would only make Linux better.
Of course this all hinges on Oracle, which makes it extremely unlikely in my opinion.
From my personal look, there could be significant mess due to attempts to "remove duplication" or similar moves to make the code more linux-like. While ZFS is not the rampant layering violation some people accused it of, there's significant amount of code there (and funnily enough, there's actually overlap with some less-known linux features)
Yes, all the parties that contributed code would have to agree, not just Oracle. However, I doubt anyone would object relicensing ZFS to some license that both FreeBSD and Linux would find acceptable.
A bit of a leap - while your theory could be correct, alternatively, if the filesystem is complicated and can be ifdefed to work for many OS's, it makes sense to combine dev efforts into one codebase rather than having multiple independently maintained forks..
not sure which is the case here.. but in any event.
So, basically, Delphix was a (the only?) commercial user of Illumos and now they're abandoning it for Linux, which means Illumos will starve for manpower going forward?
It also sounds like FreeBSD also lacks the resources to maintain an implementation of something like ZFS, which is ironic since not too long ago it seemed like one of the marquee features they had that Linux didn't.