More context: https://marc.info/?l=linux-kernel&m=154722999728768&w=2

> 5.0 removes the ability from non-GPL modules to use the FPU or SIMD instructions

That’s a pretty good reason to stay on 4.x IMO. Talk about shooting yourself in the foot.

Optionally, we may expect distros like Ubuntu simply reverse that change to not ruin their own packages.

Also...

> My tolerance for ZFS is pretty non-existant.

Greg seems like a really pragmatic, nice and agreeable chap. Bet he’s a big hit at parties.

> Optionally, we may expect distros like Ubuntu simply reverse that change to not ruin their own packages.

If they want to earn the ire of the Linux kernel developers, sure. But they won't do that, especially if they employ kernel developers. That's a scummy thing to do.

It is complete bull to claim that loading and saving the FPU state makes a piece of code inherently derivative of GPL code such that it must itself be GPL. Calling that bluff may draw ire but it is not scummy.

Previous title had "...with Linux 5.0 compatibility". The significance of this is that 5.0 changed some interfaces used by ZFS to require GPL license, which ZoL can't call, which generated some discussion https://lore.kernel.org/lkml/[email protected]...

Wouldn’t it be possible to create an intermediate GPL licensed kernel-module which simply re-exported the relevant exports so that other kernel-modules could use the exports provided by this module instead?

It could have a neat name too, like “gplbridge” or whatever (all associations with License-trolls only partially intended). That way they wouldn’t have remove optimized code for Linux 5+ users.

Dirty, utterly pointless, but it would get the job done, right?

Imagine standing in court explaining to a non-technical judge and jury how this "bridge" transforms the copyrighted work into two fully separated works rather than a single derivative work. Do think it would work?

Personally I think one has a better time arguing that kernel modules simply interface with the kernel rather than creating a derivative work, thus making any module independent from the license of the kernel. The case law around "interfacing" is conflicting, but at least a few cases has gone in favor of the accused.

The original title mentioned that ZFS now have support for Linux Kernel version 5, which is something that have been discussed before since the kernel maintainers don't like the hooks that zfsonlinux uses, it was discussed on HN but I can't find it, the discussion sprung up because of this message: https://lore.kernel.org/lkml/[email protected]...

The previous discussion was here: https://news.ycombinator.com/item?id=19018185

There was a recent controversy in which the Linux kernel removed some functions which were being used by the ZFS module, but their replacement are "GPL-only" functions which cannot be used by the ZFS module. This release has a workaround for that, so it can be compiled for Linux 5.0.

(IIRC, the original title of this submission had " with Linux 5.0 support" at the end, indicating why this release is newsworthy, but I'm not seeing it anymore.)

That's how I like my file systems updates, anything not particularly noteworthy.