You can check the status of each feature here: https://btrfs.wiki.kernel.org/index.php/Status
None of the options are marked experimental. (Specific features are marked unstable on the status page)
"Under heavy development" does not mean anything about stability. The kernel itself is under heavy development. ZoL is under heavy development. The disk format is stable, which is what matters.
SUSE provides commercial support for btrfs and uses it as the default. That's pretty much as non-experimental as is gets.
Update - also it appears Suse enterprise uses btrfs for the root os filesystem but xfs for everything else including by default /home. To me, this seems telling? If it’s so solid why not use it for /home?
The legal position is that ZFS is open source under a copyleft license but that many people think that it's illegal to bundle it with the Linux kernel because of some (I think unintended) incompatibilities between its license and the Linux kernel's license. Canonical (and some others) disagree, and think that it's legal. It's only the bundling that's at issue - everyone agrees that it's legal to use with Linux once you have both.
See https://ubuntu.com/blog/zfs-licensing-and-linux for Canonical's opinion.
Here is some more info on the subject: https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
Nope. Simon Phipps, Sun's Chief Open Source Officer at the time, and the boss of Danese Cooper—who is the source of the claims it was intended—has stated it was not:
* https://en.wikipedia.org/wiki/Common_Development_and_Distrib...
Brian Cantrill, the co-author of Dtrace, has also stated that that they were expecting the Linux folks to potentially incorporate their work:
* https://old.reddit.com/r/IAmA/comments/31ny87#cq3bs9z
Do you have any citations that can corroborate the/your claim that incompatibility was intended?
> Here is some more info on the subject:
See also:
* https://softwarefreedom.org/resources/2016/linux-kernel-cddl...
I think there's also a general suspicion that Sun could have just chosen the GPL if they cared about compatibility. Although, for various reasons, it's probably at least somewhat more complicated than that because of patent protection, etc.
There were 'technical' reasons why they did go not with GPL, and specifically GPLv2 (GPLv3 was not out yet). IIRC, they did consider waiting for GPLv3, but it was unknown when it would be out, and one thing they desired was a patent grant, which v2 does not have.
Another condition was that they wanted a file-based copyright rather than a work-based copyright (i.e., applies to any individual files of ZFS as opposed to "ZFS" in aggregate).
That's a very loaded statement. I've seen it said quite a lot over the years. But, have you thought about its implications?
The implicit assumption here is the primacy of the GPL over all other open source licences. Why should other companies and organisations treat it as "more special" than any other free/open source licence when it comes down to interoperability?
When it comes down to compatibility, the GPL is one of the last licences you should choose. Because by its very nature it is deliberately and intentionally incompatible with everything other than the most permissive licences. The problem with "viral" licences like the GPL is that "there can only be one" because they are mutually incompatible by nature. Why should the MPL/Apache/CDDL licences make special exemptions to lessen their requirements so that they can be GPL-compatible?
Nit: Apache 2.0 is compatible with GPLv3 (but not v2).
https://web.archive.org/web/20060816050912/http://www.sun.co...
How would it work anyway? It's not CDDL or MPL that causes the incompatibility, it's the GPL.
"This means a module covered by the GPL and a module covered by the CDDL cannot legally be linked together."
I don't think the incompatibilities are really unintended. If anyone has enough lawyers and money to relicense something correctly, it's Oracle.
ZFS on Linux does not break the intention and spirit of the kernel licence.