How to embed a proprietary driver with Linux on a device?

Question

We are a manufacturer of CNC controllers devices (computer numerical control): this is a special type of computer designed to control Mills, Lathes, etc. We would like to add a new range of devices with Linux at it core.

The CNC controller would be sold as a whole: the hardware with Linux and our proprietary software which include a driver.

It might be worth mentioning that the device is sold as a specific purpose embedded system, where the user mostly only interacts with our GUI, BUT, it can be connected to the Internet, a mouse, a keyboard, and eventually, the software could be upgraded.

The Kernel of Linux seems to be (at least some of the Kernel Modules API) under GPLv2 (partially with a syscall-note), this seems like a full blocker for proprietary drivers. However, I can see several companies selling proprietary drivers (NVidia, Google...), so I am not sure how is this achieved.

I am a big fan of open-source, but unfortunately, making our software public is not a possibility (and is not under my decision).

My question is:

How can a proprietary driver be installed with a Linux system and provided with a device?

Different points of view

To explain a little bit more about why all this is so confusing to me:

Binary blobs When I read about proprietary drivers on Linux, the solution usually pops as "Binary blobs", which I understand to be a compiled version of the driver's proprietary code, loaded at runtime by a minimalist GPLv2 driver.

If this is correct, how is this different than LGPL loading dynamically a library? (1)

Shipment of proprietary with GPLv2 If the limitation is that the blob shall not be provided together with the GPLv2 driver: is this a blocker to selling a device with Linux and the driver installed? (2)

Syscall-note Some sources mention that the only use of the syscall API (with Tovald syscall-note in the license) is legal. If this is true, it is not clear to me why some companies are having all those concerns making binary blobs, and why the mechanism of tainted kernels exists. (3)

Limit between firware and software Finally, some texts mention that the limit between firmware and software is about the possibility to upgrade or install software on the device. Does this mean that we shall make it not possible (or at least not trivial) to upgrade our device in order to be compliant with Linux Kernel GPLv2 license? (4)

Some related questions:

Develop Proprietary Linux Driver

Answer 1

This is kind of... an open problem. A lot of Linux systems find different ways to link binary blobs of proprietary drivers to GPL-licensed OS libraries, and... they might all run afoul the GPL, and people just kind of turn a blind eye because enforcing those issues might make Linux systems useless. Runtime linking = dynamically linking, which means the driver source code would be subject to the GPL.

One common answer is to give the user the option of whether or not to install the proprietary driver. This might not actually legally help the company that owns the driver, or the distributor, but it might factor into everybody just turning a blind eye to it.

There might be ways to keep your driver code at arm's length from the GPL code using standard API calls that don't require linking, or something like that. This is a case-by-case question, and to dig into it, you'd want to hire an attorney and have your developers in the meeting.

I am not your attorney and this is not legal advice.

Answer 2

How can a proprietary driver be installed with a Linux system and provided with a device?

The first option to investigate is if you can create a user-space driver.

Depending on how the communication with the CNC machine works, this might mean splitting your driver in two parts: One part that just handles the communication with the hardware on its most basic level and runs in kernel space and another part that contains all the interesting intellectual property that you want to protect and runs in user space.

If you are lucky and you are using a fairly standard protocol to communicate with the hardware, there might even already be a existing driver for the kernel space part. Otherwise, you would need to create your own driver under the GPLv2.

If the kernel and user space parts only communicate with each other over the syscall interface, then the syscall-note gives you permission to keep the user-space code under a GPL-incompatible closed-source library.