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.
Cue 10,001 Slashdot folks ANL posts... :)
~Dalcius
Rome wasn't burnt in a day.
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.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
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?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
Weird, I came to slashdot.org with the intention of posting a Very similar question.
I recently downloaded the Apple developer kit, and basically signed away any right to disclose what the hell is available on their developer site. They use this "IOKit" for writing device drivers, but I want to write an open source device driver for Serial-to-USB converters (the iBook unfortunately has no serial or parallel port!!) So does anyone know of any resources where I can learn how to write a device driver for OS-X without using the closed-source developer kits Apple provides?
Why stick up for big business?
You need to look at exactly what parts of your hardware a GPL'd driver source would reveal, and whether there is really any need to avoid a GPL'd driver for this reason.
Only the people who know what the hardware does and why the features in question need to be kept secret can make this decision.
-- BtB
John Sauter (J_Sauter@Empire.Net)
Everybody should freely share everything and love one another, like they do on Star Trek. The Federation has no need for money, even the warlike Klingon empire has advanced past the need for capitalism. Only the short, swarthy, large-nosed, devolved Ferengi use money.
Please read my fanfic about how the people of Star Trek freely share everything and love one another!
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.
Wouldn't access to your source be beneficial to the customer? If this was a pure software device, I'd understand, but surely you make the money on the hardware. Drivers are usually trivial to reverse engineer anyway.
1. You cant write userspace drivers.
(that is unless the kernel already have a
driver for your chips, and you want to add
someting to it)
2. Kernel drivers/code that are not released under a GPL compatible licence are illegal.
Many vendors do it though, e.g. nvidia. Its no
less illegal because of that.
Isn't OSX just another flavor of UNIX?
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.
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.
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.
The fact that NVIDIA and Rational have not been sued does not imply that they are legally in the clear. There are certainly several kernel developers who have said clearly that the "module exception" invented by Linus Torvalds does not extend to linking to their code. So far they have not sued anyone. Maybe they never will.
Finally! A year of moderation! Ready for 2019?
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
---
When you come to a fork in the road, take it! --Yogi Berra--
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.
Have you got your LWN subscription yet?
You KNOW what answer your going to get here. Open source is good. Your company lawyer is up on things a bit and I would follow their advice.
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.
See also the article "Pick and place: Linux grabs the embedded market" on http://www.e-insite.net/ednmag/index.asp?layout=ar ticle&articleid=CA253780&pubdate=10/31/200 2. Besides other information it describes some licensing issues and solutions with embedded software
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.
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).
Yes, I have heard of that.
What size shoe do you wear?
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.
Nobody wants to force you to give away some original work that you don't want to make a gift of. However, you should examine what someone could do with a gift of the source code; the obvious answer is 'buy more of your embedded network products'; if that's what you want people to do, and if the gift is really yours to make (i.e. it really is original work), maybe you should consider it.
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"
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.
James
Linus is not the freakin' copyright holder. He is the copyright holder of a significant portion of the code, but not all of it.
There goes a whole bunch of "IANAL" posts. Come on, i am ready ;)
Open Source Java Web Forum with LDAP authentication
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?
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?
An aspect, which I'm sure has been tossed around, is that the GPL won't let those involved "lose" their intellectual property, it will only strengthen it. The free support of the community, for something which is useful, can far outweigh the risks of going GPL. Though, I should point out, that GPL isn't the ONLY good open license. I particularly like the BSD license when dealing with "for profit" software. Take the Apache Foundation for example. Most of their software, all?, is BSD style licensed. Covalent is a company which makes money from that licensing. So, as you can see, it is worth while opening up the source, just a manner of deciding what you want people to do with it. For profit, BSD, for anything, GPL. The end result, IMHO, is that they won't have to waste time and money with cease and desist orders, if they use BSD licensing. It's a more clear avenue for business uses, where drivers are concerned. Drivers and other modular pieces of software which enable devices hold a special kind of importance for companies. Almost a "trade secret" mentality. Problem is, they're usually written to a specification which people can pay for, license, etc, and then build their own anyway. Hope you got something out of this.
--SuperBug
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.
Go for source driver. It will be included in kernel (if it is not too ugly). This is big win.
-- Wanna textmode user interface for ruby? http://freshmeat.net/projects/jttui/
I had gone through this with a co-worker a number of years ago over an ODBC driver that had been released under GPL and due to the rammifications of the GPL we would not be able to use the software. now my memory is a bit fuzzy but I think we had contacted the author to re-release the driver under the LGPL (either Lesser or Library) which if my mostly roasted braincells keep telling me was written exactly for these types of scenarios. I don't have the exact details but you could look into it.
I think the driver was the openlink iODBC driver (which depending on which version you look at is under GPL/LGPL)...take a look at the following circa jan 1999
That is, create a small GPL'ed kernel driver,
and put your intellektual property in userspace libraries.
As soon as you start distributing GPL'd code in addition to your proprietary drivers you will be in trouble. The GPL only allows you to distribute the GPL'd code if any code that you link to it is likewise GPL'd or under an equivalently free license. At that point you are out of compliance with the license, and thus have no right to distribute the GPL'd code.
So I'm sorry, but I agree with your lawyers on this one.
--
BitTorrent in C -- LibBT
http://www.sf.net/projects/libbt
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.
Got Code?
I tried to give them a few examples of companies distributing binary only drivers (NVIDIA and Rational)
Note that (at least with NVIDIA), they started distributing source for _technical_, not license issues. It was too costly for them to evaluate and ensure binary compatibility with so many versions of the kernel. So, initially, they released obfuscated source, so you could compile, but not really understand. If they were to fall under the GPL, this would not be permitted.
The company was very concerned about GPL issues and consulted a lawyer - who advised us to go for a user-space driver... Is writing a user-mode (and hence not very efficient)
From a technical perspective, if you don't *need* your driver in-kernel, don't put it there. I mean, if you're doing a storage or filesystem or ethernet driver, you usually _need_ to be in kernel. Otherwise, you usually don't... I learned this lesson by having a driver rejected for inclusion, because it didn't belong in kernel.
That said, for most of the subsystems, there are user-mode APIs that are low-level enough that you don't take a huge performance hit from going to user-mode. USB devices, for example, take a _very_ small performance hit from going user-mode.
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.
A deep unwavering belief is a sure sign you're missing something...
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.
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?
Releasing a binary only driver is not "supporting Linux." If I need a device, I'll buy one that has source drivers available, thank you very much.
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)
Your lawyer is an idiot. Change it. Ask next lawyer, etcaetera. Seriously, NVIDIA is _DISTRIBUTING_ a linux driver, binary only.
So I can avoid buying your products.
You are using a technically inferior and philosophically inferior OS for use in embedded products.
Switch to NetBSD and your problems are solved.
Really, most drivers don't to much more than copy bits to a card or setup DMA so the cards can do it themselves. On startup they do a little initilization. Really, if you want to know what commands are sent to your device you could hook up a PCI analyzer to the bus and watch everything. The only other thing special you could be doing in your driver is some kind of packet mangling to send the packet to you hardware. If there is something really cool that you do in your driver now, I would guess your company has patented the idea. So there really should not be much harm in telling the world see how to initilize and use your card.
It's not like we are not talking about some propriatery device that only a select few make. But rather a network adapter which recently everyone and their particular dog have made. There really is not much you could not find in another driver.
I put together a dead simple driver that only translates interrupts to blocking reads and poll/select. This allows me to eliminate hard polling loops and/or high latency sleepy loops. Beyond that, all of the I/O is done in user mode. This is for a 16-bit, I/O based ISA card, so it doesn't exactly strain the system performance. In testing I've found if you can use the ins() and outs() system calls to perform large chunks of I/O in big whacks, the perfomance is indistiguishable from I/O in kernel mode. Of course, this may only be true for the ISA bus.
However, if I do end up writing a kernel mode device driver, I will have no problem licensing under the GPL. I think some companies are just too paranoid for their own good.
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...
The "Secure Digital" slot requires a binary only kernel module. It is shipped with the Sharp Zaurus.
If Sharp (large, big company) doesn't have a problem doing it, then you shouldn't either.
http://www.myzaurus.com/
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?
-Aaron
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
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.
First you could always use one of the BSDs and not worry about it.
Second, Yes you can do a bianry only driver if it is a loadable modual.
Third, It is a stinking device driver release it and score points with the open source people out there. I can not believe that a drive driver contians anything all that special.
GPL and embedded systems are an interesting case. Suppose I created an MP-3 Player and burned some Open Source software into the ROM. Do I ship a CD with everydevice? It will do the customer no good that is for sure. Somebody out there could use it to make there own MP3 player I guess. Could I put it on my website? if so I could put it soo deep that I doubt that anyone would find it but is would still be free to download.
It almost seems like a new GPL is needed for embedded system. Maybe an EGPL. For the ebedded device I am working I am planning on offing the interface freely available. I can tell you that the people that might want to use this device would rather I hand them a lovley documented API than the source code.
I have one question... What is the difference between source and binary? I had to write in hex at one time to program an ebedded chip. A hex listing is as much source code as c source code. If I wrote a device drive in Hex then the binary version would be the source code. Yes I know it is a loop hole but it is there.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
It doesn't infringe the copyright of the Linux Kernel to write code against the kernel-module specification and distribute it in binary-only form. However, it does infringe that copyright to distribute the Linux Kernel.
The GPL is a license to distribute the kernel under certain conditions. Those conditions are incompatible with including a binary-only module linked to the kernel. There are several companies distributing binary-only modules right now, but none of them provide it linked with the kernel.
Since this is for an embedded device, I think you're stuck: do it in user-mode, distribute it separately from the kernel (two CDs in the same box doesn't count) or figure out how much you'll make from the Linux market and how much it'll really cost to GPL your driver.
-- Brian T. Sniffen
Quoting the good parts
And continuing a bit later
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!
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:
Will I retire or break 10K?
Is writing a user-mode (and hence not very efficient) driver the only way for a company to protect it's intellectual property?
I think that question has a problem in itself. The GPL is about protecting intellectual property. Perhaps the lawyer should read it better.
Now I am sad.
Trying to keep you code closed is both greedy and inefficient. Open up the code.
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.
In brief it states that you can make binary only loadble modules with major restrictions. Most of the kernel system calls are cut off by setting a non-GPL "taint" flag. You can get around this by modifing the kernel but that is strictly unethical and most likely in breach of the GPL. The best option I see if you to create a generic driver that can be GPL'ed and have the IP bits placed in userland.
-- J5
You might consider either the eCos operating system, or one of the BSD's. They both allow you to do what you want.
http://www.welton.it/davidw/
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.
Like others have stated, you will have a bigger problem: you'll end up rebuilding your driver for every linux version you want to support (including vanilla), and that introduces other problems - noteably for the one maintaining it. You'll have to decide what flavors you want to support and then recompile things after each new release... and you'll have to keep in mind other "customized" kernel versions, like RTLinux or RTAI.
Likely you have the Rubini book "Linux Device Drivers"- there he explains the license terms you're talking about on p.12.
Who can then buy a budget version and "upgrade" it with a ROM image from KazaaLite. Works every time.
Then it's a pain in the neck GPL users:
1) You can't distribute it with the rest of the free code (which means we can't just 'apt-get install' it)
2) We can't improve on it
3) Your module will never make it into core kernel or core distributions
4) The free software community will simply choose hardware for which 1-3 don't apply.
Commercial software is a pain in the ass, quite simply, and that's why we don't use it.
RTFA.
What part of "embedded devices" don't you understand?
In every embedded app I've worked on, the performance requirement was "fast enough to meet the spec" and not "as fast as possible." Or as my senior project advisor insisted, "real time" != "real fast."
Real engineers benchmark, either in simulation or the lab. Unless you can prove in advance that a usermode driver will fail to meet the needed performance, write one and see how close you get. Depending on your app, you could find that even in usermode you've got time to spare.
In other words, solve the technical issues first, because you might find that the other stuff becomes non-issues.
-cb
Still working on it...
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.
I think it's because all the good starship designers, builders etc. are in starfleet and they only make starships for really good captains. Or something like that...
"Lawyers are like pubic hair, u'll get 'em and there's lots of 'em but they don't really seem to be doing anything." The side-lines spectators....
Man....I gotta remind myself to tell that to one of my friends who's going to law school to become a corporate lawyer.
AHAHAH
anyways, if u have any analogies or jokes about lawyers (esp if it deals with it in a Slashdot-way) just reply.
It's all in good fun.
The following assumes the device in question uses embedded linux on a stand-alone device, such as a router, switch, etc.
This will probably get me flamed to hell and back but...
In theory, one could use embedded linux and device drivers as a binary in a stand-alone device and distribute the source code on a ROM built into the device, accessable only using the linux implementation in the device. By having the UI of the device limited to what it can do, i.e. no access to a shell or text editor, one can make it extremely difficult to access the source, but you have still distributed the source.
One has complied with the letter of the GPL. Specifically Section 3, subsection a, because ROM is a "medium customarily used for software interchange" and the source is being distributed with the binary. The only thing is that the source is not in an easily accessable or usable format.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
It's just a question of getting few bytes of obfuscated machine code into the kernel space and using those bytes to massage other bytes around. Extreme case would be to provide a GPL "driver" that reads bunch of bytes from anywhere and jumps to correct spots in that to get things done. The GPL part can do all the necessary calls to other parts of the kernel if required.
How would that be linking or derivate work? (Provided that the bunch of bytes is constructed independently from other involved things.) Extreme ways of separating the propritetary bytes from the main kernel just create some overhead, but the above approach would still be quite efficient.
If you're going to be creating what is essentially a substandard driver, someone else will probably write a better driver anyway(which will likely be open source), so you may as well either do it right the first time, or just say to hell with it, and just publish the hardware specs so someone else can easily write the driver that they'll end up writing anyway. I think this makes the whole legal issue unimportant.
--Not to be worried, Pitr fix.
Unlike most of the posters trying to give reasons not to Free the drivers, you've actually made a point that stands up. But there is something odd about it. It only makes sense for a very short time period. Binary drivers compared to source available won't stop the competition from reverse engineering your stuff, it just makes it a bit harder. Within probably 3 months in most markets (and I think that estimate is very much on the high side) the whole issue will have become totally irrelevant. But your customers are then stuck - even though you're gaining no further advantage by keeping the source to yourself, the customers difficulties caused by keeping the drivers closed continue as long as the hardware is still in use, which can easily be years.
So a suggestion to manufacturers in this situation, go ahead and release the binary drivers, a la Nvidia, initially. But, a few months later, when this is no longer the cutting edge hardware of the moment, open the source up. You save yourself a lot of support problems, your customers will love you for it, and you're really not losing anything at that point anyway - the secrecy has already outlived its purpose and gained you everything it could gain you already.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
> for it's embedded networking products
Slashdot, where illiteracy is valued above anything else.
It don't matter what the hell he is talking about as a enterprise customer I ain't buying your shit if it does not come with source drivers.
Got Code?
We went through this process with our (tech-savvy) lawyers on the Ethernet STB (Set-Top Box) project where we had several person-years of effort in enhancing the MPEG decode and video drivers far beyond what was available from the chip vendors. We were moving from VxWorks to *nix to reduce costs, get better functionality and a better debugged OS.
:)
The lawyers spent way too many hours reading the GPL - the result was that we would have had to either limit performance by putting stuff in user space or give away the IP we had developed - neither was a goof option.
We ended up moving to FreeBSD instead - it doesn't have the GPL problems and is a lighter-weight kernel better suited for embedded applications anyway. The FreeBSD port was only a couple of weeks before we had the basic video path working with ported MPEG and video drivers. We spent more time arguing about the GPL than doing the port
Please, please, please mod this up. I wish I had mod points today.
LRC, the best-read libertarian site on the web
Keeping your driver current with kernel releases and dealing with user support for kernel version incompatibilities carries a cost. Go from there
The crucial part of the wording of the GPL that you need to worry about is distributing an "integrated product". There is a real difference between your situation and NVidia's and your lawyer has (rightfully) recognized it.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
First, IANAL.
x -gnu-license.html which contains a post from Linus where he explains that the Kernel Module Interface is actually LGPL.
:
Second, take a look at http://www.gcom.com/home/support/whitepapers/linu
Next, see http://www.gnu.org/licenses/lgpl.html Read section 5. In particular, the paragraph
"If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)"
This leads one to believe that Binary-Only Device Drivers are A-OK.
Nvida and other graphics board developers aren't the only ones providing binary only drivers.... Adaptec only provides binaries for their RAID controller drivers - no sources at all. Not even
an "intermediate buffer layer"
The spirit of the LGPL licence seems to be "If you can upgrade the LGPL code without having to recompile the Proprietary stuff, and continue to have everything work, that's ok."
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.
The FSF is not the holder of the copyright to the Linux Kernel so that anything that they say is not binding on Torvalds and Co. It is the Linux developers who have to decide how the GPL applies.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
I can see an argument against the GPL for software writers but I had always assumed that it was a dream for hardware people that, presumably, want to get support for their hardware spread far and wide. What am I missing?
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
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
No. Hum a few bars for us.
that you clearly have the source code to your company's PABX and laser printers. It must be a pain blowing the flash roms and unscrewing the hard drives when you want to recompile the O/S to keep up with kernel patches though.
You can have device drivers that are not dependent on hardware. kHTTPd and Tux come to mind. I'm sure their are others.
Holy s-, it's Jesus!
According to the GPL, you may not distribute GPL and non-GPL software in a combined form. You can use them together. Your customer can use them together. You can even distribute them on the same media. You may not distribute them in a combined form.
For embedded devices, this offers a trivial solution:
Put the GPL stuff on one flash card, put the non-GPL stuff on another flash card, put both cards in the box, and instruct the customer to put both cards in the device upon purchase. Put absolutely no GPL software on the non-GPL card, and put every last scrap of source code for the GPL card onto a CD which you include in the box with the device.
Oh, and in the manual in the license agreement, advise the customer it is unlawful to sell the device while the two cards are installed.
Of course, this means that you also have to seperate the software into modules and keep track of which ones are or are not GPL. But if you're just starting the project, that shouldn't be too much trouble.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
By all means, pursue the loadable module approach. Your company is under no obligation to gpl a proprietary product.
Open source might mean that variable pricing (i.e. crippled versions of the software for cheap customers) would be easier to break.
But commercial != proprietary. It doesn't look good to the 'business community' if we're always discussing problems with commercial software, when the actual problem doesn't have anything to do with the fact that it's commercial.
The growing number of very satisfied users and businesses which have switched to the rock solid high performance FreeBSD is a clear indication that your business should support FreeBSD first, then GPL'ed OSes. FreeBSD and the BSD license makes it easy for you to have highly satisfied customers and grow your business.
Why not develop a driver for a BSD platform, rather than Linux, and then port the driver over? You would avoid the GPL initially, support open-source unix, and have a prior pproduct to avoid GPL issues.
It is a blatantly false myth that using a closed source driver will protect the secrets of your specialized hardware interface from competitors. Sure, it may make the task slightly harder, but it absolutely will NOT prevent your product from being reverse engineered. Furthermore, some of your customers may be frustrated by not having the source-code. If it was I making an embedded systems purchase, I would insist upon having any relevant driver source-code both for audit and for customization to my needs.
Perhaps you should show your managers a good book on reverse-engineering techniques. Show them how easy it is. Show them how everything 'hidden' comes into plain view under the 'light' of a logic analyzer and disassembler.
Well,
if you can go user space - go user space - this is
a much better choice then kernel choice:
1. easier way to distribute binary programs
2. no need for compilation during upgrade
3. kernel is not 'tainted' so it will be easier to
debug with other problems
If you can go user space - ALWAYS go user space.
Actually many things (like Rio stuff) should
(and hopefully eventually will)
be removed from kernel into user space drivers/programs.
Regards,
Kubus
they don't want to get sued themselves for giving bad advice
I suspect this guy's company would also like to err on the side of not getting their ass sued off.
I don't understand what the point is of making the driver closed source -- I mean, how much *logic* are we talking about in this driver? If this is such an amazing, sophisticated thing, it should probably be running in userspace.
May we never see th
Legal issues aside, if you aren't going to release the sources to your driver, please don't bother releasing Linux sources at all. I buy Linux-compatible hardware because it won't end up getting outdated when a new version of the OS is released and because I can actually fix it when it misbehaves. By shipping binary-only drivers, your company is only taking up market share that could be occupied by companies that are willing to ship sources.
Thanks for all the postings...
:
:)
I would like to summarize my conclusions after reading all the comments and articles I was referred to.
Botom line - the lawer was right, user-space driver is the only option for a company that does not want to take chances of establishing a legal precedent.
Two main problems
1. The situation about binary modules is not clear - even Linus's so called "exception" is not that clear as some people want it to be. Meaning that I can not convince the company management that the chances of being sued are minimal. Meaning that we can not use binary modules.
2. The situation with embedded products is even more complicated (as somebody pointed out) because we actually do ship a GPL code - we ship the device which runs GPL Linux kernel.
P.S. As for the technical issues about partitioning the driver into kernel and user space portions or using a BIOS model (a-la Sony Playstation) - well, the question actually was about legal issues
P.P.S. To all these who never worked for a hardware company and believe that the company can opensource it's drivers - well, one simple example : NVIDIA Detonator 3 driver increased the performance by 30% IIRC. Don't you think that ATI would love to look at the source code ?
Legal issues aside, if you aren't going to release the sources to your driver, please don't bother releasing Linux sources at all.
Oops--that didn't make much sense. What I meant was:
Legal issues aside, if you aren't going to release the sources to your driver, please don't bother releasing Linux drivers at all.
Since they make the user intstall the software, they force the user to agree to a EULA. Typically an EULA will trade you the right to run the software for a promise to not reverse-engineer anything, disasemble anything, and all sorts of other stuff you'd normally be entitled to do with something you bought.
If your distribution method would not typically involve end-users running an installer (and thus being forced to agree to a EULA), I could see where the lawyers might have qualms.
Since I'm not actually a lawyer, here's a supporting quote from someone who is: Eben Moglen of the FSF
Read the full article at http://www.gnu.org/philosophy/enforcing-gpl.html
They'll never respond. Well, maybe it's just me. I encountered a problem when a program I was writing (under GPL) turned out to violate a Mitsubishi patent. FSF completely ignored me.
If binary-only drivers end up being illegal to run with Linux, then that will be the death knell of Linux. Not really, though. It would be easy to fork Linux, and replace all the header files with ones in the public domain. There is enough corporate interest in Linux now to do this. (If I were MontaVista Software, I would start working on this now.)
BTW, the inclusion of GPL header files is the only unknown about binary-only driver viability because the only other way you could form a derivative work is through linking, and the linking is done at runtime. Therefore, the result of the linking process is never distributed, and the GPL does not apply if there is no distribution.
I'd much rather have the case where the lawyers *know* they don't know anything than the case where they *think* they do because one of them downloaded and installed a device driver once.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
You have argued that copyright law is ubiquitous and of wide influence. It affects your magazine? Sure. That's quite different from being viral. (Actually, this is a pet peeve of mine -- "viral" has extremely negative connotations, but something being viral certainly doesn't mean it's bad -- it's just a particular method of propogation. Of course, MS PR flacks are having tons of fun with the negative connotations).
Now, I'm not saying that the GPL is bad, but it's certainly a reasonable argument to say that it propogates in a viral manner. That's one of what I consider the more interesting things about it. Once a small piece of GPL code enters a project, the entire project must become GPL, and start pumping out GPL code fragments which can then "infect" other projects.
It's hard to define what's "good" and "bad", especially since this isn't a simple model of "what helps this project" but "what provides everyone with the most benefit in the real world". However, I still feel that there's a reasonable argument that the GPL is actually good for its hosts -- symbiotic. It's designed to help reduce code reimplementation, and helps widely-used code be debugged.
To help drive my point home, one other thing that might be considered a symbiotic virus (at least in one point in time) would be Christianity. Ignore, for the moment, present complaints about the religion being obsolete or holding back technological advances. It certainly spreads virally -- each person is "infected" by the meme, "converted", and "encouraged to spread the word". Host resources are used to assist the virus in propogation. However, there are major benefits Christianity has provided to human society. If you're living in a society with not a lot of law enforcement (think, where people live pretty much by the sword (think of the Dark Ages and earlier), you have the threat of an ultimate magistrate (God, Judgement Day), and strong encouragement to not attack/betray/cheat your neighbors. That, in turn, helps the community-organism survive, and all the units that compose the community-organism are better off. Hence, a symbiote.
May we never see th
On a similar note: what happens with GPLed demo apps?
If you want to put out a "demo" version of your software, and then later hand out the "real" version, it would seem that you'd run into problems -- unless you have two separate codebases. The person could just get your source, undefine IS_DEMO, and recompile.
I wonder if you can reasonably hand out code already processed with cpp. Probably not.
May we never see th
So exactly what is the problem with making your drivers (on Linux only) GPL? You are in the hardware business, not the software business, right? What nightmare scenario are you avoiding by not allowing folks to tweak and redistribute drivers for your hardware? The drivers aren't going to work for anyone very well until they fork over money for the hardware the drivers go with.
As the copyright holder, you'd still have the right to redistribute the drivers on other platforms under whatever other license you want.
It depends.
In real life, you probably want to have multiple apps running. You probably need to have the driver service the device at a decent number of times a second. Each time you need to service the device, you hit a context switch.
However, if the only thing running is the kernel and the userspace app, you will not experience any context switches.
May we never see th
There is a good article in EDN magazine that discusses the GPL in embedded systems. According to the article, if you keep your applications, device drivers,etc.. seperate from the Linux kernel and contain no GPL code, your code can remain proprietary. This is what Sony, IBM, Borland , and Oracle are doing
you may develop for bsd and avoid the gpl shit
-- free software from the top of xiaodong mountain
You wrote:
> Is writing a user-mode (and hence not very
> efficient) driver the only way for a company
> to protect it's intellectual property?
As you are selling the hardware, not the device-drivers, why not GPL the Drivers as well?
GPL _does_ protect your intellectual property!
Any competitor using your code has to publish it as well which he certainly does not want to.
Sven
Please see the GNU FAQ on this point, which I quote:
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in.
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, so plug-ins must be treated as extensions to the main program. This means they must be released under the GPL or a GPL-compatible free software license.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.
Drivers are not a borderline case. They do much more linking and data structure sharing than just invoking main with options. Their program, the kernel, "dynamically links plug-ins [drivers], and they make function calls to each other and share data structures".
There is a way to allow proprietary modules, but it requires a special license clause for the platform; see again the FAQ.
The inability to create proprietary plugins to extend a free platform is an important and possibly deliberate problem with the GPL. It makes it more difficult to build proprietary software by imposing an arbitrary restriction on its relationship to GPL software.
I would suggest looking up court cases that publishing on the Internet equals distribution. They can't be very hard to find.
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.
It sounds like your organization is genuinely trying to do the right thing. The FSF is eager to help organizations like yours become compliant with the GNU GPL. The FSF's general counsel Eben Moglen has said that he spends a good deal of time helping people become GPL-compliant. Perhaps he could help your company too.
Digital Citizen
I'll suggest a reason why certain manufacturers might not want to release driver sources. Suppose you have two competing products. One is a rather complex hardward based implemetation. The other is a rather simplistic hardware design with most of the functions implemented in software. WinModems come to mind but there are other "devices" where this can be done as well.
In a hypothetical design, if the vast majority of the functions can be moved to software, then even though the end users THINK they are buying a hardware solution they really are buying a software solution. This implies that if the "drivers" are open sourced, then the competition can easily match the product simply by assembling a primative hardware support card. The fewer functions actually implememnted in hardware the cheaper it is to build the card.
On the other hand, if most of the functionality of the card is handled in hardware, then the drivers become less of an issue. If the drivers are not all that significant then there is no reason not to release the sources.
The example of a WinModem can perhaps illustrate this. In the end - the modem interfaces to the real world on 2 wires. Voltages are applied to these wires at various levels and for various durations of time. As long as the interface device can interpret and create these signals - it qualifies as a modem.
The modem can be fairly complex, interfacing to the CPU via the serial interface where all the signaling and compression and error detection and correction is done on the card. In this case the device driver must deal with interupts and so forth, but it is handed bytes that are real bytes.
On the other hand, the modem can be very simple, providing little more than the digital equivalent of the analogue voltage levels it sees on the twisted pair. This leaves it up to the driver to decode that signal. In such a case the vendor is almost masquerading as a hardware vendor because perhaps 90% of the job is done in software. Clearly, and manufacturer who goes to the lengths of eliminating the majority of the hardware in his product and replacing same with a software implementation burried in a device driver is not going to want to let people get their hands on the device driver.
Or did you misunderstand him?
but was told that these companies do not distribute binary only drivers - they only allow you to download them from a web site
In what way is providing something for download not distributing it? Certainly under copyright law that constitutes publication!
Linus has stated tons of times and this has being covered tons of times
...),
i ces.com
everywhere.
You can have NON-GPL drivers in the Linux Kernel as a module.
You won't be able to compile a monolithic kernel with your driver.
This means that you might need to use a initrd image if you need it at boot time.
Things can get messy if you need your driver to access some "virtual" fs to read
the initrd image in the first place.
My advise is to try to convince your bosses that GPLing the drivers would make things
really easy for you as a developer and can be shared with other embedded developers.
Specially if this is related to common pieces of hardware, like memories (flash,
buses and so on. It is even possible that similar problems have being covered before
and it is available (guess what...) under GPL.
Good places to start:
http://www.linuxdevices.com
http://alllinuxdev
"There is NOTHING in the kernel license that allows modules to be non-GPL'd....
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."
More detailed article: Oct 24 LWN. I believe your lawyer is right. You either do userspace driver, GPL driver, or open yourself up to threat of lawsuit. I think the threat is very real; we tolorated binary-only kernel modules when we needed them because we were small. Now we're big enough that if you don't support Linux well in your network hardware, it will significantly cut down on your business. We don't need to tolarate them anymore, and it's plausible that in the not too distant future, we won't.
IBM is releasing OCO (Object Code Only, trust IBM to make a TLA from it) Linux Kernel drivers for
various S/390 hardware.
I guess that if IBM lawyers think it's OK to distribute it, your company can relax.
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.
assert(expired(knowledge));
I hope that helps. If you are ever in need of info, always hit Google.
assert(expired(knowledge));
but i really wouldn't touch binary only device drivers , and i would especially never use it in an embedded system , haven't you still realized why embedded engineers are flocking to use linux , because of the source ..
so if you're product has a contender which provides GPL'ed drivers and you only provide binary drivers , guess which product i would use in my embedded system? , please make you're boss aware of this .
link with program != link with library.
Libraries are things explicitly DESIGNED such that the finished product is a pile of functions you want other people to call.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
but you should really just GPL the driver.
Even the GNU folks have made exceptions in their stance on the GPL in order to make their product the "standard", i.e. Bison. I think that there is a strong argument for allowing this in device drivers as well. It's one of the exceptions which could strengthen the stance of the kernel as a whole.
It would be foolish to restrict drivers in this way, since well written drivers for newer hardware is still in my opinion one of Linux's weak points.
I havent read the actual comments in question but hedging on whether or not to allow such proprietary code to be distributed would be a sign to me that the whole idea and implementation of the GPL, even as close to home as the Linux kernel, has not really been thought out by its proponents and therfore send up major caution flags.
On a side note i feel that saying that code compiled with gcc should be GPL'd since it created the byte code is moronic and in my opinion a masked attempt to envelop code that would or could otherwise be totally unrelated to GPL code at all.
Microsoft should use this thread as a commercial.
I was crazy back when being crazy really meant something. (Charles Manson)
As a matter of fact, the lawyer is quite right about the matter of writting a non gpl-conformant module to the kernel. You may consult a lawyer, or you may read the GPL FAQ.
The apropriate solution would be one that made all the software that use the kernel APIs open sourced and GPL conformant - and, ona separte software layer, make the proprietary calls to your device, without touching the kernel API, but using an API on your own GPLed layer, which license contains exceptions of the GPL to allow the use of the proprietary part of the software.
Actually, there is this whole session on the GPL FAQ dealing with these issues.
-><- no
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.
Well... this may be what Disney would like you to think, but a little thing called "fair use" is supposed to allow you to quote excerpts from any copyrighted work in order to effectively talk about said work. To simply read or use the work you can usually go to a library or similar source, which has 'a copy of' the work (contrast with 'a license to') available for loan.
Work that is derived from the original work is controlled by the copyright holder of the original work.
If this were true in classic copyright law, there'd have been very few parodies ever created and fewer still actually distributed. Fortuneatly this wasn't the case.
Any proprietary software with a "license" is viral in the sense that it is attempting to change law and control users far more than ever precedented in history. Just like the GPL is viral in the sense that it also foists this really nasty "license" nonsense on the public. Now, the GPL would be somewhat nicer if it only attempted to control distribution of GPL'd work (and might have had a foot to stand on in classic copyright) instead of also controlling derivitive work. Oh well, add RMS to the list of those trying to steal my freedom I guess.
Both "proprietary" and "free" software efforts have had a great impact on recent legislation that attempts to change the way copyright works. So while a "software license" wouldn't have meant a hill of beans 20 years ago, it might mean something today... God help us all.
I am not certain but doesn't the tivo's linux kernel have some binary only drivers in it?
It is at least 2 orders of magnitude harder than reading the *commented* source.
Furthermore it may be `easy' technically, but the person doing the reverse-engineering may not be the one writing the competing piece of software or designing the piece of competing hardware. The reverse-engineer can only write a spec, from which a clean-room rewrite/redesign can be done by somebody else.
This is how Compaq reverse engineered the original IBM-PC. It took ages and the size of the ROM was minuscule compared to today's firmwares.
If you do not beleive in GPL'ing your deried work (ie, from the GPL'ed kernel) why don't you get the kernel code be licensed to you in a way that suits you. /usr/src/linux/CREDITS is a good start, identify every developer/company writen pieces of kernel code (start from Linus perhaps), get them to license the kernel the way you want it (by paying them some incentives like money, shares etc.. I guess), and distribute it with whatever license you like.
Hope that helps.
Bret writes for New Architect (nee Web Techniques), very well done mag for which I continue to pay...
You can reach him at bret@lextext.com, according to links at New Architect Magazine on-line.
Or check out his list of articles there by searching for his last name. He's articulate - and makes sense - I am not a lawyer, so this is in no way a defense of that profession :-)
You may not get a personal reply, but I'll bet he's looking for sticky legal issues such as this for his column!
Redundancy is good; triple redundancy is twice as good! - Me.
English has never had an Academy telling us how to speak. Our base grammer and core vocablary is a simplified combination of Old English and Norse, and half of our words are loan words - mostly French or Latin - that we picked up on the way.
American English started as a deliberate attempt to simplify English.
Yes it's equally logical to refer to a corporate body as singular or plural. In law it is singular but English predates that legal fiction.
I use the English version (cause I am) which reflects the particular dialect I speak, but in the end does it really matter?
Boring Old Fart (40, married, 3 kids...er no...make that 49, married, 3 grown up kids...it's been a long time)
We had a similar issue hooking up gdb (GNU debugger) to a new and highly confidential (at the time) chip architecture (IA64).
The goal was to keep all the knowledge of the chip as isolated from the GPL code as possible. In our case, we were running a simulator. We kept the simulator seperate from gdb and communicated via an RPC-like layer over a socket.
What does this have to do with your problem? The concept of isolation and creative workarounds to legal concerns. I would think that as long as your driver is a loadable module, it would have a similar effect of being isolated from the core OS and hence legally safe. Given the comments I've read about Linus' stand on this issue, it does not seem to be a problem.
"No matter where you go, there you are." -- Buckaroo Banzai
A few rants...
/. weasels pay attention the the damn question posed, and stop with the "But I think you should GPL the code" crap. If he wanted to see a long thread of argueing nonsense, he could have just posted some pro-microsoft view and saved us all time. To the original author, looks like /. isn't going to be much help either...good luck with your project.
I wish someone would post a black/white GPL ruleset on the internet somewhere. Courts can decide the shady cases, but let everyone else understand and stop arguing so damn much.
And Linus can think whatever he wants, he can't be allowed to sway Linux around because it is GPL'd. He doesn't get to change the GPL because people find a loophole, thats not his domain.
And why the hell can't any of you
Finally, why are people so keen on killing closed-source business. GPL code doesn't have a friendly community, but a forced one. I can see no reason why an open development community couldn't survive while still allowing people to create closed source proprietary projects. Challenge yourselves. If they piss you off, make their product, release it opensource/free-of-charge, and kill their business. If you don't care, let them make money and shutup.
You may be able to get away with implementing only parts of the driver in Linux.
Put in a driver pasthrough so your user space driver can have all the access a kernel driver might have.
This way your user space driver would be seprate but working in tandum with the simple kenel driver.
Or ask Linus for a seprate liccens or a liccens exception. Offer to send money to the FSF in exchange.
Quickly what intelectual property exsists in a driver?
Why dose it need protecting?
A driver is just code to support a product. What IP could there be?
Some lines of code?
The legal side is right I think it's a business mistake to reguard anything in a driver to be IP needing legal protection.
What possable avantage dose this give anyone?
I know the answer. Compeating companys benifit by not restricting it's costummers. Your products software will not be upgradable should the consummer want to.
The compeditor who dosen't restrict his users will get your constummers.
And Microsoft...
I don't actually exist.
Perhaps. But in this case, I'd claim that you aren't a hardware manufacturer at all; you're a software manufacturer with an unusually elaborate dongle.
And I would agree with you.