That is not a requirement. ZoL has the most sophisticated build system of any Linux kernel module in the world to enable it to live outside of the main tree. ZoL relies on autotools' API checks to do this. In addition, the project has an automated buildbot that helps us to detect regressions in pull requests before they are merged. It is similar in principle to how lustre filesystem development is done. Lustre is also (primarily) outside of the tree and lived entirely outside of the tree for years.

That being said, being inside the kernel source tree is not necessarily a good thing. As I wrote in the blog post, other filesystems on Linux generally do not provide the latest code to older kernels, but ZoL provides the latest code to all supported kernels and distributions. This ranges from Linux 2.6.26.y to the 3.16.y in 0.6.3 and will include 3.17.y in 0.6.4. Something as important as a filesystem should be updated to fix bugs, even if the kernel proper cannot be. The inability of all Linux systems to update to the latest kernel is an issue that Linus Torvalds mentioned at LinuxCon North America 2014 and ZoL is one of the few filesystems that can deal with it on systems where it is deployed.

You know... I hadn't given much thought to Lustre. And that is a very good comparison. Lustre is completely out of kernel (in terms of development), so it's not like you're the first to try this.

I guess it really depends on where you want ZoL to be deployed. Lustre is typically deployed on HPC clusters and is managed by people who understand it, how to set it up, and how to manage it. It's not a trivial system to get working, and requires a pretty large budget. It just isn't setup on your typical server. Lustre also has a few big names behind it to provide development resources and support (Whamclound, now Intel).

What is the target market for ZoL? Do you want it to work on servers? Clusters? Personal workstations? They are very different markets.

I'm using ZFS right now for a single storage server that doesn't need to support a large cluster, so ZFS/NFS works great. But I'm using FreeBSD. For my Linux servers, I wouldn't think of using a filesystem that wasn't natively supported by Red Hat. I just don't want the management headache. I'm okay running a single FreeBSD box for my storage needs, but I'm fearful of what happens when I'd need to scale things out to multiple servers.

I wish you luck, I really do. It seems like you're not going into this blind and you're making good decisions. But it will be an uphill battle and you'll always have that specter of Oracle looming over you. It doesn't matter if you're technically/legally right on the licensing front - you'll still have it looming over you until Larry signs off on it (like you said below).

If you can get that sign off, then all bets are off, and you'd be golden!