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.
If the open-source driver lacks support for hardware features that the closed-source driver supports, it will not get support for those features. Unless someone reverse-engineers those features in a way that is legal in all the places where the drivers would need to be distributed, which is usually a major effort that could have been avoided if the vendor saw the light.
And if the vendor didn't do a full source release in the first place, they may well sue the person who did the reverse engineering, even if he did everything legally. Basically, having to reverse engineer features is a huge PITA.
I don't know why you think this comment belongs in this story but it dosen't.. Anyway to answer you quesiton it wouldn't quite work. I've thought about doing that with Electric and Gas engines. There are tons of problems with it however. 1. your engines (just like tires) would wear down at different rates causing you to have to rotate your engines. 2. every engine isn't going to have exactlly the same power output as the other one, so you car might pull the to left or right. If you correct this by just holding the steering wheel straight your tires are going to wear down quickly and unevenly, just as having improperly balanced tires would do to your car. 3. Cooling would be a big problem, not to mention how you would get enough power to those 4 different engines. When you put 4 of somthing in a car it becomes 4 times more complicated. There are many other reasons why your idea wouldn't work but I won't name them all.
I've been using the binary-only OSS sound drivers for the last couple of years, and it's been a serious Pain in the Ass.
- you have to download and re-install the drivers every time you change kernel versions
- this means you can't upgrade a kernel (or upgrade, and lose sound for a while) until the binary-only release for your version is available
- you better have the same libc as the sound drivers, or Bad Things Happen
- if Opensound ever goes away, then no more driver support for me!*
I'd much rather have the source, and I'd rather that source become part of the official kernel distribution, where I can count on it being compatible with my system under all circumstances.
Or to put it another way, distributing binary-only drivers means you are now in the Linux tech support business, where your drivers must keep pace with kernel development. Release driver source, and it's likely that someone else will do the maintainence for you - at least as far as API changes etc. go.
*OK, bad example, there are now working proper source drivers for my soundcard in the kernel, so I do have an alternative these days. For increasingly obscure or convoluted tech though (video cards) reverse engineering open source drivers may not be as feasable. If the company providing binary-only drivers decides to stop doing so, you're pretty well screwed come kernel recompile time.
Want to learn about race cars? Read my Book
There are a number of reasons why Linus refuses to commit to a standard binary interface:
1) It commits the kernel to support something he doesn't believe the kernel should commit to, at least at this point. The kernel does provide a standard external user-space interface (at least in combination with libc). Kernel internals, however, are kernel internals, and he wants the freedom to be able to change kernel internals as needed to improve the kernel.
The kernel internal interface is not part of the POSIX definition, anyway, so there's no standard to worry about upholding.
2) Stability. Buggy user space code can crash an application, but it won't crash the system. Buggy code in the kernel -- driver or otherwise -- can crash, lock up, or corrupt the entire system. It can be very hard to trace down where the corruption comes from (I speak from moderate personal experience dealing with the kernel in various UNIX-type operating systems).
Encouraging a situation where people are at the mercy of third parties for their systems' stability is not something Linus (or anyone else) particularly cares to encourage.
Drivers don't have to be compiled into the kernel; modules work just fine for the purpose of runtime loading.
It's all well and good to talk about design, but it's impossible to know every contingency that will ever come up. It's also impossible to know a priori what will work well and what won't without real-world experience.
Try reading linux-kernel -- you might be surprised by how much stuff Linus rejects on the grounds of poor design. The kernel is definitely not hacked together, but it does have to evolve, and forcing it to maintain a fixed internal interface gets in the way of that. Maintaining a supported external interface, in combination with libc, seems to be the best compromise between stability and progress.
Oh, really? I would argue that it's the very pickiness of the Linux community that has gotten it as far as it has. There are also a lot of people who believe fervently that if Linux were to give up this "pickiness" it would mean losing the very thing -- guaranteed freedom -- that makes it so desirable in the first place.
Nobody's forbidden to release closed-source software for Linux. That doesn't mean that it particularly needs to be encouraged.
As far as that's concerned, it's quite interesting how the very same companies screaming about the need to protect "intellectual property" refuse to acknowledge that an individual may have any "intellectual property" rights to personal information about him or herself. If an individual were recognized to have copyright on the information existing about herself (such as objective personal information, purchasing and browsing habits, and so forth), there might be a slightly more intelligent discussion of the whole issue.
It's not that easy to separate a kernel version from the low-level user interface (libc, and some of the tools), for one. Also, suppose I need two pieces of hardware, and the supported kernel is different for both pieces?
Yes, these aren't fool-proof, but they might satisfy your average PHB whilst still keeping in the spirit of having as much of the tech Open Source as you can.
There is actually one further option, which would allow for a TOTALLY Open Source driver - write a meta-driver, which handles the raw communication but does NOT contain the h/w API. Then have an external "driver script" which programs the driver with the translations between the external API and the H/W API. Give any given script the option of being encrypted, and the translations for that section of the API would be visible only to the driver.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
That depends on who you talk too.
Some people like Open Source because it tends to reduce the bug level. Release a mostly bugless closed source driver and they will be happy.
Some people like Open Source because it provides an alternitate means of support when bugs are found (either they are programmers and will fix it themselves, or they will hire a consultant to do it). This might only be important to them if they think the compony will fold, or if they think the componies support level won't be good enough. Provide them with source code escrow, and a way to get the code NDAed if they think they found a "show stopper" bug that you don't think of as a priority.
Other people like Open Source because it give them freedom. It might be the freedom to port to another OS (say Plan9, or NetBSD on the PCI baised SPARCs). It might be the freedom to add new features (wow, with all this DSP stuff, I bet I can turn this card into side looking sonar....). Some of them might be happy enough with source under NDA, but many won't.
Others like it because it normally also means free programs. This is kinda a non-issue for drivers because they are almost allways free with the device.
Others like it for a combonation of the reasons listed above. You will need a combionation of approches.
There are still others where it is a end unto itself. They will not be satisfyable with non Open Source (RMS qualifyes here, ESR does not appear to).
Pretty diffrent. But if you don't need a lot you can minimise the pain. Here are a few things to look out for:
Diffrent VM system (important if you want to do zero copy DMA operations), NetBSDs provides some features Liunx's doesn't (as far as I know) like Page-Loanout. In fact the 4 BSDs (counting BSD/OS) all hae diffrent VMs (well OpenBSDs may be the same as the old NetBSD one...and I think some NetBSD platforms still use the old VM system, not sure if it assumes things that are hard to do on some MMUs, or if some of the less popular ports are just lagging).
BSD systems stull use mbufs. Some of them have fixed a long standing 4.4 external memory mbuf bug, others havn't. Some allow arbratary pullup's and splices in the middle of the buff, not just at the front (makes life a lot simpler for protocalls that need contigious headers larger then a single mbuf). Linux doesn't have the same set of functions. If you look at the KAME project I thik they have a set of functions that abstracts out what they need into another interface that sits on top of both.
NetBSD and FreeBSD have a similar but diffrent interface to talking to devices that might live in a number of places and have a number of endianesses. For example the same NCR SCSI part can be found on a x86 PCI card (little endian machine, PCI bus), a SPARC SBus (big endian SBus), a SPARC PCI bus (big endian, PCI bus), and so on. A single driver can support all three (I think the probe function has to know how to probe all the bus types though -- which isn't a big deal for the SBus and PCI bus, but is for other busses). OpenBSD may have the same interface as one of the others, lack it entirely, or be a bit diffrent again. I donno. BSD/OS doesn't appear to have one at the moment, but I expect that is one of the things they wanted from buying Walnut Creek/FreeBSD.
And porting to NetBSD, FreeBSD, OpenBSD, and BSD/OS on the Intel CPU alone isn't the end of the story. BSD/OS runs on SPARCs as well, can I have a driver there? NetBSD runs on the Alpha, on PCI Macs, and around 40 other machine types, some of which have PCI busses and could take your hardware. Can you compile me up a version for them?
And hitting all the BSDs on all the archatectures isn't enough. BSD/OS and FreeBSD are doing fine grained SMP. That can require locking in the device drivers. Will you be supporting that as it moves forward?
And hitting all the BSDs not and in the future isn't enough. What about Plan9? What about university research projects?
These things may all represent very small markets (NetBSD supports the pc532, there were fewer then 250 of them new, and assuming all the ones still running run NetBSD, it's still a tiny market -- and it'll only work there if your device is SCSI attatch, or ethernet). But Open Source would make all of those people happy.
Even if you just stick to the "larger market" systems, there are still at least three intresting BSD systems, and two or three non-Intel CPUs. Assuming your hardware product is something an ISP would want at least. Answer may be diffrent if only a video production house would want it, or only a hardcore gamer.
From a bisness standpoint you have to decide. Is getting support on more platforms, and free bugfixes worth the cost of making it simpler for competitors to reverse engnear my hardware, or take tricky driver bits for their own? Is the kind of hardware I have actually going to inspire lots of people to hack on the drivers for free for me, or is it just not a sexy device (or in a overcrowded segment, and not a standout)?
I happen to beleve that people are better at reverse engenring closed source systems then people think (look at DeCSS, or the number of cammeras that gphoto authors had to reverse engenar specs for to make work, or...), so just for the sake of keeping ahead in hardware is probbably not a big issue unless you are in a fairly slow evloving segment of the market (say LCD charactor gennerators, or slow low density network gear).
If you have some nifty stuff in your drivers that is relitavly independent of the device, well then you have a real trade off to make. How much is that chunk of code worth? Is it really relly valuable? Do you take pains to ensure your programmers won't go to a competier and write that code again having seen it once? Might the GPL be "strong enough" to guard it? (after all if your compitetor takes it from a GPLed program they either have to release all their secrets, and they probbably have some just as good as yours...or face the potential for a big lawsuit, with large damage claims....)
Maybe there is a good bisness case. Maybe there isn't.
Pet thery warning: One thing you should be careful of though, if there is a good bisness case, you want to be the first in your market segment. The first people to the table get more followers. More people willing to hack your code even when a cheaper better card comes along (so long as it isn't that much better or cheaper). And the longer you are "first" the better your lead is (more people with time invested in learing how the driver works).
FYI, as of last monthish softupdates were re-released with the BSD licence.
That I agree with. Even in more idealisticly pure BSD systems a GPLed kernel module would be Ok, as would GPLed userland bits. So as long as this device isn't a boot device (like a RAID controler) your Ok.
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).
"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."
:) but could they do GNOME, Enlightment, and all the various free software projects? No way.. not enough people.
:) Nothing worse than buying into say a SoundBlaster Live with "Linux Support" only to find out how incomplete that support is.
The answer is the *neither*... it will be "free software", not Open Source (still TM'd? heh). Seriously, read on until the end... you can't just open the code - or not - and expect to sit on your ass reaping the benefits forever.
I am not the pure GPL type - I bought Windows. I won't even claim to be pure Linux (unlike *some* people who recently editorialized comments about Quicktime videos and Linux. *Diablo* *cough* Ahem.)
It's pretty obvious tho that even if YOU do not care about Free Software vs. Open Source, you only have to wait around for someone else to code good free software, and then you'll use it. I appreciate what the FSF has done, but not everyone does. Fine, I guess, but when someone codes "the best software" and it's GPL'd, that's it and the competition is OVER; story at 11.
By the same token, I don't program, but I love the fact that so many UNIX users do, and I can benefit by running Linux. Microsoft and APple can do some neat things when inspired (well, Apple can anyways
Back to my point, there will come a day when software is more common and stuff to power your boards will be Free Software. Maybe that day is far enough away to recoup your investment and then some, but don't expect to make it last forever. Releasing the code with too many restrictions will just FUEL some GPL'd alternative (look at Qt/KDE v. GNOME, or the FreeVM v. VMware).
Like Apple, there's a day in the future you'll have to decide if you're mostly software or hardware. Predict that day, and you can pull off any licensing you want really.
Personally I get annoyed at hardware with substandard Linux support, and I curse their management as buffoons.
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.
Christopher A. Bohn
cb
Oooh! What does this button do!?
Free as in speech, not free as in beer.
Christopher A. Bohn
cb
Oooh! What does this button do!?
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
We are probably creating a new generation of hackers who will be able to look at object code and understand it. Perhaps source code and object code won't have such an absolute division then.
-fb Everything not expressly forbidden is now mandatory.
Then your problem is simple.
How much business will you lose if you release the tech?
How much business will you gain if you get the Linux market?
Which one is greater?
We would all love for you to open source the driver and release the specs for the board, but your company's decision needs to be based on the numbers. Answer the simple questions above, and the decision is made.
If tits were wings it'd be flying around.
I agree with the folks who say, "Why must everything be Open Source?"
Why not just release binary drivers as modules and specify which version of the Linux kernel is required? If people need your hardware, then they'd be delighted to run whatever version of Linux is required. (I'm talking about kernel versions, not distros.)
Just because you port something to Linux doesn't mean it has to be Open Source, or even free.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
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
As the saying goes, beggars can't be choosers. And unless you havn't noticed, Linux isn't exactly the main OS of choice, or even close to it. We can't be picky about our software. IMHO people got a large head about Linux when the IPOs started... check them out, they ain't doing so hot. If you have the power to release drivers to make Linux more powerful and more advantageous to the user, there is truly no choice to be made. The user does not care if a driver is open source unless the user just so happens to be a coder.
Now, I like open source a lot. If there is a way to release this technology AND make it open source, then do that. But just because it ISN'T open source is no reason not to release it. In fact, if Linux is ever going to be #1, we will need companies to speak out for it. I don't see Linus on the TV pushing Linux... do you? Maybe the reason your Red Hat stock isn't doing so well is becuase THEY DON'T ADVERTISE. If they do it is in publications in which everyone already knows what they are. If the only way to get companies to support Linux is to let them release some closed-source stuff, then the method justifies the means.
If you think you know what the hell is going on you're probably full of shit. -- Robert Anton Wilson
If you think you know what the hell is going on you're probably full of shit. -- Robert Anton Wilson
jdube is who
It would seem to me that the design of this hardware was made under the assumption that the driver would be closed source, and perhaps only for Windows. If I had some cool idea of a piece of hardware (like something that was faster, smarter and just better than the competition) I would put all that technology into the hardware (count the firmware that drives the onboard CPU as part of that hardware for this purpose) and let the driver be nothing more than the communication path between the abstract requests/responses the applications see, and the physical functions performed by the hardware and/or it's processor.
It's awfully easy for me to assume the driver is doing more than it should, much like the driver in the infamous winmodems that let US Robotics make the modem cheaper, eating up more of your CPU power to do stuff like compression. That was definitely the opposite of an accelerated card.
Maybe the design cycle for the next version of the hardware needs to be pushed up sooner, and this time with all the proprietary and trade secret functions hidden away in a tamper-proof chip, and a simpler hardware-to-software interface.
now we need to go OSS in diesel cars
Open Source has far more advantages than just the ability to make Linux a functional OS. As a system administrator who knows how to program, it's a means by which I can have control over, and effectively manage, the systems I need to keep up and running.
One of the assertions made by Bill Gates regarding the stability of Windows is that many of the faults (I think he was trying to suggest that it was all of the faults) for crashes lie with third party drivers (many even distributed with Windows itself). With the increasing popularity of Linux, the concept of drivers written by third parties will be seen more and more. Some will be open source and some will not be. But what I suspect is likely to happen is that a lot of it will be poorly written. Those which are open source can be reviewed and fixed, maybe by the user, and maybe by the kernel development crew. It might even get included in the standard kernels (you can be sure a binary-only driver will not be).
One of the things that I believe open source brings is quality.
now we need to go OSS in diesel cars
Certainly a strong point.
:-)
I am tempted to suggest thet an answer would be to release two versions - a closed driver with all the proprietary bells and whistles and an open version that gives the functionality the company feels they can release. However, this then leads to an even deeper segregation problem!
The one positive effect that such a strategy *may* have however, is that if the company has a positive experience with the open version of the driver, it may encourage them to open more code in the future.
Hmm, it's a thorny problem though - and one which we have all been banging our heads against since way back
"Give the anarchist a cigarette"
A little planning goes a long way...
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...
In this case, releasing the source to the driver would not do the company any harm that wasn't already in the works.
Exactly! Someone give StormReaver a beverage of his or her choice.
If your company is depending solely on the fact that their software is only distributed as object code to ensure their continued livelihood, then I recommend that you start looking for employment elsewhere. Because in short order, someone is going to disassemble the object code and use it to ruin you.
In the end, both source and object code are exactly the same thing: Instructions to the computer. The form they take makes things slightly more difficult, but no more so then keeping all your trade secrets in French does.
Likewise, if you're depending on IP law to protect you (copyrights, patents, trademarks, etc.), they will continue to do so even if you do release the source.
Closed source as security is security through obscurity, which doesn't work, regardless if you are protecting data files on your server or the source itself.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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.
Of course, that can be fixed by rationing food. An approach which worked so well in WWII. That's the problem with socialism. It is not very realistic. Instead of people buying as they can, it relies on a Big Brother to parcel out the goods. Of course, Big Brother (or Uncle Joe...) likes to have as much as he can for himself.
People work on incentive; it's the only way. Free Software and Open Source (which are one and the same, no matter what His Highness thinks) only work because people have an incentive to write excellent software; they wish to scratch their itch. Take that away, and we have no more free software.
Very few people have an internal desire to clean toilets or plow fields. That sort of work scratches precious few itches (although it does cause a few). Yet, these things need doing. Thus the free market. It arranges for a fully-functioning society, unlike any other scheme yet proposed.
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.
Say you want to use the card on something other than windows, maybe in the future when the original card maker has gone bust.
Having the source code means you could rebuild the driver for say a PowerPC machine. If you don't you rely on the card maker to provide proper drivers for all platforms which usually isn't possible.
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.)
Actually, closed source drivers are usually given away for free (as in beer). I have downloaded several drivers off the net for free (not for linux though). The problem is that the companies are afraid that the code will act like the blue-prints to their products that their competetors can look at. This may or may not be the case.
It is possible to have a binary driver to work with linux, but it becomes a pain since you can't compile it when you build your kernel. And there may be problems with the driver with upgrades to the kernel.
Although I would be interested in knowing how much changes from one version of the kernel to the next regarding driver interfaces. Is it really that big of a deal. I have successfully used older versions of modules with new versions of the kernel. I just turn off that switch that checks for module kernel versions.
Steven Rostedt
Steven Rostedt
-- Nevermind
The Company has a product that we really want to open up. Unfortunately, there are parts of the technology that we don't own and can't disclose in source. The compromise that we're trying to reach is to have the low-level stuff that contains black magic released as binary-only libraries (very much independent of the operating system, much less the release level) and open up the higher levels of the drivers.
This has been in the suits vs. suits stage for over a year now. The lawyers are running the show.
Lacking <sarcasm> tags,
-------
CAIMLAS
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
The other advantage is that the free software community will most likely improve it as well and the company itself will benefit as well.
I also have another suggestion. If you want to keep an edge on tech over the competition, then move more of the low-level logic stuff needed for the drivers into the hardware itself (e.g., ROM) and then the free-source drivers only need to send params into the hardware via some sort of documented interface. This makes porting and supporting various platforms a bit easier through a higher layer of abstraction and makes it more difficult for a competitor to reverse engineer anyway.
This also would seem to get the difficult blessing of the FSF as long as it isn't flash upgradable. I heard a talk by Richard Stahlman Sunday at H2K in NYC and asked him about PC BIOSes. Seems he thinks BIOSes should be free since they are programmable, but not needed if they are not flashable. Spliting hairs a bit on that one, but I don't see him advocating that Intel release the microcode for their processors, for example.
Now this last bit I tend to disagree with since a non-upgradable card BIOS means any bugs in it need a hardware swap, but it's better than non-free drivers.
Some say free-source purists are anal but think of it. You spend your bucks on some top-of-the-line vid card yet you can't use it on the OS of your choice, or your support is limited. So why is a non-free driver acceptable to many Linux people when the "driver" for the processor (the OS itself) *must* be free (as in freedom) or it's evil (like NT)?
If consumers of free software want better support for hardware, they need to speak with their wallets and purchase hardware with free-source drivers, even if it may be a notch or two below the top-of-the-line. Since companies have an obligation to make money, only then will they notice and feel pressure to release the source to their stuff.
A complete OS is far more than just the kernel. Linux is free and the tools and utilities that make it work are free. If Microsoft released a new OS based on the Linux kernel but everything on top of it was non-free, would that be fine with you? If it's OK for Office Suites to be closed-source, then why the heck does the command "cat" also have to be free then?
"Purchase the Microsoft distribution of Linux. We've removed all of those unreliable GPLed utilities in it, stripped the C compiler and X out, and added typical Microsoft-quality tools on top of it along with mesh (Microsoft-enhanced shell), which DOS users will find very familiar. By the way, if you give a copy of anything but the kernel to a friend, you will go to jail. Of course, in the spirit of the open source community, our modifications to the linux kernel are available, just don't expect anything else to be."
I don't see how it is the hardware vendor's responsibility to support the OS vendor's political agenda. Now, before the knee-jerk reactions start rolling in: I agree that open drivers are preferable to closed drivers. And I agree with all of your bullets about why open drivers are better (or, in some cases, the only acceptable solution for us).
But we must remember that we don't make up a significant percentage of their total sales. Because of this, all of our ranting just causes the hardware vendor to conclude that supporting us is not worth it. Who wants to be in the unhappy position of receiving support calls from these zealots? (Especially if the problem is probably the driver, which they now aren't responsible for!)
They don't understand the philosophy. And us screaming in their face every time they make a move we don't like isn't going to make them understand. And it's not going to engender any good will toward us. It probably discourages thier cooperation, as they don't have any financial reason to succumb to the wishes of a bunch of ranting lunatics.
Instead, we should encourage baby steps toward our way of thinking. That is, applaud when they do what we like, and politely deal with it when they don't. Write even-tempered letters to the vendors involved describing your decision to buy or not buy their hardware and how the relative openness of their drivers played a part in that decision. Eventually, more vendors will see the benefit of giving us what we want, and the free market will take care of itself.
I'm not sure where we, as a community, decided that we have the right to demand open drivers and expect them to jump to it. How would we react if some hardware vendor demanded that the open source community provide them with drivers?
[Since I'm replying to bero, I have to say that I think companies like Red Hat are supremely positioned to show these vendors the enlightened way and assure them that the risk they associate with opening their drivers is worth the potential benefit.]
--
"I have a good idea why it's hard to verify programs. They're usually wrong." --Manuel Blum, FOCS 94
You may not be able to do that depending on the licence you use.
For example the GNU GPL states:
"The source code for a work means the preferred form of the work for making modifications to it"
In other words, not obfuscated.
(and a good thing too IMHO)
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Here's an example situation.
Let's imagine a new version of XFree86 comes out, promising to be the best thing since sliced bread. Lets imagine that lots of hardware manufacturers produce closed source drivers that work well and that most users are happy.
Now lets imagine that some people decide that the graphical performance of the systems they have is not good enough and they want to do something about it. Perhaps they decide it's XFree86 that is just too big and bloated and they want to write some new windowing system.
They write the fantastic new system with it's almost instant loading time, its superb anti-aliased fonts and so on, but theres a problem. It can only support VESA cards. Unaccelerated. What do they do? They want to look at the source for the XFree86 drivers but they can't. As a result the brilliant new system's performance is even worse than XFree86 on fast hardware. As a result, everyone keeps on using XFree86.
We would all effectively be stuck with XFree86 for ever, like it or not.
Linux+XFree86 is slower than Win32+directx they all say, and there's nothing we can do about it.
Okay, that's probably all a bit far fetched, but I don't care. You get my point.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
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 ?
Simple. Nobody would pay for drivers. Think about it: I buy a new video card, it works great, I install a new sound card, and the video card's drivers keep crashing. There's no WAY I'd shell out a bunch of cash to my video card vendor to fix their software.
Sure, most other software can follow this model. Software breaks, company releases another major/semi-minor version with a couple extra features, and people shell out thousands to get the latest. But that doesn't work for drivers. People won't buy drivers.
Apparently, many people would prefer good closed/proprietary drivers over mediocre free ones. What they don't appear to realize is that this leaves us stuck in square one.
/binary compatibility/. You can't easily make the switch to PPC or the Alpha, not just because they're more expensive (guess why), but also because they don't support your funky nVidia GeForce2, and probably never will.
The reason most of the people who're using Linux today are using it is that it does certain things better than their old OS did. Now, what happens when there's a new OS that's even better for their kind of work? Think about BSD, or the Hurd, they're even free software. Maybe you can construct a compatibility layer to run those drivers, but compatibility layers are evil.
Even worse, consider switching to a different hardware platform. No one's disputing that ia32 is the worst major hardware platform currently available, and the only reason everybody's using it is
Of course, hardware support on these platforms is pretty poor even among free software drivers (has anybody had success with utah-glx for mga on the Alpha? Keeps killing my X server), but there's at least a chance that something will happen: You can either fix it yourself, or pay someone to do it for you; you're no longer at the mercy of some high-ups in some company on a continent on the other side of the planet.
And that's what free software is about: Independence. Don't let yourself be fooled by bread and games!
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.
The main reasons for open source drivers are in my opinion:
- short response times for new kernel developments etc. (the next kernel version/xf86-version (whatever the driver is for) could break the driver but that might be easily fixed with an open source driver.)
- support from the open source community will make the drivers better and even help to develop better windows counterparts etc.
- proper linux support lasts much longer, once it's running most changes are automatically (more reflecting changes in the kernel than enhancements of the drivers) and comes for free
The drawbacks are:
- 'secrets' are slightly more obscured in binary versions (but if a competitor REALLY wants to know how that driver works he'll take it apart with a disassembler anyway)
- there's anyway people working on the drivers, so open-source won't make it cheaper (but maybe better)
In that light it may make sense to keep a driver closed for some time (maybe half a year or so, true 'secrets' will either be copied or reproduced by competitors, be the driver binary or not), but in the long term opening the driver makes more sense (new driver revisions for linux come automatically, and maybe there's even some concepts to be learned for the next generation hardware and it's drivers.)
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
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?
Don't expect the HURD to go anywhere. Who needs it? Linux works better now than the HURD will ever work. The MACH kernel is a fundamentally flawed thing, in concept alone. It's a great example of why we have the term "ivory towers" - it's designed by academics based on theory rather than experience and fact. It's advantage, in theory, is that it's more portable. In practice, Linux proves that a properly written monolithic kernel can be so close to it in portability as to make that a non-issue, without incurring the huge performance hit that the MACH kernel imposes by insisting on a lot of unecessary abstraction.
Given these facts, which you can easily verify for yourself, (start with this bit by Torvalds explaining the difference between microkernel and monolithic architecture from a practical point of view, and how the design of Linux enables it to meet the same goals without sacrificing performance) it's easy to see why the vast majority of competent kernel hackers are working on Linux or *BSD, not MACH, and will continue to do so for the forseeable future. The longer they do this the further behind the HURD gets and the less likely it becomes that it will ever become anything usable, let alone desirable. If by some miracle the HURD project suddenly starts moving and puts out a usable product, it still won't go anywhere, because it will still be inferior to Linux and *BSD performance wise, and Linux and *BSD are both portable enough that no one would choose the HURD just for portability.
In short, the HURD is dead, for good reason, so your entire post is irrelevant.
But, even without the HURD, there are still no shortage of good systems that people use and develop that won't work with a binary only driver.
That's nowhere near a comprehensive list I am sure, but just a few major ones off the top of my head.
When M$ claims that much of their stability problems come from poor 3rd party drivers, for once they are telling the truth. Unlike windows, linux was not designed to support binary only drivers, and it's not maintained in such a way to support them, by design and for good cause. The whole point to linux for most people is to get away from the bad things that come with windows, and binary only drivers are right up in the top part of that list. If a company won't release the source for their drivers, or at least the technical specs so that someone else can write a driver for it, I won't buy their hardware. Far better for them to release the specs and let a kernel hacker write the driver (which costs them nothing) than for them to pay a team of their programmers to produce, test, and release the best binary only driver in the world. Releasing a binary only driver isn't supporting linux, it's proving that you don't have a clue about Linux or Free Software in general.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
If someone really wants to, extracting the operational characteristics of the Windows version of the driver is a simple, if lengthy process (but could no doubt be automated on a PC emulator - if they can do DNA a little driver must be easy :-)) All the company has is yet another instance of "security by obscurity"
We will not ship anything in the main distribution if we can't ship the source. If they did that, they'd end up with their driver being available for download on redhat.com and its possible inclusion on the Linux Applications CD.
(And offering something for download is something they can do themselves).
This message is provided under the terms outlined at http://www.bero.org/terms.html
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.
Once again, some moderator has taken a response that they disagree with, and marked it down for being a "troll". How is it a troll? This person simply is stating his opinion.
This is something which has always bugged me about the moderation system here. People can't post contrarian opinions without being moderated into oblivion. Obviously moderation is needed to keep out the "first post"s and "natalie hot grits", but don't use it to silence opposing views.
- In Capitalist America, law violates YOU!
I agree, Open source stuff *is* about freedom but only for certain people. Those gifted as coders are free to look and alter the code but for others such as myself it matters little whether we get the source code or not. My talents, such as they are, do not lie in programming. I am a sys admin/support person and what I need from Linux is a system that allows my users to get on with their jobs, easily, securely and if possible boosts their work experience. Personally the easier and more accesible Linux is the better. I accept the free software ethos, but for me working, closed source drivers etc. are just plain more useful.
I don't know how long your company spent developing the new technology, and integrating it into their boards, but I am pretty certain that other manufacturers will spend as much time copying and applying your technology as they would developing the thing for themselves.
One compromise would be to develop fully featured binary drivers for say, Red Hat, and FreeBSD, plus low-funtionality driver code for other platforms.
Include in the package an email address where people can ask for a binary for a particular platform. If there's enough support for it, then bring it out. There shouldn't be that much modification required, and the kudos you'll earn with the opensource community may be more valuable than you think.
Even that's not enough though. I won't order any hardware that I don't see in the supported drivers list. So the faster you get some form of drivers out there, the better your board will sell.
"A goldfish was his muse, eternally amused"
Vs lbh pna ernq guvf, ybt bss abj. Tb bhgfvqr. Syl n xvgr.
It is _not_ illegal to reverse-engineer anything in the netherlands, as long as you only release information about the reverse-engineered product.
(Our lawyer checked this extensively)
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.
Try looking at some IOCCC contest winners. They make those parts of GCC look like "Hello World."
<O
( \
Will I retire or break 10K?
Unfortunately, you do not have many choices. Unless you can afford loosing your job, all you can do is do as told.
I have been through this kind of situation before and I know how frustrating it is to work in something you don't believe. All I can tell you is start looking for another job.
... you wouldn't need to provide your own drivers.
This parallels what's happening at NVidia at the moment - they've decided to release their own closed source binary set of drivers which require a dirty great 500k kernel module to be installed.
However, if they opened the register-level specs to the device, then there are enough other people out there who will take the specs and produce a set of open source drivers themselves. Witness the Utah-GLX project.
You could just release the register level specs to the device and if someone wants drivers for the thing, they'll hack em themselves. This is something I'd like to see NVidia do.
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?
===
(End of summary, you should now go there...)
Slashdotter's version: What are your executives afraid of?
Officially, that somebody would copy their technology if they put some code in the GPL?
If this is *that* revolutionary, then they could easily check that nobody copies them by scaning the concurrents' drivers.
Remember when Quake source code was stolen from crackdotcom's server, Carmack just said that nobody could use it for a new product, as there'd be no problem to have a lawyer demonstrating this copyright infringment.
IMHO, they might just fear that someone just points out that, despite the marketing guys' buzzwords, they just released a bunch of (ISO9k'ed, of course) crap, in which case it'd be better not to release any source code.
You only take one risk if you release something: Some hacker might just make it *far* better, which is gonna sell a lot of pieces of hardware.
--
Trolling using another account since 2005.