Slashdot Mirror
GPL Issues Surrounding Commercial Device Drivers?
Demiurg asks: "My company has recently decided to support Linux for it's embedded networking products which means that I'm starting to write Linux device drivers for our hardware. The company was very concerned about GPL issues and consulted a lawyer - who advised us to go for a user-space driver, saying that this is the only safe way to avoid GPL issues. I tried to give them a few examples of companies distributing binary only drivers (NVIDIA and Rational) but was told that these companies do not distribute binary only drivers - they only allow you to download them from a web site (which is not an option for an embedded product). What does Slashdot have to say about the issue? Is writing a user-mode (and hence not very efficient) driver the only way for a company to protect it's intellectual property? Please refrain from giving answers like 'all code should be GPL' - although I personally may agree, such answers will not help me convince management to make the change." Are there any lawyers (or readers with the right legal knowledge) out there that can confirm or contradict this recommendation?
So, you got your advice from a legal consul, and you're thinking about ignoring it in favor of advice from the /. crowd? Is that smart?
Je ne parle pas francais.
Seems like you might get good info by directly talking to the FSF or linux kernel mailing list... I'm sure some people would piss and moan about binary this and proprietary that, but in the end I think you'd find more people eager to help expand linux's reach in an optimally efficient manner. IIRC the FSF's head legal eagle is a guy named Eben Moglen (there was something posted on /. just yesterday that involved his name, again IIRC.) Personally, although IANAL, making something available for public download from a website sounds pretty much like "distributing" something. True, the user has to decide to download it, but then again your users would have to decide to buy your particular widget (thus potentially getting the linux driver) also...
News for Geeks in Austin, TX
Nvidia and others do "distribute" binary-only drivers. Just because they don't actively send out CD's with their drivers does not mean they do not distribute them. Under the GPL both methods are concidered a distribution. As far as writing drivers, as long you use the driver module method and do not need to directly change any preexisting kernel code, I do not believe there is any problem at all. That is how Nvidia and others can get away with that.
So you your company should go for the best possible driver, to increase hardware sales. If that means GPL'ing the driver, you can also benefit from the expertise of a lot of developers.
Ask your lawyer how distributing something over the internet is not distributing?
NVidia are distributing binary-only drivers. They do a trick however, where the code that needs to be loaded into the kernel is (L)GPL, and then this cpde interfaces their binary driver. This both allows a buffer to the GPL code but also to support various different versions of the kernel with the same driver.
Moreover it allows for a lot of naive trolls claiming that Nvidia is distribting the source-code because they have seen this little module.
I don't quite see what is lost by releasing a device driver under GPL.
:)
You get:
1) an army of geeks who will instantly worship your company and buy your products;
2) a slightly smaller army of geeks who can actually help you fix bugs in your own product FOR FREE.
You lose... erm, nothing?
The only drawback is that the interface to your hardware (register maps etc.) are no longer as secret as they were. Perhaps you're concerned about competitors stealing your ideas based on that knowledge? Well, think about it this way - if they badly want that information, they will already be reverse engineering your products and your binary-only drivers with a debugger and some elbow-grease.
IMO - you have nothing to lose. Embrace the future...
These sigs are more interesting tha
The GPL would only begin to apply if you used existing code that was already GPL'd and incorporated it into your own project, thereby making your code part of somebody else's project and therfore governed under the GPL, which would force you to release your code.
Simply using library functions of GPL'd software doesn't mean you have to release your source code. It does mean, however, that you should credit somebody else's work for giving you the functionality that you didn't write yourself.
Kylix is a perfect example of a binary-only development platform from Borland that has done it this way.
However, if you release a binary-only driver, you must ensure that it's compatible with the various Linux kernels.
You do not have to release the source code.
I disagree with the lawyer. User space programs may not be protected from the GPL.
I know there is a comment in the kernel version of the GPL from Linus stating that user space programs are exempt from the GPL as applied to the kernel. That probably won't protect you because:
1 - Linus is not the only author of kernel code, and thus cannot provide a complete exemption from all kernel source. Any author of kernel code may disclaim that exemption.
2 - There are a number of libraries that are not released under the LGPL: you should be careful to avoid those if you want to remain isolated from the GPL or other open source licenses.
The real issue would be whether or not your code is a "work based on the program" as defined in the GPL. That question will be the subject of intense scrutiny and debate should any of the authors of the used GPL code choose to assert their rights in court.
The GPL is a HUGE minefield to commercial developers. It has not been tested in court. The best your lawyer can offer is an educated opinion based on contemporary interpretations.
Please do not consider this to be legal advice.
Easy. People ask slashdot because slashdot readers have actually had to deal with these matters on a day to day basis. Your average lawyer may see a handful of case studies.
Now, he may have gone to the sort of lawyer that specializes in software licenses (what sort of lawyer is this? a very very rich sort), in which case you're right that it is kind of stupid to approach the trolls and IANALs. But if he went to Joe Q. Publicstein of Publicstein, Stern and Lowe, chances are he'll get a much more specific answer and leads on a case he may be able to point his legal eagle towards. Which could result in a much more informed decision.
By the by, I've got a feeling that the people who MIGHT press a case on the GPL have bigger fish to fry than a company writing a device driver. If they can't catch Microsoft biting GPL code, why are they going to hunt down developers expanding the OSS market?
Hey freaks: now you're ju
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;)
"... but you can love completely without complete understanding." - Norman Maclean, "A River Runs Through It"
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?
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.
If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
I think the keys here are what count as distribution and separate works. Obviously, the GPL was drafted with traditional software in mind and is not tailored toward embedded systems. You have to answer the questions "Is this a work based on the Program [a piece of software covered by the GPL]?" and "Is this an independent and separate work?" Unfortunately, I don't have enough facts about your system, and we don't have an attorney-client relationship, so I can't give you an answer. What I can tell you is that you should make sure your lawyer is familiar with your code development processes and distributions systems and knows enough about software development so that he can draw principled distinctions between different ways of doing things.
Laws affecting technology will always be bad until enough techies become lawyers.
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.
track7.org has all kinds of interesting stuff!
Does the legal community realise that they are in desperate need of lawyers with technical background? If so, are the law schools doing their best to fulfill this need such as lowering admission requirements for people with technical backgrounds or targetting recruiting? Are law schools completely full of English and Philosophy majors that need to get a job or is there some diversity there?
I'm asking because in a year or so I'm going to have a Master's in CompSci and I'm considering my options afterwards. While a PhD would be nice, I've also been looking at law school. I don't think I could resist getting an emphasis in technology law, however I'm not sure what to expect...
My gut feeling is that a loadable module that does not itself incorporate any GPL'd code does not fall under the GPL just because it's run in conjunction with a GPL'd kernel. After all, even if the kernel + driver are considered together to create a derivative work, it's the user, and not you, who creates that derivative work at runtime.
And, the fact that you're using GCC to compile the module doesn't mean anything in and of itself. The real question is the license status of any libs that are linked into the resulting object code file. Whether they are under GPL, LGPL, or something else makes a big difference.
Now for the shades of gray part... any time you're dealing with GPL questions, you have to look at the genealogy of the running executable, working backwards to see what licenses govern the component pieces. It's a very fact-intensive process, and without understanding where all the code came from, you can't come close to giving a reasonable answer.
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.
Do not confuse duty with what other people expect of you; they are utterly different.Duty is a debt you owe to yourself.
> I'd guess that anyone who submits a patch back to ... but I'm pretty
> 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.
"Elmo knows where you live!" - The Simpsons
That depends. The question really should be focused not on the drivers, but on the relationship of the drivers to the solutions that your company sells. If the software is integral to the business, then you really can't reconcile the GPL with IP, and you have to keep it proprietary in order to protect your income stream. If, on the other hand, the driver software is ancillary to the business, then the GPL should not only be acceptable, but also advantageous, as others consider your business' solutions and yet others modify the software. Remember, if GPL'd code is modified (hopefully improved), the modifier is also bound by the GPL on distribution, and your company can use it, presumably to its advantage and free of charge.
But drivers should be. You're making money on the hardware, it's in your interest to let other improve on the software side and port it to other OSes.
If your company objects to the GPL, and you are selling embedded hardware, it seems rather silly to be using Linux. Have you considered using a BSD? Since the BSD license does not require you to give back any code, this might be ideal for you.
If you're running on non x86 hardware, I think NetBSD would be the best bet, since they run on nearly everything.
I'm assuming that since this is mentioned as an embedded product, your choice of Linux is not for the purpose of making your device work in other people's Linux systems, but is instead, for the purpose having a embedded operating system inside your embedded product. If this assumption is true, then I recommend instead to use one of the BSDs for it, e.g. FreeBSD or NetBSD or OpenBSD. The licensing issues are so much easier. FreeBSD is actually the foundation OS in many a network device on the market over quite a range of sizes from small handheld devices to huge WAN switches. Linux is, too, but if the GPL licensing is the big issue, then give BSD a serious look-see.
If the above assumption is not correct, and you are making a device which is to be accessed by a hosted Linux system, then I can at least say this: I won't use your device in my managed network engines (Linux based) unless the source code is open. This is due to the need to be able to fully audit the entire security and not wanting to have to negotiate for NDA source. Lack of source can cut into your market share, especially where security is an issue (affects network devices far more than high performance video cards). So if you have intellectual property in a network device intended for a hosted system (e.g. for example a 10GB ethernet card or an OC-192 WAN line card), try to keep the intellectual property locked up in the device itself as much as possible.
now we need to go OSS in diesel cars
Oh, and I think that this could be a solution to your problem. Write your driver, compile it as a binary with your compiler that allows the use of it's libraries with proprietary products. Then write some interfacing code that probably has to be compiled with the kernel and makes things loadable as a module. Make the interfacing code free (GPL). The binary part with your valuable (?) driver code doesn't contain any GPL code for sure and interoperability with the kernel can be maintained by modifying the code layer inbetween the two.
Two posts (parent and grandparent), neither of which links to any comments, which claim that a second person flatly contradicts himself. Lovely.
Why the hell can't you people find links, anyway?
May we never see th
I just had a vision of a bunch of Asian engineers so excited that they would "pour over" x-ray blowups of integrated circuits.
Sorry.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak