7 ms·

The zfsonlinux developers complained a while ago that some API they were using became GPL only and I think they had to write a wrapper in GPL to get around it.

by icefo 5y ago

The zfsonlinux developers complained a while ago that some API they were using became GPL only and I think they had to write a wrapper in GPL to get around it. I'm on mobile so I can't give you more details but you can probably find more if you look in that direction

vetinari 5y ago
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 5y ago
  > 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 5y ago
    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 5y ago
      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.
- pseudalopex 5y ago
  What documentation said they shouldn't use it?
  - vetinari 5y ago
    > 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 5y ago
      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 https://yarchive.net/comp/linux/kernel_fp.html
- blibble 5y ago
  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 5y ago
    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.

by icefo 5y ago

vetinari 5y ago

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 5y ago
> 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 5y ago
  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 5y ago
    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.
pseudalopex 5y ago
What documentation said they shouldn't use it?
- vetinari 5y ago
  > 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 5y ago
    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 https://yarchive.net/comp/linux/kernel_fp.html
blibble 5y ago
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 5y ago
  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.