Driver Question and Answer

Contents


Q&A on Device Driver Statement

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.


Why are kernel developers issuing this statement now? Did something change? (legally, technically, etc?)

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.


Why are closed-source modules "harmful?" What are they harming?

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.


What exactly are modules? Are they the same as drivers?

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.


What happens to these vendors if they ignore your statement? Are you going to sue them?

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


Why should vendors open source these modules? What advantages do they get from that?

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.


Are there resources to help vendors work with the kernel community?

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.


Can you explain why this is important? What should end users think or do about this?

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


Can you give me names of vendors who have opened up their modules and are good citizens?

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.


I'm a kernel developer and want to add my name to this statement. How do I do so?

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


Are the kernel developers expecting vendors to Open Source the code for all their binary drivers?

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


Vendors need to protect their Intellectual Property, won't releasing an open source driver compromise that?

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.