2012-07-31
Would GPL'ing ZFS have worked or been a good idea?
As I mentioned yesterday, one bit of recent news was Jonathan Schwartz saying that he regrets not GPL'ing ZFS. Some people may be going 'if only' now, but I take the other view; I don't see how this would have been a good idea for Sun and I don't think that GPL'ing ZFS would have been effective by itself at getting ZFS into Linux.
I've written before about the practical difficulties of getting ZFS integrated into Linux, so I will just summarize it by saying that making the Solaris ZFS code available is only a small part of the work needed. The amount of work goes up again if you're trying to maintain Linux ZFS and Solaris ZFS in sync (you're unlikely to be able to maintain them from the same code base, not without a huge amount of ugliness). Sun could have done this work (with time), but then we run into the next issue.
Put simply, it's hard to see how GPL'ing ZFS would have done Sun much good at a commercial level. I can't see how a GPL'd ZFS (even one integrated in Linux) would have driven any increased demand for Sun's hardware or software. To be blunt, Solaris 10 was already not generally competitive with Linux even when it was the only place to get ZFS; taking away even this meagre advantage wouldn't exactly have helped. In the absence of a commercial advantage, GPL'ing ZFS would have amounted to nothing more than a donation of a significant amount of engineering effort from Sun to the open source world (especially if Sun went on to expend more engineering effort integrating the ZFS code into the Linux kernel). This is nice (for the open source community) and might have secured Sun some sort of legacy, but it kind of seems like a bad business decision (with all downsides and no upsides).
(The counter argument is to say that even at the time, Sun and Schwartz understood that ZFS effectively had little or no actual commercial value because it clearly couldn't be used to drive significant business to Solaris. If you have what is basically a zero-value thing, you might as well GPL it for the PR bonus and, yes, the legacy (especially if you also suspect that your entire company is doomed).)
The final issue with a GPL'd ZFS is the one that people don't talk about much: patents. If ZFS really does infringe NetApp's patents (as alleged in an old lawsuit between Sun and NetApp), GPL'ing the code might not help much in getting the code actually used. For example, I don't know if the Linux kernel people are willing to touch something that is under active patent threat. Certainly many Linux distributions will not include things that under such threats. (As we can see from their continued lack of things like audio and video codecs.)
(I am focusing on Linux instead of FreeBSD not because I think that FreeBSD is immune from patent threats but because I suspect that patent holders see Linux as the real threat, plus there's prosperous Linux companies that can be profitably sued.)
Sidebar: the outside developers argument
One possible argument for GPL'ing ZFS is that it would have attracted outside developers to improve ZFS; then, so the argument goes, even if Solaris wasn't the only place to run ZFS Sun could still have worked hard to make it the best place to run ZFS and made money that way. The problem with this is licensing (at least if we assume that the rest of Solaris stayed with its non-GPL-compatible licensing).
As the copyright holder, Sun can both GPL their own code and combine it with other code in non-GPL-okay ways. However Sun does not have this power for other people's ZFS improvements; to get it back, Sun would have to require copyright assignment from ZFS contributors. That's sort of fine (although it cuts down the pool of contributors), but only up until ZFS gets integrated into the Linux kernel. To put it one way, the Linux kernel people are extremely unlikely to require copyright assignment to Sun before they will accept ZFS patches from outside people. So you would quite likely have a steadily increasing set of Linux-only ZFS improvements that could not be integrated back into Solaris ZFS because of lack of copyright assignment.
(Meanwhile Linux could integrate all of the worthwhile Solaris ZFS changes back in, up to the point that Sun took the huge PR hit of no longer providing them under the GPL.)
Ruminations on the future of ZFS
The big news recently has been Jonathan Schwartz saying that he regrets not GPL'ing ZFS, on the implied grounds that ZFS being in Linux would have made it relevant. Setting aside questions about whether or not GPL'ing ZFS would have worked to get it included in Linux and whether it would have been a good idea for Sun, this leads naturally to thoughts about ZFS's future.
ZFS's future is intertwined with the futures of Solaris and Illumos. Solaris's future is entangled with Oracle and so essentially opaque, but my personal opinion is that Solaris is basically dead as far as ZFS developments go (and probably in general, although Oracle will keep shaking the corpse for a while). That leaves Illumos. The problem with Illumos, put simply, is that it's a free Unix without an ecological niche. Not many people are interested in Illumos or any derived version for its own sake and it seems unlikely that that will change (the ecological niches that Illumos could plausibly make a play for are solidly occupied by strong Unixes). This effectively leaves ZFS development being done by a consortium of storage appliance vendors and storage users.
(I am discounting FreeBSD here because it's not clear if FreeBSD is doing any independent ZFS development.)
The problem with this is that historically, niche Unixes and niche Unix projects have had problems sustaining themselves and keeping development happening (due to both lack of resources and being insufficiently attractive to most outside developers). And indeed right now ZFS seems to be mostly frozen. This has advantages, such as a selection of platforms to get equivalent versions of ZFS on, but it also has significant drawbacks because ZFS is still missing important features (the most prominent is the ability to remove vdevs from a pool, which matters for long term storage management).
So the much shorter version of this is that the future of ZFS right now certainly seems to be ZFS as a slow-moving thing. Whether or not it's entirely a niche thing isolated in what is essentially a backwater depends on FreeBSD (and I have no idea how much the FreeBSD people like ZFS).
(A related issue is that ZFS is mostly standing still while other potential competitors advance. The potential competitors are starting from well behind where ZFS is now, but we've seen this show before and it didn't end well for the incumbent commercial Unixes.)
Sidebar: Why I consider Solaris dead for ZFS
It's a combination of three things. First, apparently almost all of the original ZFS developers have left Oracle (many of them have wound up working on Illumos). Second, Solaris is no longer open source, so any ZFS developments that happen there are a closed box. Third, Oracle's pricing on Solaris makes it unattractive for most people to run, so whatever closed-box ZFS changes that happen are not going to be widely used.