3 ms·

Sorry to hiijack this, but you seemed knowledgeable about a topic we were discussing about. As we don't have DMs in HN, I have to do it like this... Would you

Sorry to hiijack this, but you seemed knowledgeable about a topic we were discussing about. As we don't have DMs in HN, I have to do it like this... Would you please help me understand better your points about the GPL (linking vs. replacing)? Thank you!

kmeisthax 5y ago
For those following along, that prior comment is https://news.ycombinator.com/item?id=30429582 https://news.ycombinator.com/item?id=30429582 and I had to dig it out from a prior HN replies page. To put it very, very short: maybe you can write proprietary LKMs that replace kernel functions. The difference between linking and replacing is as follows: - When I either write a library[0] or use one in my executable[1], I am writing code that is explicitly intended to be joined with someone else's. From a copyright perspective, that constitutes the creation of a derivative work. - When I want to replace a library, I am writing code that is intended to allow me to stop using someone else's code. The only thing retained is the interface between the library and the executable using it. From a copyright perspective, this is either fair use of the interface's declaring codes in specific cases[2], or the interface itself is uncopyrightable[3]. For the record, this isn't a GPL thing; this is just how copyright law works. In fact, it's evidence that software was ill-fitted for copyright protection. People rarely, if ever, distribute other types of creative works as, say, transparent overlays intended to be placed on top of works they don't own. And the idea of there being some kind of "interface" between the overlay work and the original, where I can then redraw the original to evade the copyright on it, is entirely antithetical to how copyright is supposed to work.[4] Now, with that out of the way... what you're asking about is linking, because the rest of Linux still remains after you replace the GPL part with your own proprietary code. So the entire GPL still applies to the entire "program", minus Linus's interpretation of being able to host separate programs in one address space as long as they only use symbols equivalent to userspace ABI. For what it's worth, this is how Nvidia drivers work: they have a proprietary LKM that exposes device nodes that their OpenGL/Vulkan libraries access to control the GPU. However, Nvidia got lucky here in that Linux graphics have traditionally been handed in userspace. If, say, X11 was GPL; then the legal workaround they use wouldn't work. I have no idea if the Linux network stack is pluggable to the point where you could link in your own. I do know they have to deal with frustratingly-proprietary Wi-Fi drivers, so I'm assuming (without much evidence) that drivers are pluggable and Linus considers the API surface to be OK for non-GPL code to touch. Most kernel infringements occur because the infringers are incompetent, not malicious. Anticheat and DRM vendors don't want to touch Linux because it's a small market - not because it's illegal to release LKMs with their code in it. Also, you didn't ask for this, but I did want to mention that it is possible to "link" in so much code that none of the original remains. This is how BSD came about. However, unlike reimplementation from interfaces, there's no court precedent in favor of "tracing over" a program ship-of-Theseus style. The only reason why this doesn't pose a risk to BSD users is because lawsuits about this already happened in the late 80s, and were settled out of court. [0] "Library" here is more general than, say, a .dll, .dylib, or .so file. It means any code intended to be used by another program to carry out a function. So things like a BIOS ROM, NPM dependency, or OS kernel would all be "Library" code. [1] "Executable" here is more general than an .exe or .app bundle. It means any program designed to make use of other code that it does not contain within itself. So things like a console game, Node.js script, or Windows app would all be "Executable" code. [2] The US 9th Circuit has controlling precedent for fair use in the case of compatibility; and SCOTUS brought in the concept of "programmer convenience" as a fair use justification for copying API declarations. [3] APIs are not considered copyrightable subject matter in the EU. The US Court of Appeals for the Federal Circuit holds that they are. Other US courts have not ruled either way - not even SCOTUS, they just said "if they are copyrightable then Google did a fair use". [4] In fact, this is the reason why the lawyer that runs the FOSS Patents blog consulted for Oracle in the Android case. As far as he cared, Android was a GPL violation, and damn the entire rest of the software industry for thinking that copyright ended at interfaces.
- ladyanita22 5y ago
  Thank you for your reply. Unfortunately, I don't have a very clear understanding (probably nobody does). As far as I understand, when "running two programs in the same address space" (this is, LKMs), it's fine to have non-GPL compatible modules as long as these don't interact with GPL DRMed symbols. You can have self-contained stuff and that won't be an issue. You could also no licensing limitations if you replaced every single module that's GPLed and DRMed with your own isolated modules, but that'd of course break the compatibility with the upstream-based stuff and would only work for very tailored scenarios. What I'm asking about is not actually linking, right? To link something I'd need to import kernel symbols. I could always create a self-isolated subsystem that just runs in kernelspace but works on its own without importing stuff from the kernel, as long as I'm willing to put the effort.

kmeisthax 5y ago

For those following along, that prior comment is https://news.ycombinator.com/item?id=30429582 https://news.ycombinator.com/item?id=30429582 and I had to dig it out from a prior HN replies page. To put it very, very short: maybe you can write proprietary LKMs that replace kernel functions. The difference between linking and replacing is as follows: - When I either write a library[0] or use one in my executable[1], I am writing code that is explicitly intended to be joined with someone else's. From a copyright perspective, that constitutes the creation of a derivative work. - When I want to replace a library, I am writing code that is intended to allow me to stop using someone else's code. The only thing retained is the interface between the library and the executable using it. From a copyright perspective, this is either fair use of the interface's declaring codes in specific cases[2], or the interface itself is uncopyrightable[3]. For the record, this isn't a GPL thing; this is just how copyright law works. In fact, it's evidence that software was ill-fitted for copyright protection. People rarely, if ever, distribute other types of creative works as, say, transparent overlays intended to be placed on top of works they don't own. And the idea of there being some kind of "interface" between the overlay work and the original, where I can then redraw the original to evade the copyright on it, is entirely antithetical to how copyright is supposed to work.[4] Now, with that out of the way... what you're asking about is linking, because the rest of Linux still remains after you replace the GPL part with your own proprietary code. So the entire GPL still applies to the entire "program", minus Linus's interpretation of being able to host separate programs in one address space as long as they only use symbols equivalent to userspace ABI. For what it's worth, this is how Nvidia drivers work: they have a proprietary LKM that exposes device nodes that their OpenGL/Vulkan libraries access to control the GPU. However, Nvidia got lucky here in that Linux graphics have traditionally been handed in userspace. If, say, X11 was GPL; then the legal workaround they use wouldn't work. I have no idea if the Linux network stack is pluggable to the point where you could link in your own. I do know they have to deal with frustratingly-proprietary Wi-Fi drivers, so I'm assuming (without much evidence) that drivers are pluggable and Linus considers the API surface to be OK for non-GPL code to touch. Most kernel infringements occur because the infringers are incompetent, not malicious. Anticheat and DRM vendors don't want to touch Linux because it's a small market - not because it's illegal to release LKMs with their code in it. Also, you didn't ask for this, but I did want to mention that it is possible to "link" in so much code that none of the original remains. This is how BSD came about. However, unlike reimplementation from interfaces, there's no court precedent in favor of "tracing over" a program ship-of-Theseus style. The only reason why this doesn't pose a risk to BSD users is because lawsuits about this already happened in the late 80s, and were settled out of court. [0] "Library" here is more general than, say, a .dll, .dylib, or .so file. It means any code intended to be used by another program to carry out a function. So things like a BIOS ROM, NPM dependency, or OS kernel would all be "Library" code. [1] "Executable" here is more general than an .exe or .app bundle. It means any program designed to make use of other code that it does not contain within itself. So things like a console game, Node.js script, or Windows app would all be "Executable" code. [2] The US 9th Circuit has controlling precedent for fair use in the case of compatibility; and SCOTUS brought in the concept of "programmer convenience" as a fair use justification for copying API declarations. [3] APIs are not considered copyrightable subject matter in the EU. The US Court of Appeals for the Federal Circuit holds that they are. Other US courts have not ruled either way - not even SCOTUS, they just said "if they are copyrightable then Google did a fair use". [4] In fact, this is the reason why the lawyer that runs the FOSS Patents blog consulted for Oracle in the Android case. As far as he cared, Android was a GPL violation, and damn the entire rest of the software industry for thinking that copyright ended at interfaces.

ladyanita22 5y ago
Thank you for your reply. Unfortunately, I don't have a very clear understanding (probably nobody does). As far as I understand, when "running two programs in the same address space" (this is, LKMs), it's fine to have non-GPL compatible modules as long as these don't interact with GPL DRMed symbols. You can have self-contained stuff and that won't be an issue. You could also no licensing limitations if you replaced every single module that's GPLed and DRMed with your own isolated modules, but that'd of course break the compatibility with the upstream-based stuff and would only work for very tailored scenarios. What I'm asking about is not actually linking, right? To link something I'd need to import kernel symbols. I could always create a self-isolated subsystem that just runs in kernelspace but works on its own without importing stuff from the kernel, as long as I'm willing to put the effort.