The company I work for is selling PCIe cards. I'm writing the Linux driver for it as a Linux kernel module.

When selling these PCIe cards, we give along the Linux kernel driver as source code. Customers can thus compile our kernel driver on their very own version of the Linux kernel.

However, this source code is stated as Proprietary both in the header and with MODULE_LICENSE.

I was wondering what would it make as a difference to state these kernel module source files as GPL licensed?

From a customer perspective, I can see no difference as they can compile and use it whatever the license is. What am I missing?

  • 22
    I would strongly urge you to encourage your employer to get a qualified expert to give a written opinion you can reasonably rely on stating that your kernel module is not a derivative work of the Linux kernel before distributing it under any license other than the GPL. This is necessary to protect your employer from an accusation that they are negligently or intentionally violating the GPL. They need to have a good faith basis to believe that what they are doing is lawful. Feb 21, 2019 at 19:39
  • 4
    Beware. A memory dump of the kernel is GPL, proprietary driver or not.
    – Joshua
    Feb 21, 2019 at 21:14
  • 5
    Why make it proprietary. Add it to the official kernel. Feb 21, 2019 at 22:43
  • 1
    I don't think you can write kernel modules that aren't GPLv2 without using a proprietary binary blob and GPL wrapper like nvidia does.
    – ivanivan
    Feb 22, 2019 at 2:44
  • 4
    @ivanivan While I agree, that proprietary licences are bad. Note that because you can use GPL code without accepting the licence, you are able to link it to anything. However you will then be unable to distribute it, and maybe unable to legally modify it (because you could modify, while accepting, and link while not. At least if you were 2 legal entities). Feb 22, 2019 at 9:22

4 Answers 4


Do you customers have any right to modify the source they've been given? Do they have the right to distribute the code without your permission? Do they have the right to distribute modified versions of your code? All of those would be allowed under the GPL, but aren't under a proprietary license.

Open source is not just about the ability to use the code, it's about freedom to modify the code and adapt it for other uses, and to redistribute it (even sell it) without your permission.

  • 4
    As an extension of this, GPL would mean the driver can get included in official repositories and distributed with the kernel (no need to compile it yourself). A proprietary license means that neither the Linux developers nor your customers can take care of making any tweaks necessary to work with a particular Linux distribution. That will be a (potentially burdensome) task left to your company. Under a proprietary license, simply having the source code doesn't mean you can change it or even compile it.
    – bta
    Feb 22, 2019 at 1:39
  • 3
    "but aren't under a proprietary license" should be more like "but may not be under a proprietary license". The whole point of a proprietary license is that you can impose (or not impose) whichever restrictions you like. E.g. you may want to allow your customer to modify the source, but not distribute that modification.
    – JBentley
    Feb 22, 2019 at 13:36

Source code distributed as 'proprietary' usually does not come with the legal rights that open-source code does.

In a nutshell:

  • You cannot legally modify it
  • You cannot legally redistribute it
  • You cannot legally redistribute modified versions

As such:

  • You won't be able to get it into the kernel
  • Distributions won't be able to put it into their repositories
  • Distributions won't be able to make fixes to your code in order to make it work on their releases.
  • All support onus for the driver will fall on your company
  • You will need to provide an installer and instructions on how to get it.

Which will make dealing with your hardware on Linux a little bit of a pain in the ass for the end user, as Linux users are pretty accustomed to 'just works' for most hardware and 'have to install a single package' for most outliers.

  • Actually your first bullet point is wrong. You are absolutely free and allowed to modify it. You just probably don't want to because then you aren't allowed to redistribute it.
    – Nobody
    Feb 22, 2019 at 21:25
  • @Nobody Depends on what is in the proprietary license. Feb 22, 2019 at 21:52
  • @historystamp In most civilized jurisdictions such clauses would not be enforceable as far as I know. Feel free to provide me with counter examples. Reverse engineering is something else, that doesn't count.
    – Nobody
    Feb 22, 2019 at 22:05
  • @Nobody Many jurisdictions also allow reverse engineering in order to integrate different software products.
    – Bakuriu
    Feb 22, 2019 at 22:38

I would not touch it, because of the proprietary licence.


  • Idealism
  • Practicality

What are (some of) the practical implications?

If a change is needed to the driver in the future. Then no one but the proprietor can make legal changes. These can include bug fixes, security fixes, comparability fixes, feature improvements.

Can I put a copy on all of my computers (even ones without the hardware)? Do I need to keep track of licences?

Is it part of the mainline kernel?: Does it come pre-installed with my OS, or do I need to install it.

  • 1
    No. You can set whatever rules you want with a proprietary license. You could set a rule that customer may modify the driver but that the driver may only be used with your hardware. With GPL a competitor may legal use your software for their hardware. Feb 22, 2019 at 21:48

Since you mentioned customer perspective, here's one: For some of your customers (or potential customers) there might even be regulatory benefits if you, if you publish the driver as open source and take the effort of having it accepted into the mainline kernel and then further down the line.

Namely, in some fields (say medical), there are regulatory standards for code quality. If I'm using off-the-shelf code, like a driver for a device, I might need to "qualify" it as medical code.

For certain levels of criticality, in some regions, some of the arguments which might be used to qualify code are if it's in wide-spread use, and if there's a clearly documented development process using which the code was made, if there's a clear bug reporting and solving process and so on.

If the code is a part of Linux, then I can qualify it basically "for free", as a part of the whole kernel package. If it's not, then I'll probably have to do reviews on it, and might have to do an audit of your development processes, write many pages of reports on it and so on and so on.

In practice, this means, that if there's a competitor which has his drivers in kernel, I'm going to pick his product, even if it's more expensive or of lower quality, instead of spending a boat-load of money doing paperwork for your, and then repeating the procedure of every device I want to use your product in.

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.