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?
So, you got your advice from a legal consul, and you're thinking about ignoring it in favor of advice from the /. crowd? Is that smart?
Je ne parle pas francais.
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.'"
Seems like you might get good info by directly talking to the FSF or linux kernel mailing list... I'm sure some people would piss and moan about binary this and proprietary that, but in the end I think you'd find more people eager to help expand linux's reach in an optimally efficient manner. IIRC the FSF's head legal eagle is a guy named Eben Moglen (there was something posted on /. just yesterday that involved his name, again IIRC.) Personally, although IANAL, making something available for public download from a website sounds pretty much like "distributing" something. True, the user has to decide to download it, but then again your users would have to decide to buy your particular widget (thus potentially getting the linux driver) also...
News for Geeks in Austin, TX
Nvidia and others do "distribute" binary-only drivers. Just because they don't actively send out CD's with their drivers does not mean they do not distribute them. Under the GPL both methods are concidered a distribution. As far as writing drivers, as long you use the driver module method and do not need to directly change any preexisting kernel code, I do not believe there is any problem at all. That is how Nvidia and others can get away with that.
You need to look at exactly what parts of your hardware a GPL'd driver source would reveal, and whether there is really any need to avoid a GPL'd driver for this reason.
Only the people who know what the hardware does and why the features in question need to be kept secret can make this decision.
-- BtB
John Sauter (J_Sauter@Empire.Net)
So you your company should go for the best possible driver, to increase hardware sales. If that means GPL'ing the driver, you can also benefit from the expertise of a lot of developers.
Ask your lawyer how distributing something over the internet is not distributing?
NVidia are distributing binary-only drivers. They do a trick however, where the code that needs to be loaded into the kernel is (L)GPL, and then this cpde interfaces their binary driver. This both allows a buffer to the GPL code but also to support various different versions of the kernel with the same driver.
Moreover it allows for a lot of naive trolls claiming that Nvidia is distribting the source-code because they have seen this little module.
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.
The fact that NVIDIA and Rational have not been sued does not imply that they are legally in the clear. There are certainly several kernel developers who have said clearly that the "module exception" invented by Linus Torvalds does not extend to linking to their code. So far they have not sued anyone. Maybe they never will.
Finally! A year of moderation! Ready for 2019?
In general, do not take advice on how to write a device driver from a laywer. Or, if he/she insists, invite them to write the driver for you. Pay only if it works.
Have you got your LWN subscription yet?
I don't quite see what is lost by releasing a device driver under GPL.
:)
You get:
1) an army of geeks who will instantly worship your company and buy your products;
2) a slightly smaller army of geeks who can actually help you fix bugs in your own product FOR FREE.
You lose... erm, nothing?
The only drawback is that the interface to your hardware (register maps etc.) are no longer as secret as they were. Perhaps you're concerned about competitors stealing your ideas based on that knowledge? Well, think about it this way - if they badly want that information, they will already be reverse engineering your products and your binary-only drivers with a debugger and some elbow-grease.
IMO - you have nothing to lose. Embrace the future...
These sigs are more interesting tha
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).
Easy. People ask slashdot because slashdot readers have actually had to deal with these matters on a day to day basis. Your average lawyer may see a handful of case studies.
Now, he may have gone to the sort of lawyer that specializes in software licenses (what sort of lawyer is this? a very very rich sort), in which case you're right that it is kind of stupid to approach the trolls and IANALs. But if he went to Joe Q. Publicstein of Publicstein, Stern and Lowe, chances are he'll get a much more specific answer and leads on a case he may be able to point his legal eagle towards. Which could result in a much more informed decision.
By the by, I've got a feeling that the people who MIGHT press a case on the GPL have bigger fish to fry than a company writing a device driver. If they can't catch Microsoft biting GPL code, why are they going to hunt down developers expanding the OSS market?
Hey freaks: now you're ju
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
We've stopped using Rational products precisely because of the proprietary kernel driver issue.
There's nothing more irritating to me than than trying to shoehorn binary drivers into kernels they were inevitably not designed for.
My advice to you would be to do your proprietary driver in usermode, or put a small GPL'd driver in the kernel that then communicates to your proprietary code using a published, well defined interface.
Keep in mind, however, that all other things being equal using a proprietary software driver under linux puts you at a competitive disadvantage. If ATI's open source drivers had as solid an openGL feature set as NVidia's under linux, I'd switch in a second.
Why don't you move your proprietary IP into the firmware of your device and leave the driver open?
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...
If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
I think the keys here are what count as distribution and separate works. Obviously, the GPL was drafted with traditional software in mind and is not tailored toward embedded systems. You have to answer the questions "Is this a work based on the Program [a piece of software covered by the GPL]?" and "Is this an independent and separate work?" Unfortunately, I don't have enough facts about your system, and we don't have an attorney-client relationship, so I can't give you an answer. What I can tell you is that you should make sure your lawyer is familiar with your code development processes and distributions systems and knows enough about software development so that he can draw principled distinctions between different ways of doing things.
Laws affecting technology will always be bad until enough techies become lawyers.
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?
Does the legal community realise that they are in desperate need of lawyers with technical background? If so, are the law schools doing their best to fulfill this need such as lowering admission requirements for people with technical backgrounds or targetting recruiting? Are law schools completely full of English and Philosophy majors that need to get a job or is there some diversity there?
I'm asking because in a year or so I'm going to have a Master's in CompSci and I'm considering my options afterwards. While a PhD would be nice, I've also been looking at law school. I don't think I could resist getting an emphasis in technology law, however I'm not sure what to expect...
My gut feeling is that a loadable module that does not itself incorporate any GPL'd code does not fall under the GPL just because it's run in conjunction with a GPL'd kernel. After all, even if the kernel + driver are considered together to create a derivative work, it's the user, and not you, who creates that derivative work at runtime.
And, the fact that you're using GCC to compile the module doesn't mean anything in and of itself. The real question is the license status of any libs that are linked into the resulting object code file. Whether they are under GPL, LGPL, or something else makes a big difference.
Now for the shades of gray part... any time you're dealing with GPL questions, you have to look at the genealogy of the running executable, working backwards to see what licenses govern the component pieces. It's a very fact-intensive process, and without understanding where all the code came from, you can't come close to giving a reasonable answer.
I'm assuming that since this is mentioned as an embedded product, your choice of Linux is not for the purpose of making your device work in other people's Linux systems, but is instead, for the purpose having a embedded operating system inside your embedded product. If this assumption is true, then I recommend instead to use one of the BSDs for it, e.g. FreeBSD or NetBSD or OpenBSD. The licensing issues are so much easier. FreeBSD is actually the foundation OS in many a network device on the market over quite a range of sizes from small handheld devices to huge WAN switches. Linux is, too, but if the GPL licensing is the big issue, then give BSD a serious look-see.
If the above assumption is not correct, and you are making a device which is to be accessed by a hosted Linux system, then I can at least say this: I won't use your device in my managed network engines (Linux based) unless the source code is open. This is due to the need to be able to fully audit the entire security and not wanting to have to negotiate for NDA source. Lack of source can cut into your market share, especially where security is an issue (affects network devices far more than high performance video cards). So if you have intellectual property in a network device intended for a hosted system (e.g. for example a 10GB ethernet card or an OC-192 WAN line card), try to keep the intellectual property locked up in the device itself as much as possible.
now we need to go OSS in diesel cars
that you clearly have the source code to your company's PABX and laser printers. It must be a pain blowing the flash roms and unscrewing the hard drives when you want to recompile the O/S to keep up with kernel patches though.
All contributers of code to the kernel know that the kernel will be used to run proprietary programs. This knowledge implies that they consent to having their code used this way.
There are no useful libraries that are not LGPL or BSD or otherwise usable by your user-space program. Every time this comes up people say exactly the same one: readline. Yes that is GPL, but I think you will find it pretty useless for a driver. And that is a pretty pathetic example.
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.
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));