GPL Issues Surrounding Commercial Device Drivers? 523
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?
Linus allows an exception for device drivers (Score:5, Informative)
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.
Why necessarily slower in userland? (Score:5, Informative)
Context switches. (Score:5, Informative)
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.
article on embeeded software (Score:1, Informative)
Playstation 2 Linux (Score:2, Informative)
Addition/Correction (Score:5, Informative)
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 [u-tokyo.ac.jp] for a kernel patch that does just that (and which might be applicable to this fellow's situation).
Re:Linus allows an exception for device drivers (Score:5, Informative)
Re:Linus allows an exception for device drivers (Score:5, Informative)
Re:lawyers (Score:5, Informative)
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 [gnu.org] for more info.
Whats wrong with a user mode driver? (Score:3, Informative)
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
Linux != Linus (Score:2, Informative)
Re:Related question. (Score:2, Informative)
Your comment also flies in the face of the many developers whose create open source programs on Macs.
Module API (Score:5, Informative)
Proprietary modules may be on their way out... (Score:3, Informative)
Re:Linus allows an exception for device drivers (Score:5, Informative)
That's been a long standing supposition. However, lwn recently ran an article [lwn.net] in which Linus' view on this matter doesn't seem to support this point of view:
There is NOTHING in the kernel license that allows modules to be non-GPL'd. The _only_ thing that allows for non-GPL modules is copyright law, and in particular the "derived work" issue. A vendor who distributes non-GPL modules is _not_ protected by the module interface per se, and should feel very confident that they can show in a court of law that the code is not derived.
and also
The original binary-only modules were for things that were pre-existing works of code, ie drivers and filesystems ported from other operating systems, which thus could clearly be argued to not be derived works, and the original limited export table also acted somewhat as a barrier to show a level of distance.
Linus discused this issue recently (Score:2, Informative)
Quoting the good parts
And continuing a bit later
Re:OT: Law School for Geeks? (Score:3, Informative)
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.
Re:Supply user-space, allow kernel-space for downl (Score:4, Informative)
LOL, at least one of us has a misconception of what an embedded device is. I'm imagining something along the lines of a media player device with play/pause/stop button interface, or maybe a turnkey web server/virus scanner/proxy server/etc "black box". In many embedded devices the end user may never know or care that it's Linux inside, and there is probably no CLI or X user interface. Maybe a web interface or only flash firmware for software updates.
Downloading a specific driver for such a device is not an option. The end user is probably not expected to be GNU/Linux/*BSD/UNIX savvy.
Re:A cow by any other name... (Score:2, Informative)
> 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 [gnu.org]:
"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.
embedded (L)GPL Code (Score:2, Informative)
Second, take a look at http://www.gcom.com/home/support/whitepapers/linu
Next, see http://www.gnu.org/licenses/lgpl.html [gnu.org] 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."
Re:Tried asking the FSF or lkml directly? (Score:3, Informative)
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.
Re:Protect? (Score:2, Informative)
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.
Re:not revealing intellectual property versus GPL (Score:3, Informative)
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.
Linux kernel modules (Score:3, Informative)
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.
Re:OT: Law School for Geeks? (Score:1, Informative)
Brandon
bjlee
Licensing Issue or a Distribution Issue? (Score:3, Informative)
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.