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?

  • 4
    What do you mean by "technically"? Where it could work technologically? Whether it could work legally? Socially? 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. Jun 11, 2019 at 11:51
  • 1
    I 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
    Jun 11, 2019 at 14:16
  • "What do you mean by "technically"?" Legally
    – Josh
    Jun 12, 2019 at 15:14
  • I 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.
    – Josh
    Jun 12, 2019 at 15:25

2 Answers 2


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.

  • 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.
    – vonbrand
    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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.