[vetinari]

It was API, not API key.

Kernel is GPL, so only GPL modules can touch its internal APIs. For non-derived works, there is a subset of APIs, that are declared to be fine if used by non-GPL code. ZFS had a problem, where they were using something that should not be used (fp in kernel), which got removed and they had to find a replacement, which was GPL-only.

It is also necessary to say, that this is honor-based. Any module declares its license and the linker either allows or not allows resolving a symbol. There are no checks whether the module is really GPL or not, it is to show intent, and if you want to cheat, you must do it willfully, not by accident.

[Dylan16807]

> ZFS had a problem, where they were using something that should not be used (fp in kernel), which got removed and they had to find a replacement, which was GPL-only.

All that symbol did was tell the kernel to save the fpu registers.

It's dishonorable of the relevant kernel developers to pretend that's something relevant to the GPL.

[vetinari]

It was more complicated than that. Some architectures do not support that.

And what's more pressing is, that it is an internal implementation details. Preserving it for ZFS would mean that they have to keep internal implementation detail for an external project, that does not care to cooperate!

These two symbols were obsolete for almost two decades. Should they keep them just for ZFS? Or should ZFS switch? If it were GPL project, or better, part of the kernel, it would be already fixed and everyone would go on with their lives.

[Dylan16807]

There were two sets of exports. __kernel_fpu_begin/end and kernel_fpu_begin/end.

The only meaningful difference was that one was marked GPL and the other wasn't.

Removing the one with __ can be justified pretty easily.

Insisting that the ones they kept should still be marked 'GPL' is where it gets ridiculous. Going in and out of FPU mode is not something that makes your code derivative of the kernel code.

[blibble]

it seems quite clear ZFS is not a derived work of the Linux kernel, given it was developed for and extracted from Solaris, and that same code works on FreeBSD and Illumunos

[vetinari]

Well, obviously, since it is not derived work, how would it know how to interface with internal symbols and use internal defines of the linux kernel?

It would not... unless it becomes derived work.

[pseudalopex]

What documentation said they shouldn't use it?

[vetinari]

> In other words: it's still very much a special case, and if the question was "can I just use FP in the kernel" then the answer is still a resounding NO, since other architectures may not support it AT ALL.

Linus Torvalds, Mon, 10 Mar 2003 20:12:34 GMT

[pseudalopex]

A mailing list message isn't documentation. And that isn't the same as saying no one should use it ever. Especially in context.[1]

[1] https://yarchive.net/comp/linux/kernel_fp.html