Would it be technically (legally) possible for the Linux kernel developers to create a new license (similar to GPLv2) but different in the sense that hardware manufacturers are prohibited from distributing future versions of the Linux kernel with their product if they do not open source their latest drivers' source code for the device?
-
4What do you mean by "technically"? Where it could work technologically? Whether it could work legally? Socially?– curiousdanniiCommented Jun 10, 2019 at 23:53
-
You need to explain what assumptions you're willing to make. Practically, Linux developers will simply not agree to hurt their own baby.– Dmitry GrigoryevCommented Jun 11, 2019 at 11:51
-
1I think this question might be "Notwithstanding the social difficulties in doing so, would it be legally possible to engineer a license for the Linux kernel that would disallow binary blobs?" -- but I'm not 100% sure.– apsillers ♦Commented Jun 11, 2019 at 14:16
-
"What do you mean by "technically"?" Legally– JoshCommented Jun 12, 2019 at 15:14
-
1I don't think that it's morally right that manufacturers want to use open source software to power their product, but then they bundle blob drivers. We as an open source community have shared our code with them. But they won't share the code necessary to make the hardware we pay for function at a basic level (eg: display drivers, camera). So consumers are in a situation where the manufacturer moves on, and their device most likely becomes increasingly less useful to the point of being trash just because of some ridiculous unnecessary secrecy. I'm not talking about open sourcing app code.– JoshCommented Jun 12, 2019 at 15:25
|
Show 2 more comments
3 Answers
The GNU GPL already limits, to the maximum extent possible under copyright law, the ability to include proprietary drivers in the Linux kernel. Kernel drivers already must be licensed under the GNU GPL in order to be distributed within Linux.
The workaround that you are concerned about in asking this question is the practice of a including a "wrapper" kernel driver that is designed to link to or otherwise execute a non-GPL-licensed "binary blob" of code, external to the driver itself. In this case, the legal reality is either that
The binary blob is part of the same work, under copyright law, as the GPL-licensed driver, in which case it is indeed a GPL violation to distribute the blob without source. Such a legal conclusion, if true, would satisfy your requirement perfectly.
The binary blob is a separate work, under copyright law, that is distinct from the wrapper driver that uses it. In this case, the copyright license like the GPL cannot impose requirements on an unrelated copyrighted work.
The GPL's copyleft provisions can successfully operate as they do because new code that enters into combination with a GPL-licensed work becomes part of a derivative work of the GPL'd work. Since the preparation of distribution of derivatives is an exclusive right of the copyright holder, the GPL may limit this activity by regulating how it licenses to downstream users the right to prepare derivatives. By contrast, if the blob is not part of a derivative, then no copyright license terms may impose requirements on it, and it is not possible to construct a copyright license that operates in the way you request.
Thus, it is either the case that the GPL already satisfies your requirements, or no copyright license can do so. (I do not attempt to resolve this disjunction here.)
I suppose it might be possible to draft contract terms that prohibit use of binary blobs, in much the same way that I suppose it may be possible to draft contract terms that impose any arbitrary requirement (e.g., "I'll let you modify and distribute this software but only if you do so while holding your breath underwater"), but I don't know enough about contract law versus copyright licensing to say how this would operate differently from a copyright license in practice. In particular, I'm not sure if, how, or when you would need the downstream user's agreement to the contract terms.
answered Jun 12, 2019 at 18:31
-
It is perfectly fine by the GPL to distribute stuff that only the end user combines to create a whole, if that is never distributed further. The very tricky part would be to make sure the separate, closed source, piece is really a separate work, not based on the kernel.– vonbrandCommented Jun 17, 2019 at 13:34
There are a few issues.
First, there is no one group that holds all copyrights to the kernel code. Hundreds if not thousands of contributors and corporations, all of which must OK re-licensing the kernel. Given that some are dead, etc. that likely won't happen.
Secondly, it is already a requirement to release via GPLv2 any kernel code or modifications. This means the closest you'll get to a proprietary driver in the kernel is a F/OSS wrapper to a binary blob, much like the NVidia drivers or wireless drivers/firmware using the ndiswrapper utility.
Note that on a technical level, the kernel will complain (and loudly) about being tainted with non-free code if you are using a wrapper and non-free binary blob.
Does distributing a nonfree driver meant to link with the kernel Linux violate the GPL? (#NonfreeDriverKernelLinux)
Linux (the kernel in the GNU/Linux operating system) is distributed under GNU GPL version 2. Does distributing a nonfree driver meant to link with Linux violate the GPL?
Yes, this is a violation, because effectively this makes a larger combined work. The fact that the user is expected to put the pieces together does not really change anything.
Each contributor to Linux who holds copyright on a substantial part of the code can enforce the GPL and we encourage each of them to take action against those distributing nonfree Linux-drivers.
Now, as far as I understand, the reality is that closed source drivers for the Linux kernel exist. Nvidia being a big example. Nvidia's license that you agree to when downloading their drivers is a non-free license. (See below for reasoning.) Is it illegal? The FSF seems to think so and encourage major Linux contributors to take action. And yet, for as long as I can remember there have been easy ways to get proprietary drivers to work with Linux based operating systems. This may be a case of there not being specific case law yet or the major Linux contributors not wanting to bother pursuing for whatever reason.
For completeness' sake, "You may not reverse engineer, decompile, or disassemble the SOFTWARE provided in binary form, nor attempt in any other manner to obtain source code of such SOFTWARE." is an example of a non-free clause in Nvidia's license. This goes against FSF's definition of free which includes studying OSI's OSD 2 which says the source must be included.
