Apple Officially Bins ZFS

As pointed out by Daring Fireball, Apple has pulled the plug on the ZFS-on-Mac project and will take down the archives shortly. Gruber speculates that this is about legal issues -- like the NetApp patent litigation or CDDL issues discussed here -- and there's some precedent to this. OmniGroup once wrote a backup application for Apple that was binned over IP litigation threats, for example.

However, the CDDL doesn't require indemnification unless products are released under a different license, and Apple certainly didn't throw DTrace from Snow Leopard, and it's CDDL. Apple releases products under numerous different licenses (Apache, GPL, etc.). The NetApp litigation seems to be in its death throes.

The idea that Apple "needs" to use a different filesystem simply because Sun is being bought by Oracle seems fairly thin. Apple uses (and produces -- think of Google's use of Apple's WebKit in Chrome) other open-source software in use by third parties, such as Perl, Apache, fetchmail, gcc, procmail, python, ruby, zsh .... What has filesystem (in)compatibility to do with Apple's competitiveness in user interfaces, or its becoming beholden to a database vendor? Apple has certainly maintained project forks when it's offered benefit (*cough*gcc*cough*).

My question is what Apple thinks it wants to offer that isn't offered well -- or offered for the right price (performance, overhead, maintenability, size, and so forth ... not money) -- by ZFS. The fact that ZFS is a dream for big storage may not make it the lithe, low-overhead tool Apple sees in embedded devices, for example. I frankly can't guess. The fact that Apple imagines diverging from ZFS down the road may make Apple more interested in building the future now than in confusing people about the direction of the future.

Personally, I thought ZFS sounded great. If it turns out that frequently-used characteristics (file type or creator codes, file comments, etc.) are too much overhead for Apple to tolerate but rately used by anyone else, maybe ZFS' design for handling this kind of extended attribute is just a bad deal for Apple. Who knows?

After seeing Apple react to OpenSSH trademark claims, I just don't think the soon-to-die NetApp litigation is really the whole answer. The fact that Apple links CDDL-licensed code into the xnu kernel makes it a fairly sure bet Apple doesn't regard the CDDL as sufficient reason not to include code. The answer -- whatever it may be -- lies someplace else.

UPDATE: An interesting post suggests that licensing is behind the ZFS dump, then proceeds to list a host of reasons that Apple may have both the incentive and the resources to develop something different than ZFS and more suited to Apple's expected deployment situations. This, I view as supporting my hypothesis that a non-licensing reason exists for the ZFS dump. Yes, it's a drag to lose ZFS. However, it's good that Apple is at work on something likely to benefit from high-quality engineering directed at Apple-specific engineering challenges. Among the cites factors are (a) post-ZFS filesystem research, (b) predominantly single-drive system deployments, (c) RAM overhead in ZFS apparently inappropriate for embedded devices, as discovered by another would-be ZFS implementor, and (d) improved resources for original filesystem development now that Apple (i) can amortize the gain over so many platforms (iPhone, iPod, notebooks, routers/switches like Airport-branded stand-alone products, desktops, servers, future devices) and (ii) can direct more engineering toward the problem from the same engineers who a few years ago were trying to add journaling to HFS+, make HFS+ support Unix privileges, make Unix filesystems support MacOS file attributes under MacOS, etc.. In the comments, the author adds a link to this comment, supporting the licensing-issue hypothesis. I agree that the comment appears to be a smoking gun for the issue that Apple asked for special licensing terms. However, given Apple's willingness to use similarly licensed code elsewhere in the kernel without special terms (e.g., DTrace), and Apple's willingness to use indemnity-free code with a history of prior IP claims, I strongly believe the decision not to move forward with existing licensing is founded in concerns about the technical suitability for Apple's intended application. Were ZFS a dead-on match for Apple's intended application, Apple could easily have tolerated existing licensing in ZFS like it tolerated the exact same licensing in DTrace (which is a dead-on match for Apple's intended application). Apple did not: by 2009, ZFS just wasn't that attractive to Apple, which decided to break off its engagement to the filesystem.