MESSAGE
| DATE | 2002-06-12 |
| FROM | Ruben I Safir
|
| SUBJECT | Subject: [hangout] Issues regarding Linux closed source drivers (fwd) [jays@panix.com]
|
On 2002.06.12 13:25 Jay Sulzberger wrote:
---------- Forwarded message ----------
Date: Wed, 12 Jun 2002 09:35:37 -0700
From: Greg KH
To: linux-elitists-at-zgp.org
Subject: [linux-elitists] Issues regarding Linux closed source drivers
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.
_______________________________________________
linux-elitists
http://zgp.org/mailman/listinfo/linux-elitists
____________________________
New Yorkers for Fair Use -
because it's either fair use or useless....
--
__________________________
Brooklyn Linux Solutions
__________________________
http://www.mrbrklyn.com - Consulting
http://www.brooklynonline.com - For the love of Brooklyn
http://www.nylxs.com - Leadership Development in Free Software
http://www.nyfairuse.org - The foundation of Democracy
http://www2.mrbrklyn.com/resources - Unpublished Archive or stories and articles from around the net
http://www2.mrbrklyn.com/mp3/dr.mp3 - Imagine my surprise when I saw you...
http://www2.mrbrklyn.com/downtown.html - See the New Downtown Brooklyn....
1-718-382-5752
____________________________
New Yorker Linux Users Scene
Fair Use -
because it's either fair use or useless....
|
|
