When distributing a Linux kernel driver as source code, what's the difference between Proprietary and GPL license?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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

Why

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

Answer 4

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.