First, thanks for the Ars link in the other email. I'll give that a read. On Mon, Feb 5, 2024 at 7:55 AM J. Roeleveld <jo...@antarean.org> wrote: > > On Wednesday, January 31, 2024 6:56:47 PM CET Rich Freeman wrote: > > The main barrier is that its license isn't GPL-compatible. It is > > FOSS, but the license was basically designed to keep it from being > > incorporated into the mainline kernel. > > Which isn't as much of an issue as it sounds. You can still add it into the > initramfs and can easily load the module. > And the code still works with the functions the kernel devs pushed behind the > GPL-wall if you simply remove that wall from your own kernel. > (Which is advisable as it will improve performance)
So, that's great for random individuals, but companies are going to be hesitant to do that, especially for anything they redistribute. This is part of why it isn't mainstream. A big part of the reason that Linux is mainstream is that it doesn't have any legal/license encumbrances. If you have 100 instances of something and want to have 200 instances, you just turn a dial or add hardware. There isn't anybody you need to get permission from or pay. Personally I think the idea that the GPL prevents linking, or that you can have GPL-only APIs is legally ridiculous. Then again, I thought some of the court rulings in the Oracle vs Google Android lawsuits were ridiculous as well around API copyrighting. Dynamic linking is just adding a look up table to your program. It would be like suing me because I advised you to call somebody, arguing that by telling you to call somebody I was violating the copyright of the phone book. Linking is just an instruction to the loader to go find some symbol and substitute its address at this location. However, MANY people would disagree with what I just said, and some might even sue a company that published a large piece of software that failed to comply with the mainstream interpretation of the GPL. A court might agree with them and award damages. I think they and the court would be wrong in that case, but the police don't care what I think, and they do care what the court thinks. The result is that the murky legal situation makes ZFS unattractive. If I were publishing some large commercial software package, I'd personally be hesitant to embrace ZFS on Linux in it for that reason, even though I use it all the time personally. > > > The odd thing is that right now Oracle controls both ZFS and btrfs, > > with the latter doing mostly the same thing and being GPL-compatible, > > but it hasn't tended to be as stable. So we're in a really long > > transitional period to btrfs becoming as reliable. > > After all this time, I have given up on waiting for btrfs. As mentioned in my > other reply, it's still nowhere near reliable. Clearly Oracle likes this state of affairs. Either that, or they are encumbered in some way from just GPLing the ZFS code. Since they on paper own the code for both projects it seems crazy to me that this situation persists. > > To make this easier, there is a compatiblity option when creating a new zpool. > It's also listed in the zfs-kmod ebuild: > - zpool create -o compatibility=*grub*2 ... > - Refer to /usr/share/zfs/compatibility.d/*grub*2 for list of features. Oh, that is VERY helpful. I've found random many-years-old webpages with the appropriate instructions, but something that is part of the maintained project is much more useful. Granted, I think the bottom line is that boot probably shouldn't be on the same filesystem as large volumes of data, as these feature restrictions are going to be cumbersome. I'm guessing you can't shrink vdevs, for example. -- Rich
