• 1 Q&A on Device Driver Statement
  • 1.1 Why are kernel developers issuing this statement now? Did something change? (legally, technically, etc?)
  • 1.2 Why are closed-source modules "harmful?" What are they harming?
  • 1.3 What exactly are modules? Are they the same as drivers?
  • 1.4 What happens to these vendors if they ignore your statement? Are you going to sue them?
  • 1.5 Why should vendors open source these modules? What advantages do they get from that?
  • 1.6 Are there resources to help vendors work with the kernel community?
  • 1.7 Can you explain why this is important? What should end users think or do about this?
  • 1.8 Can you give me names of vendors who have opened up their modules and are good citizens?
  • 1.9 I'm a kernel developer and want to add my name to this statement. How do I do so?
  • 1.10 Are the kernel developers expecting vendors to Open Source the code for all their binary drivers?
  • 1.11 Vendors need to protect their Intellectual Property, won't releasing an open source driver compromise that?

This Q&A was created by the Linux Foundation's Technical Advisory Council. The answers here reflect their views and not necessarily all developers who signed the Kernel Development official statement on closed source drivers.

Nothing has changed, we have just been receiving a constant stream of questions from companies asking how the Linux kernel developers feel about closed source modules over the past year or so. This statement should be the definite answer for how a large majority of them feel with regards to this topic.

As we state, they harm the user, businesses, and the overall ecosystem. They harm the user by forcing them to abandon any recourse of support or upgrades that are provided to them by the kernel development community. They are dependent on the single provider of the closed source module for all forms of kernel support, not just to anything relating to the single module as the community is unable to help in such situations.

They harm businesses in the same way as users when they use Linux, forcing them to abandon support from their distribution and the community. For businesses that distribute and support Linux, it harms them as they are unable to support their own customers who use closed source modules for the same reason.

It harms the overall ecosystem by cutting these users off from the community, often times giving them a very bad perception of how Linux works due to the documented instability of many common closed source modules. These users are unable to help to contribute to making Linux succeed and grow because they are reliant on a single provider which controls how and when they can upgrade their system, as well as sometimes not allowing upgrades to happen at all.

A module is a chunk of code that can be loaded into the Linux kernel while it is running. It is often the same thing as a driver, but they can provide other things. Examples of non-driver Linux kernel modules are filesystems and security frameworks.

We are making no legal claims in this statement relating to this topic.

They get a wide range of benefits. After a module is released under the GPLv2, it can be included in the main kernel.org tree. The process of getting it accepted into the tree usually results in a very thorough code review process and rewrite in places where necessary. The resulting codebase is almost always smaller, faster, and works better than the original closed source module due to the experience of the Linux kernel developers as well as the wider range of people doing the review.

Once the code is in the main kernel.org tree, the module is automatically picked up by all Linux distributions for their next release and is supported by them for their customers.

Vendors who wish to have Linux drivers written for their hardware can have it written for free by the developers of the linuxdriverproject.org group. See their website for details on how to start this process. The Linux Foundation also has an NDA program to help vendors work directly with the kernel community on pre-release products and code. Participating in Linux Foundation activities/conferences also can help vendors connect with the kernel community and get their questions answered.

End users should demand that their hardware be supported on Linux by opensource modules in order for them to be able to get all the benefits of Linux. If their vendors continue with closed drivers, it harms end users since it unfortunately cuts them off from the Linux community and the on-going benefits that come with that. (See above.)

There are in fact too many to list. It's actually the norm now; closed source drivers are the exception. There are hundreds of vendors who have been doing this for years: look in the kernel.org tree for their copyrights and names for specific examples.

Please contact Greg Kroah-Hartman at greg@kroah.com.

While we feel that opening those drivers would be desirable, we recognize that such a step may actually be impossible in some cases since a lot of binary drivers contain code from a variety of different sources whose permission would have to be sought before the code could be released. However, for these cases we do ask that vendors help us to provide an open source driver for their product; we have the resources of the Linux Driver Project to do this, all we ask is for documentation (which may even be provided under NDA using the Linux Foundation NDA Program to assuage intellectual property concerns).

It is true that an open source driver reveals far more about the workings of the device than a closed driver on first inspection. However, even a closed driver can be reverse engineered to reveal those secrets; and if there are significant ones, you can bet your competition has done this anyway, so hiding them in binary modules is just giving yourself a false sense of security. Every company who released open source drivers had set off this worry about Intellectual Property against the benefits to be obtained and they all made the business decision that the benefits outweigh the problems. If you still have concerns, please contact the Linux Foundation who'll be happy to give your executive team a briefing on these issues to ensure you have all the facts before making this decision.