Some think license liability is at the heart of Apple's ZFS drop. Is this what's going on with ZFS? Despite ZFS being in significant commercial deployment, and being the default filesystem and boot filesystem for the well-known Solaris operating system, Apple has nixed it as a feature of its most recent operating system. The license under which Sun offers ZFS is the CDDL, which requires licensees indemnify Sun and other contributors for liability they might face in connection with their code contributions if licensees distribute ZFS under a different license:
You hereby agree to indemnify the Initial Developer and every Contributor for any liability incurred by the Initial Developer or such Contributor as a result of any such terms You offer.Presumably, Apple's binary distribution under its standard clickwrap license is a "different license" though it's possible Apple could fine-print references to the CDDL, the GPL, the Apache license, and other licenses applicable to various parts of Apple's software distribution. Is Apple afraid Apple might be on the hook for indemnification liability?
Common Development and Distribution License, ¶3.5
A little thought is in order, here. Calls for Sun to GPL ZFS are misguided. Sun has a non-GLP operating system, and if Sun wants to link ZFS to its operating system without GPL-ing it, Sun needs to make sure ZFS stays non-GPL. The Oracle purchase of ZFS doesn't mean Oracle can unilaterally change the license on code contributed (potentially) by a host of third parties, who expressly licensed their additions under the CDDL, presumably so they could link ZFS to their non-GPL operating systems (e.g., FreeBSD). Just as the ssh trademark litigation was without merit, claims to patent rights by NetApp (and potentially others) in ZFS are likely also without merit. If so, inclusion of ZFS dramatically improves the feature set of low-cost hardware in the storage space, to the detriment of first-tier storage vendors and to the benefit of, say, Oracle and Apple (whose revenues don't come from storage but from computer hardware and software licenses).
If patent liability is the issue, the obliteration of NetApp's claims in court probably bode well for Apple's re-inclusion of ZFS as a feature of MacOS X, perhaps even on a timetable similar to that of the inclusion of ssh. The fact that ZFS includes a broad tool suite and would require specific support from some user-facing apps to access important features might make Apple's inclusion of ZFS rather less trivial than OpenSSH, but there's reason to suspect that Apple might actually release a ZFS-supporting operating system sometime in the foreseeable future rather than kill the project forever.
After all, what else does what ZFS does? And is production-ready and proven in use?
UPDATE: Randall Smock's comment at StorageMojo.com is interesting -- it points out that folks using Boot Camp to access Microsoft operating systems from Apple hardware will face an interesting challenge if Apple starts shipping ZFS ... because those machines would start being unable to access parts of the Mac while booted in MS-Windows. I doubt this is by itself sufficient reason to scrap ZFS (even as a non-default filesystem), however. It is interesting, and invites questions about how Apple might solve this (e.g., with MS-Win drivers to enable at least read-only access to the volumes in question). After all, Apple ships read-only access for NTFS, though there are solutions for this, too.
2 comments:
I responded to your comment on my blog, but I wasn't sure you would see it.
Your analysis of the SSH situation is not correct. 10.0.0 absolutely shipped with OpenSSH (Mac OS X public beta shipped with an ssh implementation, but I think it was not OpenSSH)). The technote is referring to the fact that the UI checkbox for "Remote Login" in 10.0 enabled telnet and rsh, and in 10.0.1 that was changed to ssh. All of them were included with the system, and could be enabled by manually adding "SSHSERVER=-YES-" to /etc/hostconfig.
If you want you can even look at the public repo for 10.0 and see the exact version of OpenSSH they used.
The OpenSSH trademark threats were an unrelated thing going at the same time clearly did not prevent Apple from shipping OpenSSH (since they actually did ship it).
Thanks for your reply.
I was surprised to read your statement that OpenSSH was part of the 10.0.0 installation, when my own recollection was against this (e.g., I tried to use ssh on my MacOS machine then and could not, which I recall because I was irritated about it). However, I note that despite Apple's technote (which you point out is at least as easily construed to mean that the UI didn't enable the OpenSSH server, not that it wasn't available to interested users who bothered to run it from the command line), it's easy to confirm your version of the facts with an OpenSSH vulnerability report backs up your account by listing Apple's MacOS 10.0.0 as a vulnerable platform. Apple's technote recites that OpenSSH shipped "with Mac OS X 10.0.1 or later," and I recall installing 10.0.0 only to be surprised, alarmed, dismayed, etc. that secure remote login wasn't supported on the command line. But now you've got me wondering whether my path didn't include the right directories or the like ... incidentally, you know migrating from tcsh to bash was something of a shock, don't you? This was for sure a nod to the huge base of Linux users who expect bash-like behavior in a shell ... or will you tell me it was because scripts Apple wanted to port depended on bash's behavior? :-)
But more importantly to the point of ZFS, though, is this: I agree that an unsolved licensing incompatibility is a showstopper; however, if CDDL were a showstopper then Apple would surely not link other CDDL code (e.g., DTrace) in its shipping product in the very same kernel from which ZFS was removed. So, I doubt the CDDL license was itself the showstopper. I am much more persuaded when you write that fate conspired against ZFS in MacOS "because the appropriate people were not that excited about ZFS from a technical perspective."
I definitely appreciate your description of the technical issues -- and subsequent research -- that make alternatives attractive (and plausible) to develop. Based on what you've written, I think we agree that if ZFS were really a perfect fit Apple would have worked harder to make it happen, and that Apple's casual abandonment of ZFS suggests lack of enthusiasm on technical grounds.
Let's hope for a technical triumph from other quarters :-)
Post a Comment