0

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?

MadHatter
  • 48,547
  • 4
  • 122
  • 166
Josh
  • 21
  • 1
  • 4
    What do you mean by "technically"? Where it could work technologically? Whether it could work legally? Socially? – curiousdannii Jun 10 '19 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 Grigoryev Jun 11 '19 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 '19 at 14:16
  • "What do you mean by "technically"?" Legally – Josh Jun 12 '19 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 '19 at 15:25
  • @DmitryGrigoryev Perhaps I'm ignorant about how the hardware industry works, but I don't think it would hurt manufacturers if they release open source drivers for their hardware. They are selling hardware. Currently they have no incentive to not be selfish. But with such a change, they'd have to accept the minor inconvenience of sharing driver code. And it may necessitate them changing the way they design their software, slightly. – Josh Jun 12 '19 at 15:30
  • For example imagine a camera on a mobile phone, doing fancy post-processing. If a manufacturer is lazy and selfish they might just slap all the post-processing code in the blob driver. But if they're forced to release the latest version of a working driver for the hardware, then the open source driver just grabs the raw frames from the camera, and they do their fancy post processing in their closed source application code.

    I don't have any problem with closed source software. Just unnecessarily turning what would be good hardware, into bricks.

     – Josh Jun 12 '19 at 15:32

2 Answers2

5

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.

apsillers
  • 35,995
  • 4
  • 94
  • 131
  • 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 '19 at 13:34
3

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.

ivanivan
  • 1,015
  • 1
  • 6
  • 10