@i2 I just had a look it's still CDDL.

Yea this is sadly the thing that's been pestering the ZFS inclusion for a long time. Some distributions have done it "yolo" style, and it seams to have been working.. But it's not the right path. So the best thing would be if they could change their licensing choice to something that is known to work with GPL, like MIT or BSD+GPL. It would make it easier to include into projects.

I love ZFS, it's one of my favorites for a lot of reasons, I just can't commit to it because of their legal choices.

I started a discussion, not surrounding CDDL but asking if there's a plan/willingness to change this, and if so what that would look like. I know this has been covered in various shards before, but I'm asking for myself to better understand here: openzfs/zfs#12736

I don't want to use it as a "popularity vote" or anything, I just want to know more about their plans and if and why it may not be a topic on their OpenZFS summits. But that's about all I can do for this project and any other project I'm involved in. The rest is up to the OpenZFS community.

I'm a avid user of both BSD and Linux, and I use both ZFS and BTRFS (as well as others) so I personally just "want this to work" : )

Correct :) And there's no way for them to change the licensing model.
So either Linux people have to cave in and accept the license and adoption on a broader front - or they have to re-write everything. I don't see either of those happening in a near future.

I guess I am still confused why that’s a hard requirement given ZFS exists in the AUR. If you take the them at their word that it’s a licensing issue, then wouldn’t that still effectively be hosting it? If that’s fine, I don’t see how it would be any more risky to have the hypothetical ZFS module of archinstall simply reference those PKGBUILDs or even grab the openZFS Arch repo and install it on the system.

I guess I am still confused why that’s a hard requirement given ZFS exists in the AUR. If you take the them at their word that it’s a licensing issue, then wouldn’t that still effectively be hosting it? If that’s fine, I don’t see how it would be any more risky to have the hypothetical ZFS module of archinstall simply reference those PKGBUILDs or even grab the openZFS Arch repo and install it on the system.

AUR is an arch USER repository, but it is not officially maintained by the Arch project, rather the community. ArchInstall has a hard no-AUR rule, and won't install anything from it. @Torxed and other Arch Linux maintainers will likely not budge on this, for good reason.

Ok, fair enough. I disagree, but I guess the recent addition of external plug-in support is a nice compromise.