== Would GPL'ing ZFS have worked or been a good idea? As I mentioned [[yesterday ZFSFutureThoughts]], one bit of recent news was [[Jonathan Schwartz saying that he regrets not GPL'ing ZFS http://news.cnet.com/8301-1023_3-57480255-93/jonathan-schwartz-oracle-bungled-its-chance-at-mobile-java/]]. 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 ../linux/ZFSOnLinux]], 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.)