Slashdot Mirror
Open Sourcing Closed Sourced Drivers?
AnonymousIntern asks: "I'm interning at a company where I've signed all kinds of privacy agreements, so I'd ask that you not name me (nor use my id). The company I'm interning with sells a suite of software, along with various boards. Their software got ported to Linux a couple of years ago, but the Linux drivers for the boards (open source) don't have most of the capabilities found in their windows (closed source) counterparts because the company fears releasing a piece of technology in the chips that they've developed. Many people in the company are very level-headed proponents of open sourcing the whole driver (thus giving Linux users the same power they can get running the windows version), but fear releasing their tech. Can anyone suggest a course of action? I know this issue has come up before, but I feel it needs to be continually addressed." Now I'm all for opening driver sources, but if it came down between the choice of more driver support for Linux and Open Source code, I'd be torn. This is a subject I'm sure many of us feel strongly about, so please share your opinions.
Pretty much 100%. If you look at the device drivers Linux comes with I bet a few are reverse engnered. I know the Visor USB hotsync "driver" was built after looking at traces with a USB protocall sniffer for example. A lot of digicam drivers are done the same way. Bocs is also a great tool to help revese engener a driver (by observing the IO crom CPU to card). The (original) BSD Mitsumi CD ROM driver was reverse engenered (in 1991ish). Several ethernet PHYs (because they came on a card that had been supported until the vender changed PHYs without changing the box!). Roumor has it some of those were done because someone decided it would be simpler to reverse engenr the driver then to drive to CompUSA and get an exchange for a working card! Hmmmm, I can't think of more examples of the top of my head, but cd on into your source tree and start reading driver comments.
Hell, some drivers written with documentation had to do a bit of reverse engenering work to see what was really going on because the doco was wrong! (A Lucent Ethernet comes to mind here, and the bringup code for the so-called TurboSPARC maybe too...)
It ain't impossable. For some people (not me) it ain't even hard! Of corse it might be illegl now with the DMCA, but then again it might fall under the interoperability clause (it would definitly seem to me that it should).
First, nobody in the Windows world is making money on hardware drivers. Especially not hardware vendors.
Second, closed source kernel drivers severely limit the user. You are limited to certain kernels, with certain options. You may not be able to apply security patches. And Linus has made it clear repeatedly that if the kernel needs to change and that breaks binary drivers, that's not his problem.
A hardware vendor providing binary only drivers relegates his hardware to second-class citizen status, because there are a lot of people who don't want to put on a straitjacket to use a certain piece of hardware.
Pros on opening the source for the drivers
1) Acceptance in the Linux/OSS community
2) The driver can be part of the linux kernel
3) If there is a bug in the drivers it can addressed quickly
4) People can create alternate solutions for devices
Cons on opening the source for the drivers
1) The cat is out of the bag
2) People can create alternate solutions for devices (Might cut into revenue of other devices)
3) Competion can create a clone of your device easier
And there are there are many more reasons That can be given these are the just a few that I thhough of any more
John Carmack said it best when he refered to Nvidia's XFree 4.0 situation. In a nutshell is said that most linux users want a good working driver over an open-sourced one. That's something I tend to agree with.
If it's a GOOD driver, I don't have any problem using a binary driver. The problem comes in most cases when it's not a very good driver to begin with, adn poorly supported. I'll use the SB Live! drivers before they were open as an example.
They released so-so binary only drivers. They also weren't updated. Which leaves a big hole in even the number of people that can even use it. Drivers have to be compiled for every kernel version, and SMP versions. Creative assumed everyone ran a stock RedHat 6.1 install, and just forgot about everyone else. Although I aplaud Crative's opening their drivers, I would have been happy with closed source drivers that did everything their Windows counterparts do(read Liveware 4.0).
Most dont' want drivers open so they can hack them and make them better. As the case with my Live!, I couldn't even USE them unless I had the source. Since they just supported the 2.2.12 kernel that's on a stock RedHat 6.1 install, I had to re-compile it for 2.2.13-SMP.
So my point being. If it's a WELL SUPPORT DRIVER, most will use it, and like using it. The driver has to be kept right in line with everything your Windows drivers will do, and the same preformance. You also have to release a version for all the recient kernel versions. If it's some crappy hack like what Creative tossed out there before they opened their driver, that's when you'll get the backlash.
Yes, this is a flame bait IP rant.
The ethics and consistency of this group (or lack thereof) amazes me. The vast majority of folks on Slashdot have no stealing music from artists but seem a bit squeamish when it comes to code.
When musical intellectual property is discuessed, the answer is that it's okay to steal it because that's the way it should be done and the music companies are living in the dark. It's RIAA's fault we're stealing music.
Yet, when it comes to source code, we wring our hands and postulate about how we can convince the source's owner that the code should be opened. Why? Shouldn't we take the same track as we did with the music? Isn't it their falut that the code is closed and isn't it our obligation to steal the source and distribute it far and wide?
I say that if the intern has access to the source code the the drivers, he should put it up on gnutella or a semi-anonymous web page and link it from Slashdot. That'll teach 'em.
Why should corporate privacy agreements be any more binding than music copyrights?
InitZero
Seriously, if it comes down to that choice, I'd rather have better support in Linux.
Having been a Linux user for years (starting with an early Slackware distro), I have to say that ease of use is *still* a priority for me - even if I am prepared to dive into config files and the like, I prefer not to. Open Source is important to me as a developer and on a more idealistic level, but in the real world, I'd rather see companies supporting Linux and giving the same level of features (or better) in their software as the Windows users get.
At the end of the day, it isn't every company who is going to take the Open Source path. Those that don't should be gently encouraged, but quite realistically we have to just get on with life and using our computers - and I want to use mine with all the functionality I can get.
"Give the anarchist a cigarette"
A little planning goes a long way...
StarOffice has been like this for years. You acquire a binary that runs reasonably well on Linux but, the source is still closed.
There are no actual requirements to go open source to have your product used on a Linux platform. That's one of the big confusions in the market. People have the mistaken belief that if they release for Linux, BSD, etc... that they have to open their source too.
My office has been taken over by iPod people.
This brings up an issue about which I ahve been thinking for quite some time now, ever since I read the circumstances which gave birth to the FSF. Stallman wanted the source to a printer driver because it was buggy. He went from that starting point to argue that all source should be free. I have often thought that his ends could have been meat by stating that source and modification are free within the community of customers. That is, if I purchase a copy of Word I have a right to the source code, and a right to share my modifications to that source with others who have bought it. But I cannot give it away to someone else who has not paid for it.
This preserves the profit motive and makes it possible to write code whose source is open and whose bugs get fixed, while at the same time enabling authors to charge for what is, after all, their work and their expenditure of resources. It is true that eventually someone's modifications could be so great that he may want to charge for it; again, he would be able to do so. Let's call the original source A and he mods B. The fellow could sell B only to those who already own A, but could sell A+B to anyone, as long as he paid the original author his due for A.
I will admit that this could get out-of-hand if everyone wanted to charge even for slight mods. But again, that could be controlled--specifying that mods of less than 100 lines or something similar must be public domain, perhaps.
I do not believe that I have ever seen anything on the FSF site explaining why something along these lines (obv. not exactly this sort of thing) is not a good idea.
But it's not the drivers they are worried about, it's the hardware. They are afraid competitors can use the drivers to help reverse engineer the card and come out with a competing card.
Exactly what stops competitors from being able to do this? Closed source drivers can be examined, hardware can be taken apart. (You can protect the hardware, but you'd then have problems shipping what is effect a bomb.)
If their device is so industry-common that a competitor merely reading the driver source code is enough to worry about competing implementations being derived, then the originating company has nothing that hasn't already been seen or done and will be challenged by competition in the short run anyway. In this case, releasing the source to the driver would not do the company any harm that wasn't already in the works.
If the device is groundbreaking, then simply publishing its interface (which is all a driver does) can do no harm. Describing how to communicate with the chip in no way reveals how the chip works (unless the chip's functionality depends on already well known techniques).
Let's look at 3dfx: Does describing how to invoke the FSAA (Full Screen Anti-Aliasing) features of the Voodoo chip via driver code give away the inner-processes of how the chip goes about achieving that? No, not in any way, shape, or form. The FSAA is one of 3dfx's main competitive advantages, but is 3dfx worried that other video card manufacturers are going to be able to copy it just because its programmer interface is published? No. Do they think that other companies (NVidia, for example) wouldn't be able to reproduce it anyway if the driver were closed? Hell no. If NVidia thought that FSAA was a make-or-break line item on a video card, the company's chips designers would find a way to reverse-engineer the chip's functions via hardward reverse-engineering, or they would reproduce it from scratch. Is 3dfx now the major video card among Linux users -because- they opened their drivers? You betcha.
I'm no real expert in these matters, but I would go as far as to say that any company having the skillz to reverse engineer and manufacture a clone board, surely should have the ability to disassemble the driver. Sure, giving them it in source form from the start might lessen the amount of work required for the reverse engineering, but I don't think it prevents it much. I'm thinking a bit about NVIDIA here, since I find their approach interesting: a partially open-sourced kernel driver, which interfaces with a binary-only userspace driver. Maybe that could work for the AnonymousIntern's company's products?
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
Is it truly necessary to release open sourced drivers? Or is it just necessary to release good drivers? Cant binary drivers be made compatible across Linux distros? If not, it seems like this is something that is truly necessary.
How different is *BSD from Linux as far as drivers go? Is it REALLY that hard to recompile drivers to make everyone happy?
Well, the best solution would obviously be open-sourcing the whole thing - but if they won't do it, why not do both simultaneously?
Put a limited open-sourced driver up so everyone can use it and it can be included in distributions (and developed from there, chances are it will outdo the closed-source version some day), and at the same time, release a closed-source driver for download so people who need the extra functionality right now and don't insist on having everything in source form can use that.
This message is provided under the terms outlined at http://www.bero.org/terms.html
It gets me everytime. To allow your linux users the same level of functionality as their windows using counterparts, why do the drivers need to be open source ? Why can't you charge for provision of closed source drivers, providing functionality, documentation, support and an increasing level of product maturity with driver revisions ? Maybe I'm a profiteering capitalist, but I don't see why mine (nor many of my collegues) hard work should be provided for free to one choice of OS and not another.
This seems very familiar.
:)
I work at a company that supports open source software, and development of open source software.
We ran into a situation where we needed to have open source drivers, as opposed to the (available) closed source drivers.
(for those interested, try searching for 'philips webcam drivers' on linuxtoday or linuxnews or something)
Links to the stories can be found here.
Our action was, to get the binary-only drivers, disassemble (reverse-engineer) them, and rewrite them, as open source.
I think the best action in situations such as these, is to try to convince the manufacturer first. Often they don't want to give away specifications, or they don't get the advantages (selling more hardware because of there is support for it in free operating systems).
In cases such as those, the only way to get open source drivers is reverse-engineering protocols or binary-only drivers.
Reverse-engineering and rewriting the driver can be a lot of work, but hey - it's worth it
As for the legal implications, we were able to do it legally. In the netherlands (and i know there are other countries with similar laws) it is legal to reverse-engineer a piece of software, and to make the information you get from it public.
In our case, releasing a complete open source driver was not possible, so we had to make an information package (wich included a basic driver as a reference).
Other people are allowed to re-use this information, and make the real driver.
As far as i'm concerned, there is always a way out, and always a way to get an open source driver for a piece of hardware.
While on the topic, what's the likelihood that someone with enough intent could work out the technology by reverse engineering the closed source driver, anyway?
I'm not suggesting it would necessarily be feasible since it's not really my area. Can someone comment?
===