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?
Well, yes, because lawyers are usually cautious with how they interpret things. They don't want to get sued themselves for giving bad advice.
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)
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?
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 protection of the interface is a big issue for many hardware companies *cough* Nvidia *cough*. if you have some genius method of accelerating by writing 16 fewer bytes per accelerated operation to tee card than your competitors then by seein gthe source than can then see this and possibly derive how it was done in the hardware, thus mimicking it.
it's great for all of us users, but for the company in the lead *cough*Nvidia*cough* it would suck.
GCOM's whitepaper captures part of this response.
Never meant half of the things I said to you. So you know, there's a half that might be true - G. Phillips
Then LISTEN TO YOUR LAWYER, S/HE IS RIGHT!
Then consider something like NetBSD or eCOS if the GPL is not acceptable to your needs.
A friend of mine is going to law school at DePaul. He graduated with a dual degree in ee and cs. Going into patent law isnt the most exciting field around, but they pay you in cubic foot blocks of cash.
You only really fall into problems if you link with other code that is GPL (but yes, you can compile commerical programs with gcc, no problem).
Therefore, you can't actually put your driver into the kernel, but only as a loadable module.
(There have been many debates about whether loading a module is "linking", but the consensus seems to be that commerical drivers are OK in this form).
And your management has to be totally blind to think that NVIDIA doesn't distribute a binary driver.
What NVIDIA does is have all of their source code in a binary EXCEPT for the hooks into the kernel (aka init_module, etc...) so that you can compile this against your specific kernel headers (so it will work against a wide variety of kernels, and not just say, 2.4.18 or something).
This is probably the same approach your company should use, but in the embedded world you can probably get away with requiring a specific kernel version, since those things are very specialized.
And writing a user space driver is hard on Linux, because userland doesn't let you get at the hardware very well. You might also want to try looking at UML (User-mode Linux) for this approach, though I am not sure if it works on embedded systems.
The last thing pc hardware needs is yet ANOTHER layer of bloated, buggy code between the user and the hardware device. The solution to every so-called computing 'problem' these days is just to slap ANOTHER layer on top of what's already there. If what's there was designed well in the first place, the extra layers wouldn't be needed as much (notice I didn't say 'at all'). Java, .NET and its competing ilk are prime examples. In their case, you're mostly right, the cpu does spend most of its time idle (that doesn't mean I would want 3dsmax .NET, quake 5.NET or VST.NET either) making some applications viable as the performance hit is tolerable.. However, with low level hardware interfaces, its 100x worse. At that level, every clockcycle DOES matter. Developers don't seem to realize that any latency added by a clunky driver and/or 'wrapper' interface adds the absolute minimum response time a device can have on a given system for users. Therefore, a primary goal should be to MINIMIZE latency. Even drivers written for Microsoft's WDM interface take quite a performance hit compared to the older VXD interfaces.
This issue is important to other devices besides vid cards and drive controllers. If some new fangled mouse had all these nice features, but had a 20ms delay because of either poorly written drivers or the use of some driver wrapper, then, to me, the device is useless. I wouldn't buy it. Same goes for network cards, sound cards, game controllers, etc. I don't want some NIC driver grabbing 20% more cpu than it should on a busy server just because the developer used some wrapper to save time. Using a wrapper is just pure laziness, and has no place in a final production product that is charged for. If you're going to support an operating system, whether it be Windows, Linux, or anything else, do it RIGHT. I realize writing a driver for a wrapper can save development time, but it usually just ends up dumping problems on the user instead, when the user is PAYING the company to solve their problem in the first place. After all, that's why they're buying their device, right? Anyway, the less code between me and the hardware, the less chance of some stupid bug preventing me from using/enjoying the product I just spent money on. Come on, as a hardware developer, their employees are getting PAID to support their product. They don't have an excuse to be lazy.
In every embedded app I've worked on, the performance requirement was "fast enough to meet the spec" and not "as fast as possible." Or as my senior project advisor insisted, "real time" != "real fast."
Real engineers benchmark, either in simulation or the lab. Unless you can prove in advance that a usermode driver will fail to meet the needed performance, write one and see how close you get. Depending on your app, you could find that even in usermode you've got time to spare.
In other words, solve the technical issues first, because you might find that the other stuff becomes non-issues.
-cb
Still working on it...
We went through this process with our (tech-savvy) lawyers on the Ethernet STB (Set-Top Box) project where we had several person-years of effort in enhancing the MPEG decode and video drivers far beyond what was available from the chip vendors. We were moving from VxWorks to *nix to reduce costs, get better functionality and a better debugged OS.
:)
The lawyers spent way too many hours reading the GPL - the result was that we would have had to either limit performance by putting stuff in user space or give away the IP we had developed - neither was a goof option.
We ended up moving to FreeBSD instead - it doesn't have the GPL problems and is a lighter-weight kernel better suited for embedded applications anyway. The FreeBSD port was only a couple of weeks before we had the basic video path working with ported MPEG and video drivers. We spent more time arguing about the GPL than doing the port
Does the legal community realise that they are in desperate need of lawyers with technical background?
Being an official intellectual property attorney groupie (waaay to many of my friends are in the legal profession), I think there's a plausible explanation as to why there are so few technically savvy attorneys.
Look at one of the fundamental skills most attorneys need: a reasoning ability that permits them to see/argue/communicate/explain either side of an issue. Some would call this relativism, but I think that reflects a deeper personality issue that most attorneys I know don't have - they do have a sense of "one right answer" deep down, but must overcome it in their profession. Plus, much of this kind of problem solving is abstract/extroverted, e.g. dealing with people to wrestle with the problem domain. Often, these dealings are confrontational and you've got to get a high off of such interpersonal confrontation to survive in much of the legal field.
Contrast that with most technical persons and the skillset requirement that they evaluate a rather objective concept-area and determine the "best / correct answer." Relativism and subjectivity never worked very well in computer science. Combine this focus with the non-social interaction (working with machines, not people) and a general dislike of interpersonal confrontation, and you'll see why technical folks exist here and not on the other side.
Most of the IP attorneys I've worked with subsequently have either been attorney minds who dabble in tech (i.e. they laugh at Dilbert, have read Bill Gates's book, and bought Microsoft stock), or techies who got a law degree. Interestingly, the latter never seems to do very well in the legal profession - every single one I've known has gone back to dealing with computers, not people.
*scoove*
According to the GPL, you may not distribute GPL and non-GPL software in a combined form. You can use them together. Your customer can use them together. You can even distribute them on the same media. You may not distribute them in a combined form.
For embedded devices, this offers a trivial solution:
Put the GPL stuff on one flash card, put the non-GPL stuff on another flash card, put both cards in the box, and instruct the customer to put both cards in the device upon purchase. Put absolutely no GPL software on the non-GPL card, and put every last scrap of source code for the GPL card onto a CD which you include in the box with the device.
Oh, and in the manual in the license agreement, advise the customer it is unlawful to sell the device while the two cards are installed.
Of course, this means that you also have to seperate the software into modules and keep track of which ones are or are not GPL. But if you're just starting the project, that shouldn't be too much trouble.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
ditto for the GPL. If you copy with permission other than the GPL, no problem. If you copy under fair use, also no problem. The GPL only applies if permission and fair use do not apply.
The GPL gives rights; it does not take any away. Where copyright doesn't restrict you, nor does the GPL.
Maybe you should read the GPL again.
flossie
Write now. Defend liberty
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.
Why should a hardware company protect the driver
Imagine that company A's driver code contains a function that writes to a FIFO buffer. Company B looks at it and says "Eureka! Their cards are better because they use a FIFO buffer for that." The next version of Company B's card uses a FIFO buffer.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?