Okay, first let's TRY to be civil and not involve hard-nosed zealotry about tainting the kernel, CDDLv1 versus GPLv2, and such "this open source isn't open source enough, or isn't true open source". Let's actually discuss how it could be done since we know Ubuntu found legal grounds to do so and we know Torvalds is hands off about it from his own words or keep it as tame as possible within reasonability for educational and informative purposes.

1. We know Ubuntu has shipped and continues to ship a ZFS via a loadable module in their initramfs/initrd as opposed to a static kernel build distribution.

2. We know OpenZFS and ZFS-on-Linux can be done via FUSE for extended partitions on systems, but not bootable or system file partitions on immediate systems on Slackware which has its steady common inclusions like Ext2/3/4, JFS, XFS, and Btrfs.

So here's the meat and potatoes of the situation...

How would, and could, OpenZFS benefit Slackware, if the same design of distribution and inclusion done by Ubuntu was mirrored in Slackware? Let's say, for hypothetical purposes it is doable and included one day in an experimental release...

Do you think it would spark interest into people learning more about Slackware and could/would it increase the interoperability between Slackware and other systems like, for example, FreeBSD and Illumos based Unix-like systems?

If given the choice, would you experiment with it in test systems, VMs, or maybe even do a fill deployment if, and only if, you, through testing, found it very reliable?

What are your full thoughts on this idea and concept and what Ubuntu accomplished and maybe opened up for GNU/Linux users?

Interoperability is probably the only good selling point - then again it would also have been nice to have say UFS, UFS+ and UFS2 RW support in say Linux, but then again UFS in FreeBSD is different than even UFS in OpenBSD I think(?) - this is also the same issue the other way - supposedly FreeBSD is the only BSD in the family that has somewhat RW support for ext2/3 , but from what I read even today support is still not fully stable, and certainly no write let alone any read support AFAIK for JFS, XFS

I think though overall it would be needless and redundant because if I am also not mistaken doesn't BTRFS aim to achieve what ZFS/OpenZFS does? Also you mentioned FUSE for OpenZFS... Well, wouldn't that dramatically reduce performance? Licensing issues aside as Linus pretty much will never include it into the kernel, you have distros like Ubuntu who are willing to implement it themselves, the problem is I venture to guess Ubuntu doesn't have the same issue as Slackware in terms of the number of devs. I don't know how much work would be needed to be put into it, and I don't know if Pat even wants to bother with OpenZFS in Slackware. I guess your only alternative is to roll it yourself - or maybe see if Didier Spaier of SLINT might be interested in adding it to SLINT.

My opinion? bcachefs is likely to become the best file system native to Linux. Its integration in the Linux kernel is likely to happen sooner than later, with its recent acceptance by Linus in Linux-next.

2 members found this post helpful.

I think UFS2 is very close to what EXT4 and JFS are.

As far as Btrfs and ZFS. They feel similar, but btrfs is solely tied to Linux and ReactOS. However, it's goals feel the same, but not exactly the same when it comes to upscaling to larger systems and more modern hardware configurations. Plus, if memory serves many Enterprise distributions have dropped btrfs due to the fact it's still considered experimental, Red Hat being one of them.

My own opinion is very similar to this:

https://sfconservancy.org/blog/2016/...zfs-and-linux/

Am I liable to be sued over this? Really, I could care less. People who write software have the right to pick whatever license they want, and I'll respect it. I'll even respect what I think is the *spirit* of the license, and will not look for or utilize any loopholes. And, just like "all my friends jumping off a bridge", I don't care what Ubuntu did, or what anyone else did or does.

Has this sort of stance hurt me in the past? Clearly. Look at my refusal to switch to glibc because it was still in beta.

We are done here, ReaperX7. I'll be waiting for Oracle to relicense after you've talked to them.

18 members found this post helpful.

Okay I'll pop a tweet at them on X/Twitter and tag you in it and let's see if they give the old crickets in the bush routine.

Tweet sent... now let's if they even care.

Edit: The real other question I would raise is, why hasn't the FSF and SFC been willing to make an amendment to GPLv2 to fix this issue? There's two sides to every coin, three if you count the edge.

Re-Edit: Glibc being is beta is kind of the same yet different. Beta software isn't stable, even if people think it is. It can be, but it's one of those "let's air on the side of caution for something as fundamentally close to the base layer of the system as possible". I hardly would say you did the wrong thing in avoiding beta class software. Nobody would fault you for alpha-class either or even release candidate being avoided if it really came down to glibc, gcc, etc.

1 members found this post helpful.

He's going for it! Good luck Reaper. I'm watching with great interest.
That's probably not possible without a complete re-write, and I'd suggest that the end result would most likely be substantially removed from the original intention of the GPLv2.

Have you ever heard Linus' talk about why he chose to stick with GPLv2 for the Linux kernel instead of switching to GPLv3? https://www.youtube.com/watch?v=PaKIZ7gJlRU
That makes you unique Patrick. Respect and decency are rare commodities in this world.

5 members found this post helpful.

I don't think a complete rewrite would be needed for GPLv2.

I think at the core, many people would probably like to see ZFS finally be given inclusion but they end up with the "always the license issue" problem, even when open source say "I'm free to all".

I just, in my own way, feel here's a solution to a problem where 2+2=4, here's the 4 to close the question, but something raises up and says "the answer isn't 4 unless you show your work and how you got to 4".

One key aspect I find extremely useful about ZFS, The fact that zpools don't even have to rely on /etc/fstab is kind of a blessing. It's one less worry.

Excuse my curiosity -- Which filesystem rely on /etc/fstab?

This is the most valuable response I see under this topic until now.

5 members found this post helpful.

Very good first step! So you have now abandoned the idea of including openzfs in the kernel.

Then I'd suggest starting with
and propose a plugin to /sbin/mkinitrd. Then you could upload your plugin to SlackBuilds.org and use it with (an upgraded version that supports plugins) of /sbin/mkinitrd.

Unfortunately not.

OpenZFS is a filesystem went very far on the wrong way optimized for high latency devices.

Btrfs is a filesystem optimized for low latency devices, though with serious problems like system lock-ups or floppy-like performance when encountered.

1 members found this post helpful.

The heart of the problem is that you have proprietary and open-source interests seemingly operating together, but quietly in competition with each other.

Open-source software is disruptive to normal business practice... and business doesn't like it.

Richard Stallman published an article about the ZFS/Linux issue: https://www.fsf.org/licensing/zfs-and-linux

"The only permissible way to make available a binary (non-source) work that includes GPL'd material is under the GPL."

1 members found this post helpful.

I think that you already gotten the answer here, OpenZFS will as it seems today not be included in the official Slackware distribution. Your options left are to rely on some third party source (like slackbuilds.org or Alien Bob) to provide you with OpenZFS Slackware packages which you can add to your installation or for someone to make a fork of Slackware and call that fork maybe something like SlashOZFS64.

That someone creating a fork which ships binaries supposed to be linked together even though they have incompatible licenses must be someone like you who don't is afraid to get sued by Linus Torvalds or any of the thousands of contributors to the Linux kernel who has made copyright claims in the Linux kernel source code. Nor should this someone care about the possibility to get sued by Oracle, Intel, the United States Government or any other of the many copyright holders of OpenZFS.

regards Henrik

2 members found this post helpful.

Again, Linus has said he won't pursue it. Nobody except the FSF and SFC raised even any eyebrow. All they did was give the "shame on your speech" to Canonical. Nothing more or less.

How many times does this have to get repeated as a reply? The consensus is, nobody gives a crap about the petty squabbling between GPL and CDDL any longer. The spirot of rhe license might be there for some who do care, but honestly, at the end of the day, as I said, nobody is going to be sued, jailed, imprisoned, executed, or possibly deported for following Ubuntu's suit. If the FSF and SFC wanted to have sued Canonical into the ground, they probably should have done so within the first 48 hours of release. Its been several years, and all we get is a few blog articles attributing to nothing short of sabre rattling. Hell, Stallman could have had Canonical hanged, drawn, and quartered in all regards for violating GPLv2... but nothing happened. Why?