Oracle Could Still Make ZFS A First-Class Upstream Linux File-System

[michaelo2]

Why ZFS is not compatible with GPL? This is the best comment I've ever read about this issue:

https://news.ycombinator.com/item?id=9129784

[audir8]

Why ZFS is not compatible with GPL? This is the best comment I've ever read about this issue:

https://news.ycombinator.com/item?id=9129784

Here's a video from the author of the comment explaining how ZFS and Linux aren't completely in-compatible: https://youtu.be/6F9bscdqRpo?t=5m40s

Canonical/Debian/FreeBSD/Joyent do bundle ZFS with Linux/Other OSes, Oracle has had a commercial fork of ZFS for a few years now, and the OpenZFS and OpenIndiana projects are doing fine. If Oracle or Netapp are going to sue Canonical, or anyone working with OpenZFS, I think they would be laughed out of the courts.

[wikinevick]

I sincerely doubt that Oracle would start competing with its own puppy btrfs (yeah Oracle is backing it quite a bit) by porting the old dog ZFS.

I'd like that to happen tho. ZFS is good for its intended purpose, and stable.

btrfs is a dead end. Unfortunately the possibility of opensourcing Oracle ZFS wouldn't seem to involve incorporating any code to/from OpenZFS. In essence it would ignore the ecosystem that has been building around it.

[wikinevick]

Why ZFS is not compatible with GPL? This is the best comment I've ever read about this issue:

https://news.ycombinator.com/item?id=9129784

ZFS is not compatible because Stallman doesn't want to. The FSF keeps a hand picked list of license is makes artificially compatible with the GPLv3, including the Apache License but the CDDL is not something he can control and it's all about control.

[johnc]

If you need ZFS there's really no point in using Linux. It doesn't really get you anything and the Linux implementation of ZFS isn't the best.

[numasan]

What does Oracle get out of keeping ZFS incompatible with Linux (GPL)?

[DrYak]

I sincerely doubt that Oracle would start competing with its own puppy btrfs (yeah Oracle is backing it quite a bit) by porting the old dog ZFS.

Though judging by recent commit, BTRFS seems to be openSUSE's puppy as well.
(See openSUSE's recent announcement explaining why the think keeping BTRFS as their main FS, despite RedHat dropping it)

Also, if Linus Torvalds had been more accepting of ZFS in Linux at the time, things might have turned out differently too. Sun management wanted ZFS on Linux, about the same way that Intel or AMD contribute to Linux.

Linus wasn't accepting ZFS for reason of how the code is organised.

Appart from being CoW-based filesystems, ZFS and BTRFS share another characteristic : they are not pure filesystem, they are complete stack that include filesystem AND volume management (basically, the functionality of EXT4 + LVM + MDADM rolled together).
This is required, because both are checksumed file system. (i.e.: the checksum of extents at the filesystem level, plays an important role to help rebuilding a corrupted RAID error. i.e.: not when a drive is busted and missing, but when the drive is present, but bitrot has silently corrupted the data.

To make an over simplified example: A pure RAID1 would not know which copy is the correct one and which has bitrot and should be rebuilt.
In a "full stack" system like BTRFS or ZFS, the RAID layer can as the filesystem layer to verify the checksum to determine which copy is the correct one.
(In practice scrub works the other way arround: checksum verification will trigger RAID1 rebuilding).

But it's how each handle it that makes a gigantic difference in the balance of Linus.

BTRFS tries to tap as much possible into the facilities present in the kernel :
- the LZO, ZLib and upcoming Zstd compression scheme use the kernel compression engine present as part of the crypto stack. The same routine that compresses Zstd for BTRFS file system is also the one that decompresses a Zstd kernel image during boot.
Adding Zstd to the kernel can be simultaneously benefit both the boot process and btrfs partitions.
- the block management code and redundancy is shared partially with MDADM and Device Mapper. An new erasure coding enabling 3 parities or more in BTRFS could in theory be also used by MDADM (there was some proof of concept patches mentionned a while ago).
etc.

Meanwhile, ZFS works by implement its own stuff.
That helps making the code cross-portable, but that means that lots of features in ZoL are duplicate of facilities already present in the kernel.

That why a lot of kernel dev where speaking about layer violations about ZFS, but not complaining that much with BTRFS.

ZFS is not compatible because Stallman doesn't want to. The FSF keeps a hand picked list of license is makes artificially compatible with the GPLv3, including the Apache License but the CDDL is not something he can control and it's all about control.

Please stop bashing RMS for the sake of it.
There a very precise logic in his madness - Copyleft can be simplified to : You should be able to do whatever you want with the code, as long as you pass the same freedom to hack to the next in line when you transmit this code further.

Now regarding the precise incompatibilities between CDDLv1 and GPLv2, here's what sfconservancy has to say

[audir8]

Meanwhile, ZFS works by implement its own stuff.
That helps making the code cross-portable, but that means that lots of features in ZoL are duplicate of facilities already present in the kernel.

That why a lot of kernel dev where speaking about layer violations about ZFS, but not complaining that much with BTRFS.

...

Now regarding the precise incompatibilities between CDDLv1 and GPLv2, here's what sfconservancy has to say

On the first point, yes, this is why Reiser4 got rebuffed too. This is a valid concern, and I don't think Sun was opposed to doing a performant DRY port of ZFS on Linux, if the licensing could've been source compatible, but it never got to that point, and any hesitation didn't help.

The reply to sfconservancy is here: https://www.softwarefreedom.org/reso...rnel-cddl.html

Frankly, I agree with the SFLC and Eben Moglen.

[oiaohm]

What does Oracle get out of keeping ZFS incompatible with Linux (GPL)?

The answer is not being in court with NetApp.

http://en.swpat.org/wiki/NetApp%27s_filesystem_patents

The troublesome patents with ZFS are mentioned above.
5,819,292 - purportedly relating to "copy on write << end of life dead.
5,963,962 "Write anywhere file-system layout" << end of life dead
6,038,570 "Method for allocating files in a file system integrated with a RAID disk sub-system" <<end of life dead.
7,174,352 - purportedly relating to "snapshot" << end of life dead.

6,857,001 - purportedly relating to "writable snapshots" << has not paid fees. Absolutely sure dead in 2022.

https://www.uspto.gov/patents-maintaining-patent/maintain-your-patent#Reinstate%20an%20expired%20patent

Yes patents read expired but due to USA patent office rules a expired patent due to not paying fees can be reversed by paying fees.

I would say the reason for CDDLv1 has reduced. A read only version of ZFS should be doable and a version where the snapshots are not writeable as well without crossing over the patent. So its still 4-5 years until everything about core ZFS is out from under the NetApp patents completely. Of course its Oracle legal department who could decide to ignore the unpaid patent if they believe if it paid they can defend ZFS from it.

Btrfs is implemented using methods that none of NetApp patents apply.

Lot of people miss that the tux2 file system disappeared due to NetApp aggression.

NetApp sees Linux kernel getting working file system like ZFS as end to a lot of their products so is likely to fight tooth and nail against it.

[garegin]

How is btrfs a dead end? All they have to do is contribute and fix it up. Bottom line, if they are shifting to Linux, keeping ZFS out of Linux is a really stupid move