4 ms·
You are talking about separate programs with separate licenses put together in a package of software meant to run together. I'm talking about putting some GPL
by jraph 3y ago
You are talking about separate programs with separate licenses put together in a package of software meant to run together.
I'm talking about putting some GPL code in a program whose code is BSD licensed.
Putting a GPL program in a BSD software distribution would not make the whole package GPL
(However GPL restrictions will apply to the GPL parts and you may not want this in your package of BSD-licensed software)
Of course you can run GPL software on your BSD system, the same way you can run proprietary software on Linux (and BSD).
Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL. Now you can always distribute your BSD-licensed kernel and make your users compile some GPL code into your kernel themselves.
It's just that the GPL code unavailable to people that want to build some proprietary product from your BSD distribution, and as a BSD distribution, you might not want too much of this.
- BSDobelix 3y ago>Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL. NO, absolutely NOT. Not you nor the GPL has the right to re-license someone else code. There are many modules who are not GPL like Nvidia and not even AMD-GPU -> MIT...and still the kernel is GPL, and even the kernel itself has many different (but compatible to GPL2) licenses. If you change GPL code you have to show your changes (if you redistribute the code) if you have MIT/BSD you don't have to make that step, it really has nothing todo if you mix that stuff (if compatible). The maybe ~problem with CDDL/GPL (ZFS) however is, that you redistribute it in binary form.
- jraph 3y agoYou 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 agoThe 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.