Slashdot Mirror
GPL Issues Surrounding Commercial Device Drivers?
Demiurg asks: "My company has recently decided to support Linux for it's embedded networking products which means that I'm starting to write Linux device drivers for our hardware. The company was very concerned about GPL issues and consulted a lawyer - who advised us to go for a user-space driver, saying that this is the only safe way to avoid GPL issues. I tried to give them a few examples of companies distributing binary only drivers (NVIDIA and Rational) but was told that these companies do not distribute binary only drivers - they only allow you to download them from a web site (which is not an option for an embedded product). What does Slashdot have to say about the issue? Is writing a user-mode (and hence not very efficient) driver the only way for a company to protect it's intellectual property? Please refrain from giving answers like 'all code should be GPL' - although I personally may agree, such answers will not help me convince management to make the change." Are there any lawyers (or readers with the right legal knowledge) out there that can confirm or contradict this recommendation?
It all boils down to the concept of "derivative work". Is a device driver a derivative work of the kernel? My opinion is no, but only the courts can truly answer that question, and no one has asked them yet.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Why is a userland driver on linux necessarily slower? Shouldn't a well-written user space driver at an appropriate priority level be just as fast as a kernel driver? And if not, why is this slow on linux but fast on some other operating systems, and what can be done to fix it?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Why is a userland driver on linux necessarily slower?
See subject.
And if not, why is this slow on linux but fast on some other operating systems, and what can be done to fix it?
No operating system can have userspace drivers without context switches. Some OSes have very low context switch times and *do* put all their drivers in userspace (which has a number of very big advantages I'm not going into right now) -- but they still, unavoidably, pay some performance penalty for doing so.
See also the article "Pick and place: Linux grabs the embedded market" on http://www.e-insite.net/ednmag/index.asp?layout=ar ticle&articleid=CA253780&pubdate=10/31/200 2. Besides other information it describes some licensing issues and solutions with embedded software
Do what Sony did with the PS2 Linux - boot a Runtime Environment that has all the required drivers before running the linux kernel. Make open-sourced Linux device drivers that will use the Runtime Environment drivers. This is a similar to using BIOS calls from within the kernel.
No operating system can have userspace drivers without context switches.
By that I mean no operating system with memory protection for userspace apps. It's possible to give up this benefit (even selectively) for improved userspace performance; see Kernel Mode Linux for a kernel patch that does just that (and which might be applicable to this fellow's situation).
My company uses Linux in some of our embedded products. Before doing so, and before we had fulltime counsel, we hired a lawyer to go over the GPL and tell us if it was going to present a problem. This lawyer seemed to think that anything compiled with GCC would fall under the GPL, which is incorrect. There are specific exceptions that allow it to be used to produce non-free software.
I'm not saying he should ignore the lawyer, but that his lawyer could quite possibly be wrong. The GPL is 'viral' in a sense, but not in as devious a way as Microsoft FUD would indicate, and at least they are up front about being a bunch of commies =)
See http://www.gnu.org/licenses/gpl-faq.html for more info.
Yes you can say its more efficent to have it in kernel space, but its an embedded device so any efficency problems can be counteracted by knowing exactly what is gojng to be run on the system. If you cannot get all the information you want in user space, write a driver to patch the information you need though to user space.
An example of this is binary firmware for devices, you can just patch the loading routinues through a driver an upload a what ever you like. For example the DXR2 drivers provide all the access functions, but within the magic binary only firmware they are useless, the only thing your "device" gives away is how to write a kernel modules, but there again, you could just take someone elses gpl kernel modules and make it work for these ends saving you development time.
Having said that run time loadable modules do not have to be GPLed the only code your need to include to build one of these are kernel header files and if you look carefully at those they are not GPLed so the compiled object does not have to be GPLed. I believe using non gpl loadable modules in a GPL kernel is specifically allowed (I believe).
I think this system fits with the linux point of view. Getting support for as much stuff as possibile is good if it means non gpl fine, just don't expect us to help you. Non gpl is better than nothing at all (in many peoples book). But there again, I don't buy nivida graphics cards because of their policy of binary drivers.
James
Linus is not the freakin' copyright holder. He is the copyright holder of a significant portion of the code, but not all of it.
Your comment also flies in the face of the many developers whose create open source programs on Macs.
The kernel exports certain symbols that are available for driver modules to link to. These symbols are classified by license. Many symbols a driver can link to without having to be a GPL'ed driver. These symbols, presumably, are written by people who grant permission to link against non-GPLed code. Other symbols (for example the new work-queues stuff) are exported as so-called GPL_ONLY symbols, and linking against those in a non-GPL module is illegal. Thus, if you avoid using the GPL_ONLY symbols you can probably get away with a binary only module. The fact that this mechanism exists implies permission, so this aspect would be important to bring up to the lawyer.
A deep unwavering belief is a sure sign you're missing something...
This very question (and a possible change of Linus' position on this) has just been the top story of the last LWN issue: Proprietary kernel modules - the boundary shifts?
Quoting the good parts
And continuing a bit later
Does the legal community realise that they are in desperate need of lawyers with technical background?
Yes
If so, are the law schools doing their best to fulfill this need such as lowering admission requirements for people with technical backgrounds
Yes
or targetting recruiting?
No
_____________
BTW they actually want stuff like chemestry and biology more than compsci. An understanding of computer technology is much more part of the culture and thus non science oriented lawyers have less trouble. In other words a history major knows what software is and may even know what a divise drive is; but they don't know what an omega-3 fatty acid is.
> Simply using library functions of GPL'd software doesn't mean you have to release your source code.
> It does mean, however, that you should credit somebody else's work for giving you the
> functionality that you didn't write yourself.
This is not insightful, this is wrong.
See GPL-FAQ:
"You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program?"
Yes.
There seem to be some exceptions for the kernel though, see other postings.
First, IANAL.
x -gnu-license.html which contains a post from Linus where he explains that the Kernel Module Interface is actually LGPL.
:
Second, take a look at http://www.gcom.com/home/support/whitepapers/linu
Next, see http://www.gnu.org/licenses/lgpl.html Read section 5. In particular, the paragraph
"If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)"
This leads one to believe that Binary-Only Device Drivers are A-OK.
Nvida and other graphics board developers aren't the only ones providing binary only drivers.... Adaptec only provides binaries for their RAID controller drivers - no sources at all. Not even
an "intermediate buffer layer"
The spirit of the LGPL licence seems to be "If you can upgrade the LGPL code without having to recompile the Proprietary stuff, and continue to have everything work, that's ok."
The FSF will tell you, if you ask, that they believe that the GPL applies to all code that is designed to be linked into the same executable as GPL code, and that kernel modules appear to be linked into the same executable. But they will also tell you that they don't hold the copyright to the Linux kernel and that the copyright holders are the only people with the power to come after violators, or to grant exceptions.
My company has experience in this. I am in the group that writes Unix and Linux drivers for our hardware products.
We have released the Source al'la GPL and we will, thanks to our experience, never do that again. There is no problem in our case with intellectual property, it is a problem with support costs. We committed to support of our Hardware under Linux.
The problem arose when the source was released and people wanted higher performance. We have a group of highly talented (highly paid) people who have a combined experience of about 50 years writing low level system code and drivers. In addition, they have free access to the hardware engineers who designed the products.
Long story short, some snot-nosed high-schooler "optimized" the driver and broke about 50 things in the process. The calls to our help desk were non-stop. We had to advise customers to back down the changes. This was very confusing to them since they did not understand that the "optimized" driver was not written by us. And they all wanted to know what was wrong with our hardware. It cost my company a ton of money.
What needed to be protected in our case was the protocol to speak to the hardware. We only wanted to support our driver, not all deriatives of that driver. Consequently, my management will probably never authorize such a move again.
While IANAL, I've been dealing with GPL issues for a dozen years now, most recently as a member of the GCC steering committee.
This (dividing the work into pieces) could be legitimate if the GPL portion's interfaces are generally useful. For example, this is the origin of XEmacs, which was originally Lucid Emacs. Lucid, the company, designed Lucid Emacs to be the front end to a proprietary software development system, but the editor was useful as a standalone tool so this was legit. When Lucid went broke, Lucid Emacs became XEmacs.
But if the GPL module is only useful as an interface to the secret, proprietary code, and does a lot of secret, mysterious things that no one knows how to use, courts would probably treat the whole thing as one work. At least Eben Moglen has argued this in the past, to people who tried similar tricks to get around the GPL (successfully enough to get them to back down, though such cases haven't been to court yet).
An example of something that's clearly legit is a kernel module that is itself under the GPL, that loads a program into a processor (say, a DSP) that sits on some peripheral card. It might come with only the object code that is to be loaded on the card. But the DSP program and the kernel are two completely separate programs, and in principle you could load a different program instead.
I suppose the kernel module could talk to a userspace program, and if the interfaces between the two were clearly documented one could argue that they are independent enough to pass GPL muster. Of course the lines are fuzzy. But it isn't just the law that matters, for the fuzzy cases it suffices if the copyright holder thinks it's ok, because the copyright holder is the only one with standing to sue you.
This is why it's a problem that Linus doesn't ask for copyright assignment, because no single individual has the power to assure you that something is OK and have it stick. For FSF software, it suffices if RMS says it's OK.
I am a driver developer: A year or so ago a company I worked for was looking to release a linux driver. The same questions were going around and around. Some other things to think about.
There are lots of diffrent versions of Linux. This isn't windows where you have to make a release for one or two versions of the same operating system. This will cost money in terms of support and testing. Every driver release will have to be testing with the kernel version shipped with the last couple release of Red Hat, Mandrake, Suse, and Turbolinux at a bare minimum.
Getting a driver to work across multiple major linux verions (2.2->2.4->2.6) isn't usually a small task if your driver does more than export a basic character device. In some cases it is as easy to port to AIX and Solaris than keep up with how fast people are changing the Kernel API's. There has been talk of changing this on LKML.
You have to have a solution to deal with people who are installing kernel patches which break API's you depend on. In our case the driver was carefully written to have an opensource component and a closed source component. The user could download and compile the opensource part which would provide a stable API for the closed source part.
You also have to question your basic model. Is your company selling hardware, software, support or a combination? If your not selling software then why are you concerned about the driver? Simply opensource it. That way you will get free development. The bottom line may be a better if you hire 1 developer to write and release a opensource driver which gets partially maintained by the community vs two or three developers to write, maintain and test it.
If your releasing a new piece of hardware that doesn't have market acceptance yet and isn't just another cheaper/faster soundcard/nic/etc then you probably want to encourage use of your product. Opensource drivers help to document and provide examples of how to use the hardware. I have been involved in a situation recently where a company has been trying to sell a product for two or three years into a particular market. We are selling product into a diffrent market. After trying to buy a development kit and aquire documentation we went with another solution that has very open documentation (including some opensource driver source to look at).
There isn't anything particulary special about 99% (statistic pulled from ass) of the drivers out there. They are simply software intefaces between the OS API's and a particular piece of hardware. Just because it cost a lot money to make the driver doesn't mean it should cost a lot. Drivers by definition are pieces of code writtent to SUPPORT the hardware. Not the other way around. Viewing the driver as the cost of selling the HW (just like the marketing costs of selling it) is much more appropiate. Will you try to have a license key for the driver or will the HW be the license key? Most companies give the latest version of the driver away on their web site, why not provide the source anyway. Any patents in the source are still valid, and it discourages people from reverse engineering your driver and writing a clean room version you don't control.
Yes, the legal community does realize that there is a need for technical knowledged attorneys. I'm currently a 1L (first-year) student at the University of Houston with an EE bachelor. I chose the school because it is strong in Intellectual Property law. The IPIL (Institute for Intellectual Property And Information Law) at UH seems to be fairly well-respected and I attended a lecture last week with one of the judges on the Federal Circuit Court of Appeals (They hear patent appeals). I would say 10% of my entering class has a technical background, and most of those are interested in some form IP/Patent Law. I barely have any legal knowledge on IP issues (I'll get that next year), but I will say that the recruiting effort to get engineers into Law School is negligible, but based on the extremely high number of applicants to law school, it doesn't look like many law schools are interested in recruiting. And to close, it does appear some schools consider a technical background in admissions, but the way the LSDAS (central distribution of transcripts, think Palladium of law school admissions) ranks students is based on your standing across the university, so even though my GPA was in the top 20% of the engineering college it was below 50% for the school as a whole, that made it difficult to get into some schools that just use formulas.
.at. central.uh.edu
Brandon
bjlee
IANAL, and IANAE, but here goes...
Is your employer's concern over licensing or over distributing source code? Linus Torvolds has made it quite clear that the Linux kernel has provisions for commercial modules, given that the module follows the API requirements, such as providing a COPYRIGHT notice in the initialization structure of the module itself. Proprietary modules are not an issue with it comes to the kernel.
I believe that any changes you make to the kernel itself in order to integrate your module need to be GPL'ed. For example, let's say you have to make a patch to the Block IO API in order to enable some functionality of your driver. That patch must be GPL'ed. Your driver is still safe.
If your company is concerned with distributing source code, regardless of license, then you have another problem. In that case, you will be in the business of compiling kernels if you don't want to deal with a physical module. Compiling kernels and distributing them, which you have all the rights in the world to do, adds overhead to your company's responsibilities that they probably don't want.
So, when it comes to the Linux kernel, you should talk to Linux kernel developers and Linus Torvalds or his legal team in particular. Remember that the Linux kernel does have provisions for legal use of commercial and proprietary licensed drivers. Looking only at the GPL is not enough in this case.
assert(expired(knowledge));