Can I modify a GPLv2 licensed kernel module without having the rest of my software GPLv2?

Question

The company that I work for, develops a Linux-based in-house distro, which powers some hardware-based equipment. The project that I am working on, has some proprietary kernel modules, and proprietary user-space components, which contain important business logic.

We are currently in the process of integrating a graphics card, for which we need to compile an out-of-tree GPLv2 kernel module (we have the source code available). As our kernel version is a bit old, we will most likely need to patch the driver, so that it compiles against our kernel. We might also need to patch it, if we find some bugs in the existing code, or if we find some optimizations.

My questions are the following:

If I modify the driver, what are my obligations, according to the GPLv2 license?

1. Is it enough, if I publish the driver source code, along with the modified patches if anyone asks for them,
2. Or does the license also extend to the other (proprietary kernel modules and userspace) components in the system?

The rest of the proprietary components (kernel and user-space), make use of the driver, through standard OS interfaces (i.e ioctl calls.)

Having to release the (modified) source code (or patches) for the graphics card kernel module is fine for my company, but releasing all the existing proprietary code as open-source is a deal-breaker. I would definitely intend to talk my company into upstreaming any optimizations that we find, but some patches may be just in order to compile the code, and make it work without crashes on our kernel. So, the chance for the latter category of getting upstreamed, might be close to zero.

The person responsible for the Legal part in my company, seems to interpret the license in the most risk-adverse way, but I am not entirely sure that he understands software. Basically, if I were to follow his opinion, my only option would be to ask the company that produces the graphics card, to license to us the driver under a separate (non-GPLv2) license. I'm not sure if this is possible.

The other option that I would think of, is some kind of trickery, so that we move all our existing code from our kernel modules into user-space, and keep a kind of dummy code in the kernel, that we can release under GPL. But this seems too extreme to me, and I would leave it as a last resort option.

Also, I would like to know who might sue the company in case of breach of GPL. Is it only the company that produces the graphics card ?

As I don't have a lot of experience in dealing with open-source I would like to ask the members of the community, if they found themselves in a similar situation, and what would they advise me.

Answer 1

Userspace is fine.

According to the syscall exception, regular programs that interface with the kernel "by normal system calls" are not subject to GPLv2 obligations. If your userspace program interfaces with the kernel in a more intimate fashion than "normal" system calls, then this exception might not apply, but the vast majority of userspace code falls under this exception and is not subject to the kernel's licensing rules.

Proprietary modules might not be.

If you have developed a proprietary kernel module, it may or may not be a derived work of the kernel. This is a gray area, and there have been some high-profile disagreements over it in the past (particularly with regards to the ZFS filesystem). In general, it is safest to assume that the GPL covers any and all kernel modules, or to consult a copyright attorney for specific advice on your individual module.

The graphics driver has no bearing on any of this.

Either your proprietary kernel module is subject to the GPL, or it isn't. The existence and disposition of the graphics driver does not affect any of your obligations with regards to other kernel modules.

I am assuming, of course, that you have not reused any of the graphics driver's code in the proprietary modules, and that the proprietary modules are fully independent of the graphics driver. If this is not the case, then the proprietary modules might also be a derivative work of the graphics driver, in addition to being a derivative of the kernel. That doesn't change any of your obligations, it just means a larger set of people will be able to sue you if you violate them.

However, if you distribute a single kernel containing both your proprietary modules and the graphics driver, then that binary might be a derivative of both the kernel and the graphics driver, meaning you would be liable to the maker of the graphics driver in addition to the Linux kernel contributors.

Regardless, there's simply no obvious way for the graphics driver to change your proprietary modules from "not subject to the GPL" to "subject to the GPL." The bottom line is that you need to make sure that your proprietary modules comply with the GPL, regardless of whether you decide to add this graphics driver or not.

The GPL attaches at time of distribution, not at time of creation.

If you never distribute any of your software to third parties (employees don't count), then none of the GPL's obligations attach, meaning you can do whatever you want as long as you never distribute the software. If you do distribute your software, then the GPL's obligations attach with respect to that distribution, meaning that you are only required to provide source code to the recipient, not to the general public. However, since you will be giving the software to the recipient under the GPL, they will be able to exercise all of the usual GPL rights, including the right to further redistribute it to third parties or to the general public. This right cannot be restricted or abrogated by a separate agreement, as the GPL expressly prohibits such "additional restrictions."

Who would sue you?

It depends.

• If you don't violate the GPL, probably nobody.
• If you redistribute code under a more restrictive basis than what the GPL requires, then the upstream copyright holder (i.e. the Linux kernel contributors, individually or collectively) can sue you for breaching the GPL and infringing their copyright. But if they never find out about it, then such a lawsuit is unlikely in practice.
• If your downstream recipient is unhappy about being cut out of their GPL-required rights, then they might contact an upstream copyright holder and ask them to file suit. There has been at least one case of a downstream recipient directly suing for specific performance, but that case has yet to be decided. The legal theory is not wholly implausible, but it will depend on a number of unsettled legal issues, including whether the GPL is a contract and whether specific performance is available as a remedy. This is also likely to vary with jurisdiction, so you should consult an attorney if concerned about this possibility.
• Unless your code is a derivative work of the graphics driver, whoever wrote that driver probably has no claim against you, regardless of whether you violate someone else's rights or not. As with the downstream recipient, they might not be happy that you violated the GPL and might notify the upstream copyright holders. And, as mentioned above, if you distribute a single binary kernel with their driver and also your proprietary modules, then that may create liability as well.