[linux-elitists] Issues regarding Linux closed source drivers

Greg KH greg@kroah.com
Wed Jun 12 09:35:37 PDT 2002


Wow, the number of people who emailed me privately about getting this
information was amazing.  Seems there are lots of people working at
companies who are struggling with this issue right now.

So feel free to print this out with pretty fonts on heavy paper to
impress the management types and distribute it widely.

If anyone wants any point expanded on, or has any other things that
should be added, please let me know.  The support section should be
expanded some more by people who know more about the Linux support
business.

In the end, this document is a place to help start discussion with
people who do not know about all of the different kinds of issues that
keeping a Linux driver source closed entails.  This is quite common with
companies that are used to writing their own drivers for other operating
systems.

thanks,

greg k-h

--------------------------

Issues regarding Linux closed source drivers

First off, consult an IP lawyer. If it isn't worth the money to consult
a lawyer, then just release the code under the GPL, it must not be worth
that much to your company.

Legal issues around closed source drivers:
  - read the GPL and the section about "linking".  Then read how
    modprobe works (i.e. it "links" the module into the kernel.)  Make
    sure your lawyer understands the issues here.
  - when compiling your code, make sure you do not use any GPL header
    files to build it.  The kernel is all GPL header files, so you will
    probably have to rewrite all of the different kernel header files.
  - You can not copy any existing kernel code in your driver.

Support Issues:
  - If a customer uses your binary driver, they invalidate their support
    contract from their distribution.  Is your company willing to
    support these customers?
  - You will need to set up a special email list at the minimum to
    support this driver.  Someone from your company will need to be
    assigned to answer the questions on this list.

Technical issues:
  - You will have to release a compiled driver for every kernel that the
    major Linux distributions release.  For example, Red Hat 7.3 has
    7 different kernel versions (depending on the processor type, multi
    processor enabled or not, and high memory enabled or not.)
  - You will also have to build kernel drivers for every kernel update
    that is released by a distribution (for example, Red Hat released
    about 4 kernel updates for their 7.2 release.  So that's 28
    different kernel module versions you need to build.  And that's just
    one Linux distributor.)  Security minded customers will also need
    your updated module at the same time the kernel update is released,
    so you must have a very fast turn-around time.
  - Different distributions use different versions of gcc for building
    their kernel.  When building a module for a specific distro, you
    also need to use the proper version of gcc.
  - None of the Linux distributors will pick up your driver, so you will
    have to constantly keep it up to date with all of the most recent
    kernel versions.
  - If the Linux kernel internal APIs change (and they do quite
    frequently) you will have to keep updating your driver to keep on
    top of this.  If your driver is in the main kernel tree, any API
    changes, will be done to your driver, by the person doing the API
    changes (one of the main benefits of having your driver in the
    kernel tree.)
  - Linus has stated that any kernel module that relies on a patch to
    the main kernel tree to support it, is not allowed to be closed
    source.  This means you are only allowed to use the existing API.
  - What happens if in the future one of the API calls you are using
    disappears because no one thinks anyone else is using it.
  - No Linux kernel developer will offer to help users of your kernel
    driver if they can not see the source code (they have no idea of
    what the driver is doing.)  In the more recent kernels, there is a
    "taint" flag that will get set if you try to load a binary module.



More information about the linux-elitists mailing list