3 ms·

You can link MIT code to a GPL kernel just fine, the whole thing would be under GPL (though of course you can take the MIT part use it permissively). But I'm ta

by jraph 3y ago

You can link MIT code to a GPL kernel just fine, the whole thing would be under GPL (though of course you can take the MIT part use it permissively). But I'm talking about the opposite thing. Distributing a BSD kernel with a GPL module. This would be under GPL as well (but again, you can take the BSD part and use it permissively). This is exactly what people talk about when they say the GPL "contaminates" and this works with the BSD and the MIT licenses because these licenses are known to be GPL-compatible. This is also by the way what people mean when they say a license is compatible with the GPL. While you don't relicense other people's code, the package you create by mixing GPL and MIT code is under GPL. You of course don't have all the rights the MIT grants on the whole package, only the rights common to the GPL and the MIT, which are exactly the rights that the GPL provides since the GPL is strictly more restrictive than the MIT. You are mentioning NVidia and this actually illustrates my point: nobody distributes the Linux kernel with the NVidia driver because you can't, because of the GPL that forbids you from linking GPL with proprietary code and distributing the result. Instead, you make the user download the kernel, download the nvidia driver and then compile the module locally. That's why we have DKMS. It's a hack around the distribution limitations. Of course it doesn't please the Linux kernel developers too much and that why they have the GPL-only symbols (things that only work if your module is GPL-compatible). The CDDL/GPL issue of ZFS is the same thing: you just can't distribute the whole thing together if you consider that the licenses are not compatible or don't want to take the risk. Ubuntu certainly does take it but not the rest of the world. Also no need to get upset, let's have a calm argument, please?

BSDobelix 3y ago
>Also no need to get upset, let's have a calm argument, please? Yes and i am totally fine with your latest explanation, however you wrote: >Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL. And that's just wrong, just because i run a GPL-Driver on Windows make Windows not GPL, and just because i run a GPL-Driver in a BSD makes BSD not GPL, it just means, that package has many licenses and the most restrictive but compatible is (for example) the GPL, so you probably want to follow it's rules.
- jraph 3y ago
  The more careful and accurate phrasing of my sentence: >Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL. Would be: "Any distribution of a kernel with a GPL driver needs to be under GPL and requires the kernel to be under a GPL compatible license." (I implied distribution because as long as something is not distributed, nothing matters in terms of licensing when it comes to free software licenses.) Since installing yourself a GPL module in any kernel doesn't constitute a distribution, the direct consequence is that the module and the kernel are distributed separately in such incompatible cases. Which would also be true of GPL drivers on Windows, but the kernel is always distributed alone by Microsoft and the GPL driver by the vendor (while for Linux, distributions could decide to compile the kernel with third-party modules - not sure how the BSD world works in this regard) so the situation is somewhat easier to understand. Now, distributing GPL code explicitly meant to be linked to the Windows kernel might be a grey area and probably requires all the authors to agree to this. Like, it's not 100% clear to me whether you can take some random GPL code and put it in a GPL driver explicitly intended to be linked to the Windows kernel even if you don't distribute the result yourself. I guess that would be somewhat similar to the ZFS on Linux project though: while everyone writes CDDL code, ZFS on Linux is clearly intended to be linked to the GPL'd Linux kernel. Thanks for expecting me to be accurate and holding me to higher standards, that's appreciated.
  - BSDobelix 3y ago
    >Thanks for expecting me to be accurate and holding me to higher standards, that's appreciated. Well you did the same to me, so i have to thank you too ;) BTW: Absolutely on par with you last comment.
  - jasomill 3y ago
    IANAL, but Oracle's lawyers are, and they see no problem distributing GPL 2-licensed Windows drivers for VirtualBox[1], in both source and binary form, so, in the absence of evidence to the contrary, neither do I. I suspect Windows driver signing requirements may conflict with GPL 3, however, because running Windows in test-signing mode interferes with the normal operation of popular Windows software (e.g., games that require anti-cheat software deliberately incompatible with test-signing mode in general). OTOH, Windows itself runs just fine in test-signing mode, and surely the fact that other software deliberately chooses not to run if a test-signed driver is installed doesn't imply that Windows is incompatible with test-signed drivers, and therefore GPL 3, so it's hard to say, but I'd personally talk to a lawyer before creating or distributing a GPL 3-licensed Windows driver. Here's a copy of the click-through license from the latest Windows Driver Kit installer, which, to my non-lawyer eyes, doesn't appear to place any restrictions on use or distribution of drivers created with it, in source or binary form: https://jasomill.at/wdk-license.html https://jasomill.at/wdk-license.html Obviously any individual or project using proprietary headers under this license to build a driver would have to accept its terms, but this is no different than, e.g., using proprietary headers under the Xcode license to build GPL software for macOS, and the FSF, at least, seems to be fine with this, given that the Emacs project recommends[2] a macOS binary distribution[3] that does precisely this[4], so I assume it's okay. [1] https://github.com/mirror/vbox/blob/master/src/VBox/Additions/WINNT/Graphics/Video/mp/wddm/VBoxMPCm.cpp https://github.com/mirror/vbox/blob/master/src/VBox/Addition... [2] https://www.gnu.org/software/emacs/download.html#macos https://www.gnu.org/software/emacs/download.html#macos [3] https://emacsformacosx.com/ https://emacsformacosx.com/ [4] https://git.savannah.gnu.org/cgit/emacs.git/tree/configure.ac?h=emacs-29.3#n2103 https://git.savannah.gnu.org/cgit/emacs.git/tree/configure.a...

by jraph 3y ago

BSDobelix 3y ago

>Also no need to get upset, let's have a calm argument, please? Yes and i am totally fine with your latest explanation, however you wrote: >Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL. And that's just wrong, just because i run a GPL-Driver on Windows make Windows not GPL, and just because i run a GPL-Driver in a BSD makes BSD not GPL, it just means, that package has many licenses and the most restrictive but compatible is (for example) the GPL, so you probably want to follow it's rules.

jraph 3y ago
The more careful and accurate phrasing of my sentence: >Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL. Would be: "Any distribution of a kernel with a GPL driver needs to be under GPL and requires the kernel to be under a GPL compatible license." (I implied distribution because as long as something is not distributed, nothing matters in terms of licensing when it comes to free software licenses.) Since installing yourself a GPL module in any kernel doesn't constitute a distribution, the direct consequence is that the module and the kernel are distributed separately in such incompatible cases. Which would also be true of GPL drivers on Windows, but the kernel is always distributed alone by Microsoft and the GPL driver by the vendor (while for Linux, distributions could decide to compile the kernel with third-party modules - not sure how the BSD world works in this regard) so the situation is somewhat easier to understand. Now, distributing GPL code explicitly meant to be linked to the Windows kernel might be a grey area and probably requires all the authors to agree to this. Like, it's not 100% clear to me whether you can take some random GPL code and put it in a GPL driver explicitly intended to be linked to the Windows kernel even if you don't distribute the result yourself. I guess that would be somewhat similar to the ZFS on Linux project though: while everyone writes CDDL code, ZFS on Linux is clearly intended to be linked to the GPL'd Linux kernel. Thanks for expecting me to be accurate and holding me to higher standards, that's appreciated.
- BSDobelix 3y ago
  >Thanks for expecting me to be accurate and holding me to higher standards, that's appreciated. Well you did the same to me, so i have to thank you too ;) BTW: Absolutely on par with you last comment.
- jasomill 3y ago
  IANAL, but Oracle's lawyers are, and they see no problem distributing GPL 2-licensed Windows drivers for VirtualBox[1], in both source and binary form, so, in the absence of evidence to the contrary, neither do I. I suspect Windows driver signing requirements may conflict with GPL 3, however, because running Windows in test-signing mode interferes with the normal operation of popular Windows software (e.g., games that require anti-cheat software deliberately incompatible with test-signing mode in general). OTOH, Windows itself runs just fine in test-signing mode, and surely the fact that other software deliberately chooses not to run if a test-signed driver is installed doesn't imply that Windows is incompatible with test-signed drivers, and therefore GPL 3, so it's hard to say, but I'd personally talk to a lawyer before creating or distributing a GPL 3-licensed Windows driver. Here's a copy of the click-through license from the latest Windows Driver Kit installer, which, to my non-lawyer eyes, doesn't appear to place any restrictions on use or distribution of drivers created with it, in source or binary form: https://jasomill.at/wdk-license.html https://jasomill.at/wdk-license.html Obviously any individual or project using proprietary headers under this license to build a driver would have to accept its terms, but this is no different than, e.g., using proprietary headers under the Xcode license to build GPL software for macOS, and the FSF, at least, seems to be fine with this, given that the Emacs project recommends[2] a macOS binary distribution[3] that does precisely this[4], so I assume it's okay. [1] https://github.com/mirror/vbox/blob/master/src/VBox/Additions/WINNT/Graphics/Video/mp/wddm/VBoxMPCm.cpp https://github.com/mirror/vbox/blob/master/src/VBox/Addition... [2] https://www.gnu.org/software/emacs/download.html#macos https://www.gnu.org/software/emacs/download.html#macos [3] https://emacsformacosx.com/ https://emacsformacosx.com/ [4] https://git.savannah.gnu.org/cgit/emacs.git/tree/configure.ac?h=emacs-29.3#n2103 https://git.savannah.gnu.org/cgit/emacs.git/tree/configure.a...