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?
lawyers (Score:5, Insightful)
Re:lawyers (Score:5, Insightful)
I personally had to convince a VP of Development to consider my alternatives over the simple no answer that came from the corporate lawyer. It wasn't easy, but I was able to pursuade 2 other directors who backed up my ideas. No, this wasn't a dot-com startup, but a nasdaq listed company with a strong 25 year history. The conservatism and resistance to change was mind boggling.
My advice is to do exactly what you're doing. Brainstorm the heck out of this and see if you can make it work. Good luck!
Re:lawyers (Score:5, Insightful)
There may be a connection between `resistance to change` and `strong 25 year history`.
OT: Law School for Geeks? (Score:3, Insightful)
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...
Re:OT: Law School for Geeks? (Score:2, Interesting)
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:OT: Law School for Geeks? (Score:3, Interesting)
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 (Score:2)
You have a point, but would you rather get sued over actions taken from advice taken by your attourney or by your creative tech/geek/programmer/etc.?
But what am I complaining about? It's an interesting question, and I'm sure there are interesting comments, and I'm avoiding work. Yay Slashdot!
No, this wasn't a dot-com startup, but a nasdaq listed company with a strong 25 year history.
You work for Microsoft?
Re:lawyers (Score:2)
When someone eventually sues over the binary drivers packaged with the Linux kernel, people will lose their intellectual property.
The FSF knows this and loves it -- they are out to push their agendas.
BSD or Apache licensing is the way to go.
My advice to you would be to listen to your lawyers -- there is no rational argument to support your claims.
Re:lawyers (Score:2, Funny)
<sarcasm>
You forgot to include the part about the secret alliance between the FSF and Microsoft. After all, the real function of the FSF is to invalidate intellectual property so that it can be used by MS.
</sarcasm>
Re:lawyers (Score:5, Insightful)
FLAME ON--
Actually yes and no. It is incredibly wise to ask the
FLAME OFF--
It is relatively well known the Linus has essentially modified the terms of the GPL under which the kernel is distributed w.r.t. loadable modules to allow exactly this functionality. You write a closed source driver for your odd exceeding proprietary hardware, make it a loadable module (not compiled in) and your driver does not have to be released under GPL. As soon as you distribute a version with the module compiled in "all your IP are ours", but as long as you dynamically load it your ok.
Tell you lawyer to contact Linus to confirm this in writing; he's the freakin' copyright holder.
Linux != Linus (Score:2, Informative)
Re:Linux != Linus (Score:2, Insightful)
> Linus is de facto making him a copyright holder of
> the code in the patch (well, assuming he is also
> the holder of the original code
> sure he has the copyright for the 0.01 kernel!).
No, this is not the case.
> IANAL, but I think it's a safe bet that sending
> a patch (w/o an explicit license agreement)
> constitutes a gift.
It doesn't constitute a gift. Authors have copyright over things they create; that is the law. The copyright of Linux is so widely spread that it is now unlikely that it could ever be relicensed.
Witness the problem when Mozilla relicenced - they had to go and find all the old hackers who used to work on the code to gain their permission to relicence.
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.
Re:lawyers (Score:4, Insightful)
The GPL is not viral, copyright law is. The GPL is an optional license which you can opt out of by simply never accepting its terms. In which case, it has no sway over you at all, and you can walk away unscathed.
However, like all copyrighted works, GPLed software cannot be modified and "made your own". A modified (or "derived") work is just that.
When you use something like a compiler, there's some grey involved as to what the end product is. It has incorporated some headers and libraries that are part of the compiler suite (crt0.o, for example), so it's not just a "printing press for computers". This means that applications which incorporate parts of themselves into their ouput must make a special exception in their licensing terms in order to clarify the status of that output.
Now, here's the kicker... this is true regardless of what license you use! Yep, you can use the MIT/X license, the BSD license, the GPL, Microsoft's EULA (which is legally on much shakier ground than the GPL, BTW because it relies on this idea that you do not own the software that you purchased, which has been defeated as a tactic for books).
The only difference between using the GPL and a weaker license like the MIT/X or BSD licenses is that those licenses allow you to do nearly everything that Copyright law takes away. Not that I'm comparing those licenses to the GPL for any real reason. They're both very good licenses for what they are meant to do.
However, to say that it's the GPL that's viral is silly. Try cutting up a magazine, reassembling the articles and then publishing the result. I think you'll find that copyright law has infected your creative work without the GPL (or any other license) coming anywhere near you.
Re:lawyers (Score:5, Interesting)
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.
Re:lawyers (Score:3, Insightful)
Another absurd statement, but I digress. "Rights" is such a loaded word; it makes laws sound like unalienable laws. Copyright gives certain "rights" to the author at the expense of the consumer. The GPL takes away some of those rights from the author and gives them to the consumer. There is always a conservation of rights. If society gives you the "right" not to be murdered, it impinges on my "right" to murder you. Our perception of which laws are "rights" is coloured by our nature and nurture; there are no absolute rights.
Another absurd troll. Copyright law removes more or less all rights on the part of anyone except the copyright holder. A license is a way for the copyright holder to grant some rights to others. It is their choice which rights they wish to grant and under what terms. If they decide to use the GPL, then they are issuing you with various rights in exchange for your agreement to use the GPL in any work you do that is related to their work in some specific, enumerated ways. If you don't wish to follow this agreement, they transfer no rights to you, and you may not legally use their work at all. If you do agree to their agreement, then you can use their work. The GPL hasn't given or taken or away any rights - the copyright holder has used the GPL to detail under what terms you have permission to use their work in ways that would otherwise violate copyright law. The copyright holder giveth, the copyright holder taketh away - thats the law. The GPL is just a particular codification of their conditions for you having some rights to their work.
Re:lawyers (Score:4, Insightful)
Dude, you are completely full of shit. Copyright law is a little bit viral, but the GPL is ebola viral. 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. How can you gloss over a detail like that. It makes ALL the difference.
Who's full of shit here? You would be able to reprint/reissue your work without the copied work, but until you did that, continued duplication of your work would be a violation of copyright law (and you would remain in violation of it for the prior duplication).
Get a sense of proportion. There is a huge difference between someone who wants to take a GPL'ed app, tweak it a bit, and sell it under a non-GPL license, and someone who wants to take a GPL'ed library and include it as a small part of a non-GPL'ed program. That would be stretching the definition of "derivative work" beyond the level of common sense.
If someone's work is copyrighted then you have no rights whatsoever to duplicate or use it unless they give you such rights. The author of the GPL'ed library has decided to give such rights only to people who give her and others the same rights in return. The author could have chosen to give you no rights whatsoever, in which case, they need not bother with a license at all. When you use somebody else's code, whatever license it is under, it is only legal if they have given express permission to do so. If they have not, or if they have added conditions under which you may use it, the law does not permit you wriggle out of this with lines like "get a sense of proportion."Again, you're full of shit. Each of the excerpts is covered by its own copyright; they aren't infecting each other. If you take some excerpts from Tom Clancy and mix them in with some quotes from Charles Dickens, it doesn't mean that Tom Clancy gets copyright over the Dickens quotes, nor does the public domain status of the Dickens quotes cause the Clancy quotes to fall into the public domain. *THAT* would be viral licensing, and that's what the GPL does.
You need to be careful with that "shit" term. You are right about the lack of "transfer of copyright" in the domain of the printed word. But the same thing applies to software too. The GPL cannot cause transfer of copyright between owners. If there is an existing body of GPL'ed source code and it is merged with or used to derive new source code, the exact same rules apply as they would with books: genuinely new work is copyright the new author, quoted work is copyright of the old author. The point is: without a license of some sort, you have NO permission to use the existing work in any way, not to copy, not to quote, not to use to derive new work from. If the work was GPL'ed, the author has given you permission to use it as you wish, as long as you use the same license for your own work. The author has no copyright claim on your own original work whatsoever. You are free to issue work that is entirely your own under any license you wish. Work that is derived from the original work (and "derived" here is a technical term that may include compile time linkage, but never includes run time execution) is controlled by the copyright holder of the original work. the copyright holder may choose to prohibit you from using HER work unless you choose a certain license. If you don't agree with that, then you have no permission to use her work; if you do so anyway, you are in violation not of the GPL, but of US and international copyright law.
Re: lawyers (Score:5, Funny)
> The GPL is 'viral' in a sense
The GPL isn't viral; it's hereditary.
I have had both GPL and non-GPL software installed together on my system for years, and none of the non-GPL software has ever been infected.
Re:lawyers (Score:2)
Maybe you've been lucky to never deal with lawyers, but perhaps you've dealt with the IT manager who's usually a similar risk-averse type. All they can see if a project goes forward is the risk that they haven't built enough capacity or redundancy into the system and it will fail, bringing their career down with it. So they take a simple $50K project and turn it into a complex $500K project, effectively killing it.
Bring the info you collect here to your project manager and have them make the case to the legal staff. If facts can't convince them then the lawyers have taken over and it's just a matter of time until the company dies.
Brilliant!!! (Score:5, Funny)
Well, boss, I know the lawyer said one thing, but look at all the Linux zealots on Slashdot that say we should go this way instead!!! Some of them even hold jobs and live outside their parents' basement!!
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.
Re:Linus allows an exception for device drivers (Score:5, Informative)
Re:Linus allows an exception for device drivers (Score:5, Informative)
Re:Linus allows an exception for device drivers (Score:2, Interesting)
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.
Re:Linus allows an exception for device drivers (Score:2)
It will not be up to Linus, it'll be between the distributer, reciever and what the courts and the lawyers come up with. GPL'd Embedded systems could be particualry sticky in court, it's probably easier to get a judge or jury to understand seperate files on a disk than on a rom file system.
Maybe Demiurg's company sould consider one of the BSD OSes
Re:Linus allows an exception for device drivers (Score:3, Insightful)
Why the hell can't you people find links, anyway?
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.
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:Context switches. (Score:2)
Tried asking the FSF or lkml directly? (Score:5, Insightful)
Re:Tried asking the FSF or lkml directly? (Score:3, Funny)
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:Tried asking the FSF or lkml directly? (Score:2)
They'll probably recommend that you release the driver as Free Software in the first instance.
And why not? You've got to weigh things up here: is the puported competitive advantage gained by hoarding your source code more important than the loss of efficiency involved in writing a userspace driver?
Distribution Method (Score:5, Insightful)
Re:Distribution Method (Score:2)
That's distribution by the poster's question.
Sujal
Re:Distribution Method (Score:2)
What exactly are you trying to keep secret? (Score:5, Interesting)
Only the people who know what the hardware does and why the features in question need to be kept secret can make this decision.
Re:What exactly are you trying to keep secret? (Score:3, Insightful)
if you're a hardware company, then until everyday people copy your hardware, there is no need to place restrictions on device drivers. even opening up the source in most cases will not hurt your company, unless you're trying to protect how the device communicates.
if you're selling hardware, sell the hardware. give away the software--it's no good without the hardware anyway.
Re:What exactly are you trying to keep secret? (Score:4, Insightful)
Re:What exactly are you trying to keep secret? (Score:2, Insightful)
Imagine an automobile engine computer. Some piece of code you devise allows you to pinch out an extra 5 miles per gallon by adjusting the performance of the engine. Now if you're required to open-source the code, every one of your competitors will have that same code in their next version. If you don't, you've got 6 months to a year before they figure out how you did it. And your higher efficiency gives you a market edge.
Re:What exactly are you trying to keep secret? (Score:2)
> increase that is essentially independent of the
> hardware, you need to keep that code away from
> your competitors for as long as you can.
If it is independent of the hardware it need not be in the driver and therefor the GPL question does not apply to it.
not revealing intellectual property versus GPL (Score:5, Interesting)
John Sauter (J_Sauter@Empire.Net)
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.
Avoid the term "intellectual property" (Score:2)
drive the device without revealing intellectual property
Instead of saying "intellectual property", say "copyrights", "patents", or "trade secrets", which are almost completely unrelated to one another in the U.S. federal and state legal codes. Under which part of the law do you claim your company is trying to protect its monopoly?
Is your company trying to make money selling drivers? Don't. Here's why not [gnu.org]:
Protect? (Score:5, Insightful)
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.
Re:Protect? (Score:3, Interesting)
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.
Re:Protect? (Score:2)
The issue is, obfuscation DOES contributes to protection - at least in this case - theoretically you can always dissect the interface, hiding it permanently is NOT the goal - You only need to delay your competitors doing so until you roll out your next generation product.
The Anonymous Coward does have a point. Closed source drivers DO delay competitors from discovering hardware trade secrets.
Easy solution (Score:2)
You create a binary only, non-GPL driver and only
provide it as a module in your device's filesystem that gets immediatelly loaded by your custom init scripts.
If this driver is needed before your userland can fully initialize (for example, it's a custom disk device...ICK), stuff it into an initrd, boot from initrd, load the driver,and then pivot_root over to the real userland and run your init.
As of today, non-GPL binary only driver modules are perfectly acceptable. As long as you do not directly link into the static kernel binary, you do not have to GPL your driver. No legal issues at all.
The counterexample is NVidia (Score:5, Insightful)
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.
Re:The counterexample is NVidia (Score:2)
I use they
2. Do you say they are or they is?
I say they are.
Sorry for being a smartass; I know americans say it differently, but my english dictionary says both forms are correct when using a company-name. I just like to see a company as a group of people and not an entity.
Not sued != legal (Score:5, Interesting)
Get a New Lawyer (Score:2)
He is not a kernel hacker (Score:4, Funny)
Re:He is not a kernel hacker (Score:5, Funny)
In general, do not take advice on how to license a device driver from a programmer. Or, if he/she insists, invite them to be sued. Pay only if they win.
What are they trying to protect? (Score:5, Insightful)
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...
Re:What are they trying to protect? (Score:2)
The whole reason people don't release source code in the first place is to make it harder for the competition to duplicate the effort that went into developing your technology. For hardware companies it might or might not be as much an issue (depending on the product, etc.), but for software companies this is really important, because (like medicine) you have to spend lots of money up front on R&D and giving away your source code to the competition will definitely shorten the time within which you can recoup those expenses.
Re:What are they trying to protect? (Score:5, Insightful)
1) In a technology sector where "time to market" is a crucial feature, distributing source for your drivers gives your competition a considerable edge. Everyone reading this who codes will know exactly what I mean when I say that having a known-good chunk of software to modify is vastly easier than starting from #include <linux/kernel.h>. Drivers are, in fact, a bitch to get right. On a device of median complexity you probably save your competitors a month of dev. time by presenting them with all your clever ideas and a working model on which to base their clone. On a truly clever device you may save them several months.
2) More importantly for some applications, if there are over-broad patents that concern your device, supplying source code can easily make the difference between your opponents having grounds for suit and not having them. Your source code reveals your intent behind your arrays, and the purpose of your function calls. When a lawyer is trying to prove your product is infringing, this is significantly better ammunition than hundreds of lines of debugger output that has to be "interpreted" by their experts.
An earlier poster had what I'd consider the best suggestion. Embed the secret stuff in your app. If your device supports it, make the kernel driver little more than a tool for getting data quickly in and out of user space. This approach has several advantages, among the better is that I (or any user who mucks about with these things) can then upgrade the kernel and recompile your trivial kernel space driver (say past an unrelated, but nasty bug) without begging for your help. I can do this to fix bugs you haven't encountered and present you with fixes for bugs you can't easily recreate, but others may be suffering from.
Best of luck.
Re:What are they trying to protect? (Score:2, Insightful)
Maybe his job if an ARMY of geeks contribute to the driver development. The hardware might also be blocked by 3rd party IP.
Playstation 2 Linux (Score:2, Informative)
Isn't this what the export GPL was made for? (Score:2)
So, as long as you don't work around these DRM/License restrictions, shouldn't things be ok? After all, any code you run in Linux will be using the kernel in some way, so if you extend the GPL argument too far, things get messy indeed.... IANAL, IANAKD, blah blah blah blah blah.
Driver in ROM (Score:2, Insightful)
Also, how will this product interface with Linux? Via PCI or USB interface or actually run Linux? If it runs Linux, then I don't think you need to have users download drivers since it will be a closed system. But, on the other hand, you will just have to bite the bullet and use the user space driver, which is actually a standard.
Why don't you take a look at this article [linuxdevices.com] and a reply article here [linuxdevices.com]? There is are more discussions.
What about UDI? (Score:5, Interesting)
1) Avoid any GPL issues -- if your driver is written to the UDI spec, then it's not a derived work of the linux kernel, as your driver can just as easily run on non GPL OS's
2) Avoid having to constantly update your driver -- the UDI spec stays the same even when the kernel version changes. Even if your driver was GPL'd, if it's not part of the base kernel distribution, you are still responsible for chasing down changing kernele interfaces everytime a new major (or sometimes minor) kernel is released.
UDI has gotten a lot of flak from the community, for various reasons, most of which I think are unfounded (such as, "It will allow Windows users to steal our quality Linux drivers", etc.), but I won't go into that rant now. The only technical concern is performance. I don't think that will be much of an issue, since most of the time the CPU is sitting there waiting for devices anyway, so if it has to expend a few extra clock cycles during this time that it would otherwise be idle, then it's not that big of a deal. Of course, this could be an issue with high-speed devices such as video and scsi controllers.
Anyway, I think it's worth checking out.
UDI doesn't circumvent the GPL. Alternatives exist (Score:2, Insightful)
> written to the UDI spec, then it's not a derived
> work of the linux kernel, as your driver can just
> as easily run on non GPL OS's
Point 2 is correct but point 1 is wrong. Your device driver isn't a derivative work of the kernel, *but* the combination of the Linux kernel and the UDI device driver *is* a derivative work of the kernel. The Linux kernel links to UDI which links to your device driver.
Previously, Linus allowed binary modules to exist because most of the kernel wasn't modular so there's only so much that a binary module can do. The trend in Linux kernel version 2.6 is towards making as much as possible become a loadable module so recompiling the kernel will eventually become a thing of the past. Because of this, the tolerance of binary modules is decreasing. Don't be surprised if binary modules are eliminated altogether in Linux 2.8.
IMO, the best way to design your device driver is to use usermode. Note, user-mode doesn't have to be slow. The linux kernel web server was removed from the kernel because it was possible to get the same performance benefits with a user-space program. In order to get this added performance, you may need to patch the kernel and release the source code for that patch. However, if done right, you can do it without revealing your intellectual property. Just define a generic interface which sends bytes to your device driver. The logic for the API would be in user-space. To get added speed, you have to eliminate user-space to kernel memory copying. Look at the "zero copy networking" code for details on how to do this.
Supply user-space, allow kernel-space for download (Score:2, Interesting)
First off, I can't imagine embedded system user (especially Linux user) having a problem downloading a driver from a website. Don't we all ñheck the 'Driver updates' on the web regardless of what's on the CD?
But if it absolutely have to be bundled with the product, I'd put the legally-safe version in and make the 'performance' kernel-space version available for download (and note that in accopmanying documentation).
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.
Our drivers are fully GPL on purpose (Score:2, Insightful)
It took years (3 to be exact) to get lawyers comfortable with the GPL. Honestly, I prefer the FreeBSD license on all levels, but that's just my opinion.
None-the-less, we've migrated to a GPL-only policy based on our lawyer's requirements, so we're fully compliant. I'd post our URL here, but last time I got moderated out;)
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
Nvidia *does* distribute binaries! (Score:2, Insightful)
I'm not sure how this is even an issue for your company unless you are not talking about writing your device drivers from scratch, but are instead modifying GPL'ed code with the intent of redistributing it on your hardware. If that's the case then you are legally obliged by the GPL to release the source code for those modifications.
If you're writing your own drivers from scratch then you can do whatever the hell you want with them: it's entirely your own work and you're not stealing from people by taking their GPL'ed work and rebranding it as your own with a few tweaks.
So, where's the issue? Can you clarify exactly what it is that you're doing?
Re:Nvidia *does* distribute binaries! (Score:2)
And, as we've also seen, a large number do.
Dinivin
Keep the kernel clean (Score:3, Interesting)
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 (Score:3, Interesting)
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.
place propriary code in a library (Score:2, Insightful)
You place all your propriary code in a library that don't access anny kernel functions or structs (read symbols) directly.
Then you write a GPL "layer" that maps all kernel stuff to your own interface that your lib uses, and calls functions in your lib.
This way you have a GPL module that just happen to need a propriary library to compile.
But I am not going to buy your binary only driver (Score:2)
I am impressed (Score:3, Funny)
Module API (Score:5, Informative)
Living With The GPL (Score:5, Insightful)
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.
Proprietary modules may be on their way out... (Score:3, Informative)
Talk to Montavista (Score:2)
GPL questions are very fact-intensive (Score:5, Insightful)
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.
GPL not a problem (Score:2)
-Aaron
Arrrgh! I am seeing the worst advice ever here (Score:2, Interesting)
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.
Linus discused this issue recently (Score:2, Informative)
Quoting the good parts
And continuing a bit later
DSL Driver - Efficient Network 3010 (Score:2)
Alcatel MicroElectronic was probably trying to save Alcatel Network's StingRay from losing its marketing edge (they lost anyway).
Henceforth, we're were restricted to providing the kernel-specific modules (Linux 2.4.8)
And worst, 3010 fell into obvilion (like it should) because it was a WIN-MODEM!
Linking is the key (Score:2, Interesting)
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.
UDI and other 'wrapper' interfaces (Score:2, Interesting)
Use FreeBSD or NetBSD or OpenBSD instead of Linux (Score:3, Insightful)
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.
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.
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.
Re:If you agree... (Score:2, Offtopic)
Re:If you agree... (Score:2)
On the other hand, maybe he is like me and writes proprietary code by day and open code by night. There are always ways to balance what you believe in and how you are getting paid.
Hello Mr Fluffy wuffy... (Score:2)
BECAUSE HE GETS PAID.... because he has to eat. This isn't that big a deal and he is talking about getting Linux some support.
If he was raving about the GPL and being threatened with the sack because it didn't fit with the companies aim then that would make him a nutter.
I use MS at work... why ? Because all the clients use MS. I starve to death, or I could make a reasoned judgement that this is not an important issue.
Wrong! (Score:4, Insightful)
Bruce Perrens says it perfectly here. What matters to the industry in the creation of software is the use of open/patent/royalty-free standards.
Claiming all Linux users subscribe un-equivocally to the FSF's views about Free software is a provocative statement that indeed does deserve to get modded down for being a Troll.
Re:Another Winner (Score:5, Insightful)
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?
Re:Related question. (Score:2, Informative)
Your comment also flies in the face of the many developers whose create open source programs on Macs.
Re:That's not how they do things on Star Trek! (Score:2, Funny)
These are the times when a few bars of cold pressed latinum would save your butt. But nooooooo, you're from The Federation. You don't believe in money.
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.
Re:Userspace programs may not be protected (Score:3, Interesting)
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.