As nice as the technology is as long as there's the potential of a Damoclean license issue I'll always feel hesitant around ZFS.
(Hey looks like it's a sore spot!)
(Hey looks like it's a sore spot!)
I very much regret the fragmentation of FS design, it has many mothers. "there can only be one" was never going to work, but we seem to have perhaps 4-5 more than we really need. ZFS manages to wrap up a number of behaviours cohesively with good version-dependent signalling so it should always be possible to know you're risking a non-reversible change to your flags. And, it keeps improving.
But, counter "it keeps improving" so do all the other current, maintained, developed FS and if somebody tells me they prefer to use Hammer, or one of the Linux FS models with a discrete volume-management and encryption layer, I don't think thats necessarily wrong.
Mainly I regret Apple walking away. That was about Oracle behaviour. It wasn't helpful. A lot of Apple's FS design ideas persist. I never got resource/data forks, it only ever appeared on my radar as .files in the UNIX AUFS backend model of them. Obviously inside Apples code, it was dealt with somehow. It felt like the wrong lessons about meta data had been learned. Maybe an Ex-VMS person went to Apple? Also Apple has a rather "yea maybe or no, dunno" view about case-independent or case-dependent naming. Time machine is good. Feels like it should fit ZFS well. Oh well.
You just have to define whatever kind of tags you want and choose names for the xattrs in which to store them and then you should use them in your scripts or applications.
I am using all the time xattrs for things like file checksums and content classification, on XFS and on FreeBSD UFS, but almost all modern file systems support xattrs, except Linux tmpfs (which has only a partial support that is useless for those who use custom xattrs, so a file with xattrs cannot be copied to /tmp if tmpfs is used).
tmpfs is getting user xattrs in kernel 6.6, together with quotas.
> You just have to define whatever kind of tags you want and choose names for the xattrs in which to store them and then you should use them in your scripts or applications.
It is still just a oob store, you have to traverse the directory hierarchy old-style; the old BeOS did (and Haiku today does) something more: it indexed the selected xattrs and allowed live queries against those indices. This allowed for very interesting uses.
I am aware of this, but the so-called user xattrs support most likely remains too bad to be of any use.
The kernel list message:
"Add support for user xattrs. While tmpfs already supports security xattrs (security.*) and POSIX ACLs for a long time it lacked support for user xattrs (user.*). With this pull request tmpfs will be able to support a limited number of user xattrs."
I am waiting to see which is the meaning of "a limited number", but based on the history of tmpfs, I suspect that this does not mean that the number of extended file attributes is limited to some value, but it means that there is a small list of names of user xattrs that will preserved (which are those used by some application that the tmpfs devs love, while they are hating the other applications), while the other xattrs will be lost, like now.
If "a limited number" is really a number, that would be much better, but this might still mean that the number is excessively low, e.g. ten attributes or less, instead of being high enough to not be a serious limitation, e.g. one hundred or one thousand.
> It is still just a oob store, you have to traverse the directory hierarchy old-style; the old BeOS did (and Haiku today does) something more: it indexed the selected xattrs and allowed live queries against those indices.
You are right and it would be nice if the file system itself would allow faster queries by xattrs than what can be achieved by testing the attributes of files selected by their names.
However, it is not difficult to create a database file indexing the files by attributes, but it may need frequent updates, to remain in sync with the indexed file system. I use such databases, but mainly for file system parts where I keep files for long-term storage, like books, research papers, handbooks, product documentation or older software projects.
It looks like it will store as many xattrs as there is space for, based on their contents.
All the file systems that support extended file attributes have some limit for the size of the attributes attached to a file, for instance of 64 kB.
After searching through the patch, it seems that the maximum number of xattrs is 128. There is also a size limit of 128 kB, which might be the limit for the sum of the sizes of all attributes.
If that is the only reason for saying "a limited number", then this is very good, the limits are high enough to not cause any problems in most applications, so tmpfs will finally no longer strip the attributes of the files copied through it.
There's quite a few "quality of life" differences like boot environments (boot into a pre upgraded OS state, even years old), built in SMB server with NFS v4 style ACLs, dtrace, built in snapshot scheduling and management, and Napp-It is an available web UI for management a la FreeNAS/TrueNAS.
It has a few differences, service management is quite different from other things, but overall very underrated as an OS I think.
Frankly, if even Debian can use it, it's a non-issue.
That depends on what you want. If you want a license that will play well with closed source software, then yeah, it's a downside. But the GPL family comes from the perspective of a developer who wants to retain their rights while respecting others' desire for the same. If you care about your rights, then this is an upside.
>"It has a weak per-file copyleft (like version 1 of the Mozilla Public License)"
The CDDL isn't a strong copyleft licence. It doesn't give a shit what larger project you include the code into, and it doesn't give a shit how you licence the resulting binary. It's considerably more permissive than the GPL.
The conflict is entirely on the GPL side.
I agree this is unlikely, but so is someone being born with as much litigiousness as Larry Ellison.
ZFS is licensed under the CDDL [0], which is a copyleft license that grants you full rights to use the ZFS source code for basically anything, providing that any derivative works incorporating its source code are also are under the CDDL. There is no "licensing fee" that you can pay Oracle related to this.
Linux is licensed under the GPL, which just like the CDDL, is a copyleft license which requires derivative works to be distributed under the GPL.
The conflict here is that both require the entire derived work to be distributed under CDDL/GPL, but obviously only one license can be picked.... even though realistically, GPL and CDDL are quite similar licenses.
The additional fact that is useful to know is that zfs.ko, the zfs kernel module, is distributed under the CDDL by ubuntu, and any other distro distributing it that I know of.
So, with that knowledge, who can sue who and why?
1. The people that can be sued are people distributing compiled zfs binaries (the 'zfs.ko' kernel binary). In practice, this means canonical, and anyone else who distributes disk images using ZFS (such as snapshotted EC2 AMIs)
2. The people who can sue are the holders of the Linux GPL license, and they can do so by claiming zfs.ko violates their copyright by being a derived work of the linux kernel, but being distributed under the CDDL rather than the GPL.
So, first of all, the vast majority of companies using ZFS aren't also distributing binary distributions containing zfs.ko and the linux kernel together, therefore this whole thing is moot. Realistically, most companies using ZFS only have the risk of _canonical_ being sued, and that breaking their filesystem, not them running into legal issues themselves.
And second, it would require a holder of Linux copyright to file suit, and realistically, no court could find significant damages here.
Canonical also has lawyers that claim 2 wouldn't legally follow, that 'zfs.ko' is not in fact a derived work of the linux kernel. There's differing opinions there, but pretty much everyone agrees that the people who could sue if this interpretation is wrong is the holders of Linux copyright, not oracle.
[0]: https://en.wikipedia.org/wiki/Common_Development_and_Distrib...
The CDDL is totally ok with the rest of the linux kernel staying GPLv2. The GPL is allergic to any non-GPL (eg. ZFS) code being distributed with the kernel source.
Does it change any of the other information? I admit I shouldn't have written "both require the entire derived work to be distributed under CDDL/GPL", and instead should have written "both may require, depending on a court's interpretation, the zfs kernel module to be distributed under CDDL or GPL respectively".
I think the rest of the comment stands though, right?
That's wrong, and misses fundamental information about the CDDL.
First, the CDDL gives absolutely no fucks how you licence a resulting binary. It only cares about the specific covered source files, and doesn't care what you bundle them with. So nobody would ever argue that the module should be licenced as CDDL.
On the flip side, you'd have a really hard time arguing that the module should be licensed as GPL.* Sure, there's maybe a GPL wrapper, but lots of modules are non-GPL even when they might feature such a wrapper. ie. nvidia. You also can't argue ZFS is a derived work of the kernel, which is really the crux of the issue. ZFS was first written on solaris, developed for several years on freeBSD, and remains neutral across 3-5 different supported OSs. There's nothing to indicate the GPL should have more claim over ZFS than the wrapper.
The one and only place you'll ever run into trouble is if you start trying to distribute ZFS *source code* in the kernel source tree, as a fully integrated part of the kernel. (EDIT: or compiled together in a single kernel binary, from said combined source) The CDDL doesn't care about the mixing but the GPL does. Literally everyone agrees this is a bad idea and nobody does it.
*Let's ignore for a moment for the moment that you *couldn't* since the GPL requires complete corresponding source code and you can't relicence the CDDL source code files.
> On the flip side, you'd have a really hard time arguing that the module should be licensed as GPL
That is the very thing that some people do argue, for example the sfconservancy people. As I note, canonical's lawyers take your view (and I personally agree), but it's not clearcut. The sfconservancy outline their reasoning clearly for why they think zfs.ko is a derived work of the linux kernel.
Their stance isn't just rejected by nvidia and company, but also by the kernel devs most notably torvalds himself. Their argument boils down to "if ONLY it were statically linked everyone would say it's derived" combined with "there's no difference between static and dynamic linking."
They completely ignore the inconvenient fact that being statically linked would imply being pasted into the kernel tree, and the real reason people would say it's derived at that point is because you'd expect the ZFS code to be deeply connected with linux's guts if that were the case. Which it isn't, and it isn't. Over in reality courts look at how code came to be and where it came from, a more reasonable definition of "derived." For one thing it means I can't come up with a GPL module that statically links against a pre-existing bit of other software and then try to claim the software should be GPL. (remember, OpenZFS' fork long predates ZFS' compatibility with linux)
Being a derived work shouldn't imply time travel, i.e. at the very minimum shouldn't violate causality.
Torvalds himself has personally refuted the "(dynamic) linking inescapably means you're derived" point on multiple occasions, and yet here the SFC is, continuing to wave it around because that's how they wish it worked.
Their article is very plainly a "extend the GPL's reach" political move attempting to move the goalposts the kernel community set up wrt proprietary modules, while using the muddy waters around ZFS as cover. Their arguments could equally be applied to the nvidia kernel module and yet would instantly be rejected as extreeme if they attempted to use nvidia's module as their subject.
They could sue you as a kernel contributor, but only if you do something to violate the GPL. The only thing that would clearly violate the GPL, in the era of proprietary nvidia blobs, is if you tried to ship the ZFS source code in-tree.
Everybody agrees that's a bad idea, nobody does it. ZFS instead is shipped as a separate kernel module.
As someone ignorant to file system development, I would almost expect something more likely to be BTRFS getting sued for copying a feature of ZFS or something like that.
If anyone (Oracle or Linus Torvalds) launches a ZFS-related lawsuit, it'll be as an author of GPLv2 kernel code. For the time being the solution has been to ship ZFS separate from the kernel, as any module with a non-GPL licence typically does.
The biggest hurdle to ZFS isn't legal, but technical. The various teams working on ZFS has so far been able to keep up with kernel churn and symbols (eg FPU ones) being made GPL-only.
That said, the kernel devs have made it clear that they don't care if you're open source or proprietary, they will make changes and mark new symbols GPL-only to fuck with you regardless.
However, what will be left is a blob, that runs on the dedicated core on the GPU. The stuff that Nvidia doesn't want to open is moved there, and that's why the open kernel driver works only on Turing and newer.
But that basically firmware, right? So not all that different from the firmware loaded by a NIC?
If Oracle wanted to, they could easily release their copyright under a dual license or something else to clear up the licensing issue. They have not, and have chosen to retain the ability to sue every Linux user using ZFS. This concerns me.
Back in the pre-oracle days Sun's fishworks division sold ZFS-based storage appliances. Oracle still sells those, and thanks to ZFS' reputation they're still profitable. Oracle simply took that much older fork of ZFS (with no OpenZFS code in it) and made it closed-source.
Before anyone asks, no, that fork is too old and too diverged to be compatible with OpenZFS.
We're currently in a legally-stable state, and have been for over a decade now (nearly two). If they could have done something, they would have.
The fact is that so long as nobody tries to merge ZFS code into the mainline kernel, there's nothing they can do. Everybody knows this, everybody agrees that would be a dumb idea, and everybody has agreed not to do it.
Oracle can't actually sue people using ZFS modules. The CDDL licence that sun provided already gave all the relevant rights away. They can only sue from the GPL side as a kernel contributor, and that's ONLY if someone is dumb enough to ship ZFS code in the linux source tree.
You *seriously* underestimate the number of people using ZoL in production that Oracle would love to sue *if they could.*