Follow Slashdot stories on Twitter


Forgot your password?
Linux Software

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?
This discussion has been archived. No new comments can be posted.

GPL Issues Surrounding Commercial Device Drivers?

Comments Filter:
  • lawyers (Score:5, Insightful)

    by Dionysus ( 12737 ) on Tuesday November 05, 2002 @12:13PM (#4599797) Homepage
    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?
    • Re:lawyers (Score:5, Insightful)

      by nicodaemos ( 454358 ) on Tuesday November 05, 2002 @12:25PM (#4599906) Homepage Journal
      Many times the corporate lawyer is a liberal arts person who doesn't understand the finer points of technology and licensing. As such they don't have the background to come up with creative ways for you to achieve your goals while still remaining in compliance with licensing.

      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)

        by Anonymous Coward on Tuesday November 05, 2002 @12:35PM (#4600007)
        "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."

        There may be a connection between `resistance to change` and `strong 25 year history`.
      • 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...

        • 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.
        • 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?



          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.

        • 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.

      • Many times the corporate lawyer is a liberal arts person who doesn't understand the finer points of technology and licensing. As such they don't have the background to come up with creative ways for you to achieve your goals while still remaining in compliance with licensing.

        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? :-)
      • Lawyers can read and the GPL has nothing to do with technology.

        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)

          by GreyPoopon ( 411036 )
          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.

          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.

    • Re:lawyers (Score:5, Insightful)

      by Anonymous Coward on Tuesday November 05, 2002 @12:30PM (#4599952)
      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?

      FLAME ON--
      Actually yes and no. It is incredibly wise to ask the ./ crowd because there are a few of us out here who a) aren't school/college age geeks and b) have ACTUALLY DONE THIS IN A COMMERICAL PRODUCT and worried over the issue ourselves. It's dumb to take the ./ crowd advise in place of your lawyer's advice. Instead the rational thing to do is to ask here and if something looks interesting point it out to the lawyer.
      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)

        by ??? ( 35971 )
        Linus is not the freakin' copyright holder. He is the copyright holder of a significant portion of the code, but not all of it.
    • Re:lawyers (Score:5, Informative)

      by kableh ( 155146 ) on Tuesday November 05, 2002 @12:33PM (#4599988) Homepage
      My company uses Linux in some of our embedded products. Before doing so, and before we had fulltime counsel, we hired a lawyer to go over the GPL and tell us if it was going to present a problem. This lawyer seemed to think that anything compiled with GCC would fall under the GPL, which is incorrect. There are specific exceptions that allow it to be used to produce non-free software.

      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 [] for more info.
      • Re:lawyers (Score:4, Insightful)

        by ajs ( 35943 ) <ajs AT ajs DOT com> on Tuesday November 05, 2002 @02:21PM (#4600560) Homepage Journal
        I'm getting very tired of this mistake. It's being pushed by MS, but it was started by the likes of Slashdotters who don't understand the terminology.

        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, Funny)

        by Black Parrot ( 19622 ) on Tuesday November 05, 2002 @03:27PM (#4601037)

        > 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.

    • Lawyers evaluate the legal risk in a project. The lawyer has no reason to stick his/her neck out. If something does get done, the lawyer has their butt covered if they make sure it uses the most conservative measures possible.

      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.
  • by Anonymous Coward on Tuesday November 05, 2002 @12:14PM (#4599805)
    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?

    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!!
  • by LordNimon ( 85072 ) on Tuesday November 05, 2002 @12:16PM (#4599831)
    You may need to dig up the reference from some mailing list archive, but Linus Torvalds himself has said that he will allow binary-only drivers, as long as they're loadable modules, to be distributed.

    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.

  • by drinkypoo ( 153816 ) <> on Tuesday November 05, 2002 @12:16PM (#4599833) Homepage Journal
    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?
    • Context switches. (Score:5, Informative)

      by cduffy ( 652 ) <> on Tuesday November 05, 2002 @12:22PM (#4599887)
      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.
      • Addition/Correction (Score:5, Informative)

        by cduffy ( 652 ) <> on Tuesday November 05, 2002 @12:26PM (#4599921)
        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).
      • Context switches are indeed something that will slow down any user mode driver because you can't poke directly into the client program's address space, unless of course you _are_ the client program as well as the driver. You can also get interrupt during I/O which can be a bad thing. There are myriad other things that it will slow down however. For one, you can't hook interrupts in a Linux userland program last time I checked. Thus any device driver that wants to receive interrupts must at least make a presence of some sort in the kernel (even if it just delivers signals to a userland program at interrupt times). Also you can't tinker with internals like the scheduler and block caches, so you may be wasting resources you would have had access to there. There are probably more things that someone more experienced specifically in Linux kernel hacking could tell you about.
  • by StandardDeviant ( 122674 ) on Tuesday November 05, 2002 @12:17PM (#4599839) Homepage Journal
    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...
    • I'm supposing all the FSF will tell him is that when he's done his company's gonna have to call it GNU/EmbeddedDevice.
      • 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.

    • Seems like you might get good info by directly talking to the FSF

      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?

  • by ShadowFlyP ( 540489 ) on Tuesday November 05, 2002 @12:17PM (#4599840) Homepage
    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.
    • Even more to the point, Dell preinstalls the NVidia driver one their preconfigured Linux boxes with NVidia video cards. We have one in the office, and it had the NVidia binary drivers installed.

      That's distribution by the poster's question.


  • by Brian the Bold ( 82101 ) on Tuesday November 05, 2002 @12:18PM (#4599855)
    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.
    • this is the same reason device drivers are free. granted they're often only available in binary form, but if i get a piece of hardware by itself i can just go download the driver from the manufacturer (if i can find it).

      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.

      • by Jaeger ( 2722 ) on Tuesday November 05, 2002 @01:29PM (#4600342) Homepage
        if you're selling hardware, sell the hardware. give away the software--it's no good without the hardware anyway.
        I personally agree with you, but I can see two reasons why companies might think this is a bad idea:
        • Suppose most of the interesting work takes place in the driver (as in the case of a software printer or modem -- although I imagine this could be the case in other devices as well). The driver then provides an emulation layer between the rest of the operating system and the hardware. Some enterprising clone maker could easily throw a DSP, a transformer, and an RJ-11 jack on a PCI card, copy the driver, and sell a software modem for far less than the original manufacturer.
        • There are plenty of companies in the world who still think that it is possible to ship a device that cannot be reverse-engineered, and that any additional information released to the general public is additional information that the Asian clone manufacturerers will use to screw them in the marketplace. They ignore the fact that said Asian clone manufacturerers have enough manpower to disassemble their drivers line-by-line and pour over wall-sized X-ray blowups of their chips to reverse-engineer the silicon at a transistor level. The only people they're hurting in this situation are those who use free operating systems -- and, by extention, their own market share, because those who use free operating systems won't buy their products.
    • Some embedded processors run on a very low margin. If some piece of your code enables a performance increase that is essentially independent of the hardware, you need to keep that code away from your competitors for as long as you can.

      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.

      • > If some piece of your code enables a performance
        > 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.
  • 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)

    • 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.

  • Protect? (Score:5, Insightful)

    by OttoM ( 467655 ) on Tuesday November 05, 2002 @12:20PM (#4599863)
    Why should a hardware company protect the driver? If you make a quality, high performance driver, more people would want to buy the hardware. If you make a lousy, slow driver, not many people would buy the hardware to use on Linux.

    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)

      by istartedi ( 132515 )

      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.

  • This is a really simple problem to solve.

    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.

  • by Isle ( 95215 ) on Tuesday November 05, 2002 @12:22PM (#4599885) Homepage
    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.
  • Not sued != legal (Score:5, Interesting)

    by amorsen ( 7485 ) <> on Tuesday November 05, 2002 @12:23PM (#4599888)
    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.
  • With all the lawyers out there, I am sure there is one who agrees with you. If you feel shaky about it, cash out your stock options first, and update your resume
  • by Daniel Phillips ( 238627 ) on Tuesday November 05, 2002 @12:23PM (#4599890)
    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.
  • by CaptainAlbert ( 162776 ) on Tuesday November 05, 2002 @12:24PM (#4599899) Homepage
    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... :)
    • You forgot: army of competitors in the same market who now have your source code which they can use to make their product compatible with your own, while you are stuck spending tons of research dollars on reverse engineering their product to compete.

      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.

    • by Art Popp ( 29075 ) on Tuesday November 05, 2002 @01:16PM (#4600254)
      Though I agree that those should be important considerations in this company's decision, the dangers involved are neither imagined nor trivial.

      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.
    • "I don't quite see what is lost by releasing a device driver under GPL."

      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)

    by GeLeTo ( 527660 )
    Do what Sony did with the PS2 Linux - boot a Runtime Environment that has all the required drivers before running the linux kernel. Make open-sourced Linux device drivers that will use the Runtime Environment drivers. This is a similar to using BIOS calls from within the kernel.
  • IIRC, working with new kernels, certain portions of code are protected against modules which aren't GPL or GPL compatible. There are mechanisms in the new modutils providing support for tainted modules, etc... Any kernel hackers out there feel free to disagree with me.

    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)

    by boy_afraid ( 234774 )
    I may be way off base, but what about embedding the driver in the hardware via ROM chips? Wasn't there a previous /. article about this?

    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 [] and a reply article here []? There is are more discussions.
  • What about UDI? (Score:5, Interesting)

    by tchuladdiass ( 174342 ) on Tuesday November 05, 2002 @12:30PM (#4599955) Homepage
    UDI [] is a driver abstraction layer that can have multiple benefits:

    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.

    • by Anonymous Coward
      > 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

      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.
  • 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).

    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).

    • by MyHair ( 589485 ) on Tuesday November 05, 2002 @01:25PM (#4600312) Journal
      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?

      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.
  • I believe that lawyers just haven't digested the GPL AND the GPL hasn't had any case-law precedents to support or refute it. Like most professionals, lawyers are conservative and risk-averse. It may be years before any organization embraces the GPL because lawyers don't know how to handle it.

    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;)
  • by oolon ( 43347 ) on Tuesday November 05, 2002 @12:37PM (#4600022)
    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.

  • You are correct that NVIDIA distributes binaries only, your companies lawyers are confused. There is no problem with them doing this because their drivers are original works not licensed under the GPL. The only thing that can stop them doing that is if the customers have an ethical objection, and as we've seen a large number don't.

    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?
  • by Outland Traveller ( 12138 ) on Tuesday November 05, 2002 @12:41PM (#4600054)
    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?
  • Check this with your lawyer:

    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.
  • You can bet your sweet ass that if I have a choice between a card or some hardware that comes with source or a binary driver your binary driver can pack sand along with with the lost sale. I admin clusters for a living and if I ain't got the source I cannot compile a reliable kernel so I have no need for your hardware.

  • Module API (Score:5, Informative)

    by be-fan ( 61476 ) on Tuesday November 05, 2002 @12:52PM (#4600117)
    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.
  • by Compulawyer ( 318018 ) on Tuesday November 05, 2002 @12:52PM (#4600121)
    I am a patent guy, so my licensing experience with the GPL is rather limited (except for using GPL'ed software). However, upon a cursory review, it seems as if this section of the GPL is the cause of most of the concern:

    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.

  • by Florian H. ( 6933 ) on Tuesday November 05, 2002 @12:55PM (#4600138) Homepage
    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? []
  • I would talk to the fine people at Motavista [] as they deal with this everyday. I think they also may know some lawyers who are educated on this issue. If your doing embedded they can also be really useful there too :) (Note, I don't work for Montavista)
  • by n8ur ( 230546 ) on Tuesday November 05, 2002 @01:08PM (#4600215) Homepage
    IAAL, so unlike most of the posters here, I'm not going to give you a black-and-white answer :-)

    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.

  • When investigating various network processors, I see that all of the vendors I have looked at supply drivers for embedded Linux. In fact, Linux appears to have better support than any other operating system (including VxWorks and QNX). GPL is not an issue for them, even though the drivers are highly proprietary. Why not ask an embedded Linux vendor like Monte Vista (Hard Hat Linux) and see what response you get?

  • OK, for starters do not believe that binary only drivers are acceptable. Read this recent post for more infomation: Linus on binary only modules []


    Then consider something like NetBSD or eCOS if the GPL is not acceptable to your needs.

  • Check out the LKML archive .2/0603.html

    Quoting the good parts

    I will re-iterate my stance on the GPL and kernel modules:

    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 inteface per se, and should feel very confident that they can show in a court of law that the code is not derived.

    The module interface has NEVER been documented or meant to be a GPL barrier. The COPYING clearly states that the system call layer is such a barrier, so if you do your work in user land you're not in any way beholden to the GPL. The module interfaces are not system calls: there are system calls used to _install_ them, but the actual interfaces are not.

    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.

    And continuing a bit later

    Side note: it should be noted that legally the GPLONLY note is nothing but a strong hint and has nothing to do with the license (and only matters
    for the _enforcement_ of said license). The fact is:

    - the kernel copyright requires the GPL for derived works anyway.

    - if a company feels confident that they can prove in court that their module is not a derived work, the GPL doesn't matter _anyway_, since a copyright license at that point is meaningless and wouldn't cover the work regardless of whether we say it is GPLONLY or not.

    (In other words: for provably non-derived works, whatever kernel license we choose is totally irrelevant)

    So the GPLONLY is really a big red warning flag: "Danger, Will Robinson".

    It doesn't have any real legal effect on th emeaning of the license itself, except in the sense that it's another way to inform users about the copyright license (think of it as a "click through" issue - GPLONLY forces you to "click through" the fact that the kernel is under the GPL and thus derived works have to be too).

    Clearly "click through" _has_ been considered a legally meaningful thing, in that it voids the argument that somebody wasn't aware of the license. It doesn't change what you can or cannot do, but it has some meaning for whether it could be wilful infringement or just honest mistake.
  • I've helped worked on the DSL Linux Driver for an Efficient Network 3010 DSL PCI adapter card and we had the exact same problem only this time, it was Alcatel MicroElectronic Legal that refused to release us from our Non-Disclosure Agreement with them.

    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)

    by streak ( 23336 )
    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.
  • by Skapare ( 16644 ) on Tuesday November 05, 2002 @03:23PM (#4600998) Homepage

    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)

    by bored ( 40072 ) on Tuesday November 05, 2002 @05:24PM (#4602127)

    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.

  • by runswithd6s ( 65165 ) on Tuesday November 05, 2002 @06:51PM (#4603091) Homepage

    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.

To be a kind of moral Unix, he touched the hem of Nature's shift. -- Shelley