As the author of that article, thank you. And, I agree it would be sad if you had to think about exactly how many drives are in a RAID-Z group. The entire point of my blog post is that you do not have to think about it.
"TL;DR: Choose a RAID-Z stripe width based on your IOPS needs and the amount of space you are willing to devote to parity information. Trying to optimize your RAID-Z stripe width based on exact numbers is irrelevant in nearly all cases."
ZFS device removal is on its way but not quite in illumos yet. From Alex's blog post: "We’ll publish the code when we ship our next release, probably in March [2015], [and we will] integrate into Illumos once we address all the future work issues."
The legal issue is a matter of some debate (see below). In practice, I don't think the Benevolent Dictator wants ZFS in the main Linux kernel tree at the moment.
In this link Linus talks about loadable module licensing.. gives an example of AFS, which he says he did not think counted as a derived work (and therefore did not need to be licensed under the GPL).. very similar to the ZFS case.
You don't see Linus's viewpoint as contrary to the one on gnu.org? It seems like Linus is saying that the GPL allows AFS to be used with Linux (because it is not a "derived work"). How is ZFS different from AFS in this respect?
No, I don't. The gnu link says CDDL is not compatible with the GPL. What Linus is saying is, if a kernel loadable module relies on kernel internals, then it may count as a derived work, and must be licensed under a GPL-compatible license. If it does not -- for example, it is a filesystem that was ported to Linux (like AFS, and zfs fits here too IMO), then it may not be a derived work, and can be licensed under a non-gpl compatible license (like the CDDL).
Obviously, including the AFS or zfs into the source WOULD DEFINITELY create a derived work, and would require AFS/ZFS to be licensed under the GPL.
So Linus' is only explaining how a kernel loadable module could be licensed under a GPL-incompatible license.
Well written, I will add that it's pretty clear cut that zfs on linux would be a derived work of the kernel cause it has some differences specific to linux internals to make it work. That's why zfsonlinux only distributes module sources. Since it never distributes a binary, it can't run afoul of licensing.
It's really more than simply adding it to a repository. I can store two text files that have nothing to do with each other on my HD or in a repo or wherever, and I would not be creating a derived work.
But if I have file A (kernel source) and file B (zfs code), and I compile A+B into a binary (the kernel image), then I have a single work that has been derived from A and B.
When it's suggested that ZFS be added to the kernel repo, what's really being said is that a single work (kernel+zfs) should be created.
In contrast, ZFS is currently a kernel loadable module. We have the kernel binary, and the module binary.. two separate works. (What Linus was clarifying was how integrated the module could be with the kernel and it still be considered a separate work.)
So what if it was inside the official kernel repo but defaulted to building as a module, and anyone distributing binaries left it on the default? Would that actually satisfy the licenses or are there clauses that would get in the way?
From my mostly second-hand knowledge, in practice even lawyers specializing in IP wouldn't have a solid answer for how to make this distinction, without looking at a specific case in detail. If it came up in a trial, the two sides would make a version of the arguments presented here: one would emphasize that the sources have now been "added to the kernel tree", a unified project managed with close integration etc. etc., while the other side would argue they were merely placed alongside the kernel sources in a version control system, like collecting short stories in an anthology.
Let me ask a slightly different question then. Does the GPLv2 ever try to control anything that is not derived from the GPL source code? Some of the FSF's saber-rattling seems to imply that either the answer is yes, or they're being misleading, or they have a completely ridiculous definition of derivation.
A derivative work is one that extends upon an original work. Thats an simple definition of a derivative work, but doesn't include any clear examples.
The FSF gives the example that linking causes a derivative work, and incorporates that line of thinking into the LGPL. The reason behind it is that a linked work existence is based upon an original work, and can not exist without it. As such, linking is an easy example where the line into derivative work has been crossed.
In the end, it will be up to the courts to decide what is or isn't a derivative work in software. The statutory definition is incomplete and the concept of derivative work is thus interpreted with reference to explanatory case law. Each time a music company wins a lawsuit against remixes, derivative work extends its grasp. Each time a game like WoW wins a lawsuit against bot software, one more step is taken.
In light of the precedential cases, I consider the FSF example of linking to be quite conservative definition of derivation. It might not be true every time and for every possible use of linking, but it should be true enough in the general case. Is there a strong argument against that interpretation?
Don't they claim that the linking rule works via derivation? As far as I understand it, the FSF would tell you that anything linked is always derivative. But that doesn't mean it's true. If you could prove that a particular instance of linking to a library was not derivative, would they still claim your program had to be GPL?
As I understand it, the LGPL exists to 1. provide legal certainty and 2. allow some amount of external derivation if necessary.
And it's easy to create an artificial dynamic-linking case where there is provably no derivation, using multiple libraries with the same API.
Don't they claim that the linking rule works via derivation?
Yes.. it was the closest thing I could think of where the two pieces of software are fairly separated. I mean you could have a huge proprietary program, and a developer calls gsl_pow_int() from the GNU scientific library, and the entire program must be licensed under the GPL.
I think that's about as close as you're going to get.
If you're looking for a case where the FSF said a piece of software had to be licensed under the GPL, even though it was NOT a derivative work, I don't think you'll find it. The reason it must be a derivative is copyright law.. the GPL can't unilaterally change that.
And they do have a requirement if you do so: The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.
If yo take a Makefile which say Linus had written and tack on some of your own rules, you have almost certainly (unless the original Makefile was something trivial like ::) created a derived work.
If you distribute a single source tarball with code files with different licenses, all of them apply. There may be different terms limiting what you are allowed to do with the file in each of the licenses, while the most restrictive license terms apply to the whole file.
Besides the real legal issues, this also causes unnecessary confusion for users and those creating packages for binary distribution. Therefore, using multiple incompatible licenses in a single source tree is usually avoided.
>If you distribute a single source tarball with code files with different licenses, all of them apply.
Yes, the tarball distribution must respect all the licenses of files inside it, but once the tarball is unpacked it goes back to individual licenses per file. I understand how it's a big mess when it gets to binaries, but do any licenses actually place restrictions on what they can be tarballed with?
Lets forget the licensing entirely. ZFS was built ontop of the Solaris VFS layer (virtual file system), which is entirely different than the Linux VFS. Taking the code in the Solaris kernel that provides ZFS and porting it to the Linux VFS is a massive undertaking that would require rewriting most of the "stable" guts of ZFS.
Honestly other than the fuse stuff, I doubt ZFS will ever be in Linux as it would require a rewrite of such a large portion of code, it would be impractical.
> Taking the code in the Solaris kernel that provides ZFS and porting it to the Linux VFS is a massive undertaking that would require rewriting most of the "stable" guts of ZFS.
And it's been done and working quite well considering. There still are improvements to be made, but progress is happening.
I don't mean adding solaris / illumos interfaces (see slide 8 on your link) into the Linux kernel. That will simply never be accepted upstream. I mean properly porting it from the Solaris to the Linux VFS without a shim ie a native port.
That still has not been done. It is a ridiculous amount of work.
Wait, if the current Linux ZFS module doesn't interface with the Linux VFS, then how does the filesystem even work? Did they write a Solaris VFS -> Linux VFS bridge?
"""
Solaris Porting Layer
- Adds stable Solaris/Illumos interfaces
* Tasqs, lists, condition variables, rwlocks, memory allocators, etc
- Layers ontop of Linux equivalents if available
- Solaris specific interfaces were implemented from scratch
"""
It doesn't (currently) use the Linux page cache, which causes quite a few ancillary issues. The idea is awesome, but this will simply never be able to be "natively" in linux without a rewrite of much of the core.
"TL;DR: Choose a RAID-Z stripe width based on your IOPS needs and the amount of space you are willing to devote to parity information. Trying to optimize your RAID-Z stripe width based on exact numbers is irrelevant in nearly all cases."