ZFS 2.2.0 (RC): Block Cloning merged

Re:ZFS 2.2.0 (RC): Block Cloning merged by Dylan16807 on Tuesday July 04, 2023 @05:17PM (#36592599)

To have legal weight, it has to be a signal that you're implementing something that is derivative of kernel code. That's the directly stated intent of EXPORT_SYMBOL_GPL.

But "call an opaque function that saves SIMD state" is obviously not derivative of the kernel code in any way. The more exports that get badly marked this way, the more EXPORT_SYMBOL_GPL becomes indistinguishable from EXPORT_SYMBOL.

[ Parent | on HN ]

Re:ZFS 2.2.0 (RC): Block Cloning merged by colonwqbang on Tuesday July 04, 2023 @05:52PM (#36592979)

I see it as just a kind of "warranty void if seal broken". Don't do this or you may be in violation of the GPL. Maybe a legal court in $country would find in your favour (I'm not convinced it's as clear cut as you imply). Maybe they would find that you willfully infringed, despite the kernel devs clearly warning you not to do it.

The main "legal effect" I see is that you are not willing to take that risk, just like Oracle isn't.

[ Parent | on HN ]

Re:ZFS 2.2.0 (RC): Block Cloning merged by Dylan16807 on Wednesday July 05, 2023 @07:33AM (#36598855)

If the goal was to prove someone saw the GPL, then the entire license enforcement mechanism wouldn't be in the kernel.

If enough symbols get restricted without valid copyright-based reasons, modules that legitimately have non-GPL licenses will have to lie to the kernel to get loaded. And that's a stupid situation all around.

[ Parent | on HN ]