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?

Comments

What exactly are you trying to keep secret?

[Brian the Bold]

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.

not revealing intellectual property versus GPL

[John_Sauter]

I suggest you divide your code into two parts. Write a device driver which does not reveal any of your secrets but provides support for your application, which uses the device driver to interface to your device but need not be licensed under the GPL. Put all code that would reveal any important secrets into the application.

John Sauter (J_Sauter@Empire.Net)

Not sued != legal

[amorsen]

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.

Keep the kernel clean

[Outland Traveller]

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?

Re:Keep the kernel clean

[Outland Traveller]

Exactly what good would it do NVidia if they opened their sources so that ATI can copy it and have a "solid OpenGL feature set" like them?

What part of "all other things being equal" did you not read?

Having said that, I'd still rather see graphics board hardware vendors compete on the merits of their hardware, rather than make their drivers undebuggable and closed source.

Our application heavily uses the NVidia cards for specialized rendering, and as solid as their linux drivers are, they are not very solid. Our applications regularly crash their driver doing perfectly legal openGL calls. When this happens we get NO USEFUL DEBUGGING OUTPUT. Either X crashes, or the system hangs, with no logging, even if you supposedly enable logging in their driver options.

It is an arduous process to track down exactly what sequence of calls crashes their drivers, write an example app, and then send it in to NVidia to fix sometime in the next 2-4 months. It would be so much more helpful to see for ourselves where the problem is occuring. We've asked for drivers with better debug multiple times, but they won't provide any because of "IP Issues".

On top of all this, there's issues with them not properly supporting various kernels, their lack of official support for linux related questions (their community message board is useless for getting an answer to serious questions beyond installation), and the fact that you no longer have a single source for the linux kernel builds. On top of this you now have to deal with kernel tainting and all the irritation that causes.

I remember reading an article last year about The Weather Channel sponsoring a team to improve ATI's linux drivers. I think it's only a matter of time before other reasonably performing graphics cards offer good accellerated openGL drivers that ARE open source, and ship with the linux kernel. When that happens, there will be little reason for us to stick with closed source NV.

Re:OT: Law School for Geeks?

[scoove]

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*

Re:lawyers

[flossie]

The major difference is that if you include a copyrighted image/paragraph/etc in your original work (whether by permission or via fair use) the copyright on the cited work does not infect the remaining 90% of your original work.

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.

So maybe you ought to think about this issue a little more before you post this tripe again.

Maybe you should read the GPL again.

Re:Userspace programs may not be protected

[spitzak]

User space programs *ARE* "protected from the GPL".

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.

Re:Protect?

[istartedi]

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.