5 ms·
Microsoft were doing this for ages... From the NT kernel to the shell. To stay above competition, they have tons of different undocumented APIs they keep for th
by orbital-decay 5y ago
Microsoft were doing this for ages... From the NT kernel to the shell. To stay above competition, they have tons of different undocumented APIs they keep for themselves to use, and don't guarantee it to exist or stay unchanged in future. In fact this is the response. Nothing special about this particular one. Developers reverse engineer those, and try to rely on them, all the time.
- kmeisthax 5y agoEvery OS and library has some form of undocumented/internal APIs that they don't want users of that library or OS to be relying upon. Hell, Linux even uses DRM (not the Direct Rendering Manager, Digital Rights Management) to check if your LKM is licensed properly to call those APIs. GPL-incompatible libraries only get to link to functions that are rough equivalents to syscalls.
- pbhjpbhj 5y agoCalling what you describe DRM is pretty deceptive. Can you get access to DRM-ed materials by promising to share them freely under an open license? That said I'm surprised by what you describe as I'm struggling to understand how that works -- you're saying the Linux kernel has a secret API, surely one can read the source and/or documentation and find the API details. Or are you saying calls to kernel APIs are cryptographically protected? Could you give details of what this system is called, thanks.
- icefo 5y agoThe 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 agoIt 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.
- blibble 5y agoit 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 agoWell, 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.
- 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 agoIt 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.
- blendergeek 5y agoUnder the GPL, a "combined work" must also be distributed under the GPL. Given that use of certain kernel APIs requires the inclusion of large GPL'd header files, the kernel developers require that any modules that include this GPL'd code be also released under the GPL. In order to make it more difficult for developers of kernels modules that break the law by running roughshod over the GPL, the kernel developers decided to only make these available to modules that claim to be under the GPL [10]. Please note that module developers can still easily distribute modules that use the "GPL only" APIs but they have to explicitly state that they are using GPL only code (thereby signalling that any copyright infringement is willful). Calling this "DRM" seems a little disingenuous to me. Anybody can legally remove these protections from their own kernels without any legal repercussions. Removing DRM protections (in the USA) is a felony that carries up to five years in prison. DRM is intentionally obfuscated and poorly documented. The kernel makes its license clear and obvious. [0] https://lwn.net/Articles/154602/ https://lwn.net/Articles/154602/
- kmeisthax 5y agoUnder DMCA 1201, this sort of measure would probably be legally considered DRM. All you need is a technical mechanism that controls access to a copyrighted work. You do not need obfuscation or encryption in order to make 1201 claims. Whether or not GPLv2 precludes a DMCA 1201 claim is still in question. On one hand, the GPL says you can make whatever changes you like. On the other, the Linux kernel module loader is specifically enforcing GPL's share-alike requirement, which is a predicate of the right to make modifications to the kernel. This is the heart of what DMCA 1201 is trying to do: extend copyright protection to software that enforces copyright. If Linux had been re-licensed to GPLv3, this wouldn't be an issue, because v3 specifically has a clause intended to disclaim any and all construable technical protection measures under DMCA 1201.