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.
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.
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)
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.
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?
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
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).
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.
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?
Check this with your lawyer:
You place all your propriary code in a library that don't access anny kernel functions or structs (read symbols) directly.
Then you write a GPL "layer" that maps all kernel stuff to your own interface that your lib uses, and calls functions in your lib.
This way you have a GPL module that just happen to need a propriary library to compile.
You can bet your sweet ass that if I have a choice between a card or some hardware that comes with source or a binary driver your binary driver can pack sand along with with the lost sale. I admin clusters for a living and if I ain't got the source I cannot compile a reliable kernel so I have no need for your hardware.
Got Code?
Your comment also flies in the face of the many developers whose create open source programs on Macs.
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?
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)
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.
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.
Ah, yes, but what happens when you're out on the edge of the Federation, you've had to dump your warp core, and when you take your shuttle craft to the local non-Federation trading post looking the a new core, the green-skinned junk yard dealer with the right model warp core wants two NSR-420Z plasma injectors and all you have is a NSR-350 injector, and she doesn't accept American Express?
These are the times when a few bars of cold pressed latinum would save your butt. But nooooooo, you're from The Federation. You don't believe in money.
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.
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?
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.
> 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.
This is not insightful, this is wrong.
See GPL-FAQ:
"You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program?"
Yes.
There seem to be some exceptions for the kernel though, see other postings.
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.
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.
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?
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
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.
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.
Open source might mean that variable pricing (i.e. crippled versions of the software for cheap customers) would be easier to break.
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.
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
All contributers of code to the kernel know that the kernel will be used to run proprietary programs. This knowledge implies that they consent to having their code used this way.
There are no useful libraries that are not LGPL or BSD or otherwise usable by your user-space program. Every time this comes up people say exactly the same one: readline. Yes that is GPL, but I think you will find it pretty useless for a driver. And that is a pretty pathetic example.
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.
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
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
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.
I believe that was me. I do have a wee bit of experience in this, as I work for a company that does a lot of embedded work, and I'm one of the two guys who writes all the company's device drivers. We've even shipped modified GPL drivers from Linux in many of our systems (we modified a GPL ethernet card driver to work under VenturCom's RTX extensions).
I believe this is probably a hit on me, since you replied to one of my postings on this subject by pointing me to this message. However, as stated above, I do work for a hardware company (writing device drivers, no less), and my question still stands.
First off, the example you state is useless for the exact reason that its a proprietary driver: we have no way of knowing what caused the increase. It could well be that certian hardware features for the tested card were not turned on in previous versions of the driver, due to the hardware being ready before the software was. I know that's happened with nVidia video drivers in the past.
I'm guessing from your answer that you are worried about loosing a competitive advantage against a close competitor. I suppose that's possible, depending on your business. But who says you'd loose? It could be that your competitors actually have the superior software.
But more to the point, why should you have to worry who has the better software? If your business is primarly hardware, should you really be trying to compete with software? That isn't your company's core competency.
But, as I mentioned in my other message, I don't really know enough about your business to say. I know it wouldn't hurt *our* business in the slightest. But then, our hardware typically costs over a million dollars when all put together (Flight Sims). You are probably in a different situation.
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
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
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));
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.
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?
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.
These may be the rules in the US. How much do you think someone in Seoul, Taipai or Bombay cares about them?
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.