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.
What license would you release something like that under? Would /. start referring to similar licensing terms as "free as in ass"?
Hmm...
AC
Ya'll observe the same Berne copyright convention that we do. Whether you legally disassembled the code or legally found the source in someone's garbage, it is still illegal to "copy" it. You can learn from it, get interface info, etc., but it still carries all the copyright protections as the original source code. Even the translation to machine code and back is no defense. Besides, there's the ethics of it all. Shame on you.
Okay, it's time this NVidia thing was more fully explained. In fact, I daresay the NVidia situation would make an excellent Slashdot feature, assuming we could get anyone at NVidia to go on record. I, sadly, must remain off-record, since we're trying to get this very information out of NVidia so we can support their chips, and I wouldn't want to upset them. However, I also think a more complete picture of the situation -- at least, as I have come to understand it -- may help Slashdotters and Open Source advocates understand the situation more fully and allow youse guys to direct your intellect and zeal in a more constructive manner.
First of all, the Big Book Of NVidia Register Definitions won't tell you a thing. NVidia's design philosophy is very unlike any other graphics chip. Everything, including rendering context maintenance, is dealt with at the hardware level. In reality, a lot of duties get thunked off to software via interrupts, but by taking this approach, NVidia can migrate functionality into and out of the hardware at will, and all client software will continue to work (that's the theory, anyway). Thus, to write an effective driver, you need considerably more information than a register list since, in actual fact, half the time you aren't dealing with real registers.
I have it on reliable authority that this information isn't really written down anywhere; unlike Intel, NVidia does not have a technical documentation division. The design philosophy remains primarily in the engineers' brains. If you want to become a customer of NVidia (that is, a board OEM), they'll give you enough access to their brains so that you can customize your board offering. In terms of NVidia's engineering time, this is not cheap, which is why they charge OEMs handsomely for this privilege.
So, without access to NVidia engineers, the register spec is of little aid to a driver-writing effort. Fuhgeddabouddit. The lowest level they're willing to document at all is the virtualized hardware interface and, as it happens, all that information can be found here.
Another reason NVidia is so protective of their specs is partially due do historical accident. Several of the principals at NVidia used to work at Sun Microsystems, where they developed the GX graphics accelerator. One of the SunOS releases inadvertently contained a single #include file detailing the GX registers. Using that file, a debugger, and a logic analyzer, Weitek managed to develop a clone of this chip in a mere six months. The clone was so good that Sun's own drivers worked on it. Needless to say, this left a bad taste in their mouth.
Astute observers will note that Weitek is now dead dead dead , but NVidia has more recent experiences to keep them gun-shy (Gnu-shy? :-) ). It seems that NVidia is of the opinion that the few Open Source releases they've made have directly resulted in getting hit with patent infringement suits. Apparently their competitors (who evidently have nothing better to do :-) ) download their source release, pick through the code, make some reasonable conclusions about the underlying hardware implementation, and start filing suits. Yes, it's bullshit, but if you're a cost-based accounting kinda guy (and most accountants are these days), NVidia's Open Source releases have been hideously expensive, and haven't resulted in the sales of additional chips.
These two last points (fear of cloning and fear of lawsuits) are the two big sticking points for NVidia at the moment and, sadly, I don't see them changing any time soon. Personally, I think their chip is so monsterously complex to design and fabricate that their fear of cloning is virtually unfounded. The patent thing, however, is another matter. Perhaps they might choose to hook up with Jeff Bezos in his stated intention to pursue patent reform. But that seems unlikely, since it could distract them from the very important job of staying ahead of 3Dfx, S3, ATI, and Matrox.
Keep sending them kind, polite notes of encouragement toward an Open Source release. But be prepared for a long, long wait.
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.
Did you notice how a red Windows Evangalist will never drink pure water? Vodka. They drink vodka.
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.
You know, I suggested something along those lines once. Only it was more of an elite omega force type thing.
F0 07 C7 C8
Fully working drivers? No such thing :)
F0 07 C7 C8
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.
Can you post a message and ask for free help? Can you write a check? Both are possible ways to get fixes if you have the source. Remember that with free software, you have a significant number of people whose motivation is more in getting things working right than in profit.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
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
Because I'm a prospective customer? Damn right! They don't have to open their source, I don't have to buy their product! What's more, I'm just as free to discourage other people from buying it, too.
A free market cuts both ways, my friend.
They do indeed. However, that doesn't mean that that behavior should be encouraged. If a company realizes that releasing a driver without source loses sales to their competitors, they may be encouraged to open their source code. Such an outcome would be highly desirable.
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?
another con....
the product is computer authorisation algorith (eg ACE-server & Securid card). Opening up the source exposes the driving algorithm for public (read cracker/hacker) viewing. IF there is hole in the algo and someone finds it the company is screwed.
The point here is that the algorithm _must_ be secure. Its how the 'one time pad' works.
opening up the aglorithm destroys its main strength - obscurity. (ok as we know this is generally a bad idea, but lots of people still make lots of money out of 'snake oil':-)
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)
If the kernel interfaces change (which they do from time to time) Linus has already implied that they (the kernel team) are not going to shed a single tear for those vendors that produce binary only drivers. The official take is that while they're not excluded, they are unsupported by the development community.
Either the company in question is going to be willing to pony up the resources to keep up with the kernel development (an ambitious task- but NVidia seems to be willing at this point in time...) or open the source and the technical details to be able to fix the same. While they're making that decision, they should understand that unless there's some magic mojo involved in their tech, they're not going to benefit at all from opening the source and tech data. They should also realize that if they have some special magic that it's VERY likely that a potential competitor would be reverse engineering the stuff and unless the company in question has patents on the software and hardware, there's going to be clones and knock-offs eventually (rather soon, I'd suspect...). Plainly speaking, security of "IP" through obscurity is no security at all. It's almost totally in their best interests to open it all up.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Arrgh... I botched that.
/. before consuming mass quantities of caffene!! :-)
They will benefit from an opening of the info and driver source.
(Shouldn't post to
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Poor sampling techniques get poor consistancy. It is very possable that the people tht say "don't steal code" are not the same people tht say "steal music". (of corse it is possable that people are inconsistant)
Slashdot does not speak with one voice. Not even the same parts of slashdot read the same stories!
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).
On lkml I once read a thread started by some one distributing a binary-only kernel module. The binary guy was experiencing some problems and some kernel hackers were assisting him in tracking down the source of the problem. What kernel version? UP or SMP? What compiler?
So, binary-only modules are pretty much guaranteed to be big hassle right now. Bigger than some people trying to distribute them realised in advance.
--
Fuck the system? Nah, you might catch something.
"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!?
Dr. StrangeLinux?
--
Program Intellivision!
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.
A GPL'd driver may not be able to be used in a *BSD system, but a BSD licenced driver can be used in Linux or as part of a GPL'd system. Though, from a hardware manufacturer's perspective I suspect that BSD licencing would be even less acceptable than GPL as it would allow someone else to make the driver proprietary.
Speaking of moronic logic ... you have your logical implications back to front. Since many cats drink milk, anyone who drinks milk is a cat ...
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.
This has *nothing* to do with monolithic kernels. It has to do with having a stable interface, something that can and should exist just fine without a microkernel.
---
Joseph Foley
Akamai Technologies
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.
Well, 3D Cards are one thing, SCSI adapters are another.
Linux is supposedly being installed on more servers than Novell NetWare. If you manufactured something targeted at the server market, you'd be a fool to ignore Linux (and you'd be an even bigger fool to not play by the rules and try to support a binary driver...) This is the kind of hardware that comes with support for obscure platforms like OS/2 ODI networking and Novell NetWare 3.x - Linux should be a no-brainer.
Intel proposed a cross-Unix driver API (and presumably will implement it for Linux). The conculsion of the Linux cabal was that any driver using it would be doggy dog slow.
--
Business. Numbers. Money. People. Computer World.
The situation is more different than you would think. Linus (and many other kernel hackers) thinks that there is no need for supporting binary-only drivers and thus make no effort of keeping the driver interface stable over time.
Many binary-only drivers even violate the GPL by using the inline functions from the (GPLed) kernel header files. I think Linus gave only one explicit exception from this rule to some company (etinc, I think).
IMHO it is hard (if not impossible) to write (and especially maintain) the Linux driver not covered by GPL. You basically end up duplicating the changes in the kernel develoment yourself.
Speaking from the point of view of kernel driver author/maintainer it is the best thing for maintainance to have your driver included in the mainstream kernel tree. Core kernel hackers often modify drivers in the kernel tree to reflect changes of the driver interface, so you don't have to track closely the kernel development.
-Yenya
-Yenya
--
-Yenya
--
While Linux is larger than Emacs, at least Linux has the excuse that it has to be. --Linus
>> How about a new GPL but for drivers. I could state that, yea, you can change the code, yea, you have the code, but no, you are not allowed to make hardware products from this code, but anything else could be allowed.
Would go against RMS' sense of fair use, i.e. doing whatever you want to do with the source, including competing against the creator of the software.
Je ne parle pas francais.
so there's no chance i will ever spend any money to put an nvidia card in any of my computers.
shrug. i mean, really, does anyone who USES linux REALLY give a damn?
--
blue
you need this
i browse at -1 because they're funnier than you are.
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
Don't be such hard asses on the guy. It was a suggestion and you may have taken it incorrectly. How many more cliche browbeatings are you people going to subject this guy (Harold) to? Question: Why can't this company patent their secret technology and then open source the code? Ok, now flame me...
-dbw
vapour I believe you have landed on the wrong web site, you must have taken a left at Amazon.com instead of a right, because I think you were looking for Micro$oft.com where the idea of open source is simply too bizarre to imagine!
-dbw
It would just be a matter of time and having a skilled engineer to do it. A competitor which designs similar products would of course have plenty of capable engineers.
The sad truth is I doubt they are really doing anything that is unique and if they are, their competitors already know about it. Security through obscurity is no security at all.
Yeah, but the driver issue was that he couldn't get one that would do what he wanted. Hardware manufacturers make their money off of the hardware, and give away the software (drivers) so that you will find the hardware worth buying.
... This is quite difficult with the closed source drivers. And it can never become a part of the standard. This may not matter to them. It will matter to some fraction of the Linux users, who will decide that this driver doesn't suit their needs. It won't matter to another fraction.
The problem with a closed source driver (assuming that the interfaces are properly documented) is that it won't work on all Linux systems, but only, say, on the i486 systems. With an open driver the Alpha users could recompile an tweak it to run with an Alpha, the Mac users could
Now I don't know what a hardware manufacturer thinks he would be giving away by revealing the driver source. But I don't need to know. That's his decision. I may decide to buy it or not. That's my decision. They can count on a closed source driver being greeted by raucous cat-calls, but so what. That will let folk know that the driver exists, and since freshmeat won't carry it, they need some way to let folk know.
I think we've pushed this "anyone can grow up to be president" thing too far.
A couple of thoughts here.
- First, the company isn't protecting their technology by limiting it to closed-source Windows drivers only. Their competition has engineers and labs and money, and can and will reverse-engineer the Windows drives. It'll take them a few weeks longer and force them to add a couple-three dollars to the price of their product to preserve their profits, but that's about it.
- Binary-only drivers turn into a headache when new kernels come out, or people compile their own kernels to their own preferences. Source for kernel modules can be recompiled to match the kernel by whoever recompiled the kernel. Binary modules can only be done by the company releasing them. Does the company really want to take on the job of tracking every single kernel release out there?
- If Linux and other open-source OSes take off in more wide-spread use, companies that have Linux drivers lagging behind the Windows ones in capabilities risk getting left behind on both fronts. If the apps using your cards need, because of creator decisions, to run on both Windows and Linux, they will avoid using things available only under Windows. If your competition starts opening up, those apps will be able to use the more advanced stuff and will work better, and people will start to shift towards them even when they only run Windows ( because all of their friends who run mixed systems use the competition's stuff ).
Sometimes I think we're getting to a point where protecting your rights in something and making a profit from it are starting to be incompatible. Much like printed books: the only way to completely stop people from copying them is to not publish them, but you've got to publish if you want to make any money selling your books.If it's the part in the hardware that's hard to reverse-engineer, wouldn't it remain just as hard if the driver source were available? If so, keeping the driver source closed doesn't protect anything. Having it might enable the competition to write drivers for that hardware, but they still can't make a replacement for the hardware so people will still have to go to the original company for it. No loss to the original company there.
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
(Now, watch this get moderated down as a troll, even though it's totally factual.)
Yeah, real factual. And so objective.
I'm curious: where did you read that the drivers should be GPL'ed? It said they should be Open Sourced. Quite a difference!
And this brings me to a mini-rant: why do BSD-people (not all, ofcourse) try to kick Linux and/or the GPL so much? It seems like you're required to dislike Linux when you run *BSD. Linux and *BSD are totally different. Use what you like, but please don't whine about the others, is that so difficult?!
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
Anybody interested in putting together such a project?
Jumpstart the tartan drive.
A closed driver ties you to a particular kernel version on a particular platform. When a company releases a binary only driver, you'll be lucky if they even bother to build an SMP version of the driver, nevermind one for Alpha or PPC. And if you cant use the kernel version that they release for? Well, too bad... And forget about development kernels.
If the driver is for a data acquisition board which may be used to digitize data of experiments which cost tens of thousands of $$$ then it would be helpful if provision be made to release the source to selected users (e.g. with NDA). Open Sourcing is not compulsory but it should be considered as soon as the product becomes outdated.
In order to use Nvidia's lame xfree 4.xx bvinary server on my box at home (which can't boot 2.2 due to insane pci cards which require 2.3/4's newer PCI code), I'd have to use a nasty third party hack, to kludge the driver to work with my kernel. for me, it's not a choice.
We don't have a magic driver system
Of course, companies like smartdisk and creative labs go one step further, writing opensource drives.
I'm wondering if the unnamed company is indeed creative, because they have released perfectly good basic emu10k1 drivers to control their cards. however, they don't tap much of the DSP power of this beastie.
People who do this will probably still get more of the linux user dollar than either nvidia (see above), or people who don't offer support at all (hello, Event/Echo, you mongrels!
Speaking personally, I have a Geforce at home because I play games, but in my linux box at work, I have a G400, because of Matrox's willingness to document their product. I now have to consider linux whenever I buy any general-use hardware.
The K7VT motherboard which I bought yesterday (Asus Athlon/Thunderbird mobo) sports a neat little "tested with linux" flash. This is half the story. People must also follow through will full support in each case, word gets around...
Umm, end of ramble.. what was the point that I was trying to make?
As to the rest, if manufacturers took your suggestion as read, it would mean losing sales even more surely as if they produced a shonky card which relies on layers of software to take the strain.
I personally don't want to be restriced to "retired" hardware, and be grubbing around for old orphaned hardware like a poor relative of the BillyClicker world, there's no earthly reason for it. As free OSsen gain more of a foothold, manufacturers will realise that a it's an increasing market, and one that doesn't just scrape by on recycled kit, third rate outdated stuff.
That sort of approach would put me at a very real competetive disadvantage to my Clicker colleagues, since they might be lacking in clues, but their alien technology would always be several steps ahead
Like I want to stay using an sb16 with worse sound quality than a Psion PDA, while other people are using Wave8/24.. Like I want to be struggling along with lame-ass 3DFX crap to preview 3d scenes while other people are using a fully-supported GeForce 2 GTS... not fun, eh?
http://www.oreilly.com/catalog/cb/chapter/magic-ca uldron.html#magic-cauldron-17
Need I say more?
ESR mentions both Adaptec and Cyclades. As far as I know both of these companies do make money.
If you feel it is propaganda please prove it wrong. You only harm your own credibility by spreading FUD on ESR. Posting as AC does not quite help either.
So: If you really have a point to prove prove it. And do it non-anonymously.
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.
If somebody really wanted to reverse engineer or gain technical advantage from your drivers they could do so almost as easily from a binary. I dare say there isnt anything in there that competitors havent thought of anyway, I honestly havent seen anything truly innovative for years
Let me see if I understand this: You understand that Open Source is good, you want to attract Open Source people---but you don't want to open the source. Can't be done.
However, I suspect your REAL question is "How can we seem to jump on the Linux bandwagon to gain marketshare AND mindshare without taking any risk?" Answer: binary-only drivers!
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
"To allow your linux users the same level of functionality as their windows using counterparts, why do the drivers need to be open source ?"
They don't.
"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 ?"
You can.
"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."
It needn't.
But if you take this route, you won't have me as a customer. Why not? Because I don't use software that's not Free (also free, but that's not a goal, that a necessity). If I am not someone you want as a customer, then we're both fine. If I AM someone you want as a customer then you are in trouble.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
But then you want to start using hurd or beos or who knows some new incredible new OS that was just created. Surprize no drivers for your hardware. I guess you will have to waut untill your choice is also adopted by millions more to have a closed source driver.
I think it is an outrage to buy a piece of hardware and don't have access to the specs so you can create your own driver if you want.
My only question is what the hardware manufacturer would loose if they open the specs, I am not realy asking about drivers, I only asking for SPECS, I simply want to be able to have access to what I buy. Is that ask to much in this world???
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
[]'s Victor Bogado da Silva Lins
^[:wq
Or, continuing along this line, why not release the kernel part of the driver as open source, while another part (the actual hardware calls) as a closed source library?
----------------------------------------------
the pun is mightier than the sword
>A kernel driver can crash the entire system. If it's binary only, it can't be fixed by the community.
True. But then if a company is releasing the driver as an "offical" driver for it's hardware, it should already be stable and functional. If it isn't, then they have to fix it. This has been the case on Windows and other OS's for quiet some time. If the driver stinks, don't buy the hardware; you wouldn't use a peice of software that doesn't work, so why hardware?
In the end, theirs very little reason why a company can't just release binary drivers for a product, apart from the screaming zealots. Oh well.
That attitude is correct, but asking for trouble. A driver only has to be "good enough". If it causes occasional crashes, especially difficult to diagnose ones, most companies won't put forth too much effort to fix the problems. Factor in to that picture several companies using the same tactics & pretty soon, Linux crashes as often as windows. While I don't have a strong opinion on the question in general, this is a VERY significant issue. One of Linux's primary advantages is it's stability. maintaining that stability is absolutely paramount for it's continued growth.
That's what I'd like to know. It seems to me, that if your double-secret hardware is so great, your competitors are disassembling your windows drivers *now*. They've also got a lab full of your hardware product in various states of disassembly. So, just who are you hurting by acting like your drivers are Secrets of the Gods? Only us, your (potential) customers. Thanks a lot.
Binary drivers don't necessarily work with any version of the kernel except the one they were compiled with. Either the company would have to maintain a version of the driver for every kernel in use out there, or users would be locked into the kernel that supports that driver.
It's not some kind of Stallmanite dot-commie devotion to Free Software that makes open drivers a good thing, it's pure practicality.
Do you really think that your drivers are a lot better than your competitors? If you don't, then go ahead and release. Let your pride down for a while think realisticaly.
.o distributed. Like Nvidia does.
:-)
OTOH, if you do have better drivers, Then a half-open solution could work,
all the glue to kernel is Open Source, but actual magic happens in the binary
The third solution, since you sell software and hardware, is to release the source only to your
customers and EULA them so that you can sue them on a leak
signatures pending - ansa@kos.to - (dont mail there)
If you have problems beyond that, the producer should have some form of tech support or, better yet, a contact in their development area.
My office has been taken over by iPod people.
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.
no text
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.)
you make your money on the hardware right ? you give drivers away for free right ? so why not open source em ?
not entirely true. microkernels can scale better with multiple procs than monolithic designs..which is why linux/BSDs are having so many SMP problems. ..and one more reason why NT ..besides the fact its dog slow..beat linux on a quad box. exokernels are slightly worse in design but better in performance than microkernels giving improvements in IPC where microkernels bog down. i'd take a slightly slower microkernel over a monolithic any day since the design itself is cleaner...portability is a non issue as you mentioned.
umm..no. the NT kernel had a multithreaded TCP/IP stack and is a true microkernel derived from VAX/VMS. VMS+1 char = WNT.
microkernels are by definition cleaner - what would you rather choose - a 1,000,000 line BASIC program which is written well or a 1,000,000 line java/C++/smalltalk program written modular ? i'd go with the object oriented approach. granted that linux uses fairly modular code (hell, ive written a driver myself) and is easy to understand thanks to the cluefullness of the people writing it. yes the million line basic program in the above example will run faster than a corresponding java program (or any other OO) but the OO language approach results in a fairly clean design. monolithic kernels have ti be split on > 4 procs since the same code cannot be run with optimum efficiency. look at solaris - its dead slow on 4 CPUs. microkernels are just better at scaling up for >2 CPUs and are slightly slower on UP systems... one of the main disadvantages according to linus is the code for a microkernel is harder to write. thats one reason which has (so far) stopped much microkernel development in linux....other than mklinux which IS microkernel based but has not been developed properly.
Lose, not loose!!! [/spelling flame]
"It's tough to be bilingual when you get hit in the head."
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,
This issues seems to recur frequently, but it still leaves me confused. If it is proprietary hardware technology that these companies fear revealing, then why can't they secure patent protection?
When the patent is issued, then the technology ceases to be a secret. The intellectual property is now protected by legal power of the patents. So releasing an open-source driver should do little to alter the value of the IP to the inventor.
Perhaps they'd rather retain secrecy rather than have to enforce the patent. Not likely, as is there is so little extra secrecy. It's just that it's slightly easier for competitors to look at source than find the relevent patents. And perhaps the patent doesn't reveal or explain some details that driver source might.
Maybe its the uncertainty of the patent process. It takes several years to actually have the patent issued. If the patent application fails, then the cat is out of the bag with no return.
Software technology is obviously different. If hardware guys want to protect software IP, then I have no sympathy. That attitude places them squarely on the slippery slope to proprietary OS's, each aiming to differentiate mediocre hardware. We've been there, and it sucks royally for the consumer.
I have an idea as to who this company may be. And the "secret" to which he refers is far more complex than the MIDI card example. It is *possible* to reverse engineer it, but very *impracticle*. There is no consumer device that I can think of that has the complexity of this one "feature" of the companies boards. Even with the documentation for it, it is hard to get it working.
Reverse engineering it would not be easy. The secret has been available in the hardware for years, and I don't think any competition has done anything like it. It is a very complex ASIC on their boards.
I like the notion that they open source their driver without support for the secret, but with support for plugins. A binary plugin can be provided for the extra functionality, and all the comapny has to do is port that binary plugin to the different architectures (x86, PPC, etc.). It allows for people to get the driver up and running anywhere, and then the extra functionality comes at the pace the company can keep up with.
Its not an ideal situation, but this is not an ideal world.
Once the kernel has developed "enough", the driver interface (at least for certain types of drivers) will probably stabilize and become de facto standard or be blessed by Linus as standard.
But really this is beside the point. Kernel version 2.2 has been around now for what? 2 years? Version 2.4 .0preX is out, so that api is stable now and it will certainly be around for quite some time. There is no big deal to make a single source base compatible with both 2.2 and 2.4 (and 2.0 for that matter) and release them all as binary.
This sort of situation is similar but far better than the Windows version where each driver is nearly an entirely different code base since the driver interfaces are often completely different between Win9x and NT.
"Why should I be content to simply live in this world, when I, as a human being, can CREATE it?" - Oertel
-------
CAIMLAS
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
All right, this may be a naive, unrealistic idea that show my complete misuderstanding of Linux and lack of experience with the kernel but here goes:
Could a "virtual machine" a la Java be developed for Linux device drivers?
The binary driver's could be written for this virtual machine. The distribution would handle the specifics for that installation. Any company who did not want to open source their driver but did want to provide a driver could write to the virtual machine specs. This might not resolve all problems would would make supporting Linux much easier.
Eric Raymond's paper The Magic Cauldron talks about reasons for being open for stuff like this.
perl -e 'srand(-2091643526); print chr rand 90 for (0..4)'
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.
Maybe I'm crazy, but isn't that fact that the linux kernel is open one of the things that's helped to make it great? I'm not trying to be an open-source zealot here, I'm just saying there are practical (not merely idealogical) reasons why we as a community shouldn't except binary drivers
.Suppose you get a binary drivers for, say, a soundcard. They work great, no detectable errors at all. A while latter, you get a bianary driver for your Nic, it works great too. In a couple months, you have 5 or 6 of these binary drivers. Then things start to fuck up. You try going back and only having the drivers that worked well togeather, but things are still all messed up. So, what can you do? The hacker community is no help (okay, so they may have reverse engineered there own drivers, let's say they didn't, becsue if they did, those are open source drivers, which is outside this argument), becase they don't know anything about the internals of the drivers. So you call the driver vendors, and they blame one another. What do you do? Your stuck with either no drivers, or a linux box as stable as a win 95 PC (It might be tough for it to become that unstable, but bad hardware drivers were one of the most commong causes of those blue-screens of death... The linux kernel does work rather differently, admitedly.)
Well, any way, that's my reasoning. This is why I think you should seriouly consider not using bianary drives, even if they do work well. If companies see that the linux community is willing to except bianary-only drivers, they will more then willing to keep shipping them out. So, just don't except them. That way, if they want to sell to linux users, they'll have to have open source drivers.Dionysus vs, Socrates! The greatest battle of all time!
A GPVed driver can't be just ported to BSD, because doing so would GPV-infect the BSD kernel. That would contravene the goals of the BSD community, since a significant goal is to keep the BSD system truly free for all, including those who would base proprietary code on it.
(Now, watch this get moderated down as a troll, even though it's totally factual.)
--
Disinfect the GNU General Public Virus!
You posted anon because you were afraid of losing karma. Kind of sad.
Well, if posting messags that disagree with Slashdot orthodoxy didn't automatically destroy your karms through knee-jerk moderation by folks who refuse to think, perhaps it wouldn't be necessary.
--
Disinfect the GNU General Public Virus!
I would love to have a rational discussion with you or any of the many other critics of Free Software that for some perverse reason seem to want to take over a site predominately concerned with Free Software, but the moderation system as currently implemented means I can't do that, unless I want to go negative karma immediately, or else post anonymously as I am doing now for obvious reasons.
This paragraph is a perfect example of the problem I have. It's simple: Why do you think 1) that the FSF gets the exclusive right to define what free software is, and 2) that Slashdot is exclusively dedicated to what the FSF decrees? I contend that neither of those is valid. "News for Nerds" is NOT exclusively for Linux, or GNU, software. If this were the case, why would there be a BSD section? I do not want to "take over a site predominately concerned with Free Software" because I think that's a grossly inaccurate and unnecessarily limiting definition.
--
Disinfect the GNU General Public Virus!
[...]I suspect that BSD licencing would be even less acceptable than GPL as it would allow someone else to make the driver proprietary.
Wrong. The original code can never be made proprietary. Once released under a BSD license, the original code will always remain available.
--
Disinfect the GNU General Public Virus!
I run several Linux boxes, and only one BSD system (a DECstation that runs an IRC server as its only task). I maintain a software package that runs on Linux and not (at present) on BSD. In general, I prefer Linux from the standpoint of a user.
I don't dislike Linux. I do despise the GPV, and have argued against it for a decade. I do not agree that the two go hand in hand, or that Linux would not have reached its current state had it been BSD licensed. I especially object to the concept (as expressed elsewhere in this discussion) that only the FSF gets to define free software, and that only GPV-infected stuff qualifies. I believe that the GPV is significantly less free than the BSD license, and claiming otherwise is ignorant at best and dishonest at worst.
--
Disinfect the GNU General Public Virus!
Why is expressing my opinion in an honest and open manner a troll?
--
Disinfect the GNU General Public Virus!
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!
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.
In the future, our children will ask: Why was it once a crime to share, with your friends?
Dont mess with my e-mail adress
That is how Aureal did/does it. Their binary modules and associated open-source wrappers can be found here, Despite the fact that Aureal the company is defunct (Alas). I'm not sure if they will work with 2.4, however. I have not tried.
If I buy a video card I figure I'm entitled to use it any way I want, under any OS I want, instead of depending on the manufacturer's good will to make drivers. That means at least having access to the board's specs.
Being the troublemaker I am, I could actually do that if I lived in the US.
What about users of other, non-binary-compatible OSs? (I use two myself; and although I'm unlikely to want the drivers in question, the principle still stands.)
If Linux (and compatibles) ever become the unquestioned OS Of Choice, will any of us remember our principles, or will we too be trying to lock everyone else into our favourite system?
Ceterum censeo subscriptionem esse delendam.
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
Well, the problem so far has been the fact that we haven't been able to rely on closed source drivers. The target (ie. the kernel interfaces) is moving constantly, and while we are drooling for all the cool new features of Linux 2.4 we can't easily upgrade because most certainly the drivers would break if they were networking or disk drivers or other drivers relying on generally frequently modified kernel interfaces. Linus et al. have held the position that no kernel binary interface (ie. stable interface) will surface for the foreseeable future.
It's certainly possible to maintain closed source drivers but that would mean a commitment far greater than the current penguin courting business crowd is willing. It would mean that any prospective change in the kernel would need to be mirrored in a timely fashion by such a party. And then the higher commitment would bring more criticism of closed source mentality, a whole deal of stress to the company support personnel and engineers, and possibly a split in the user community between those conforming (pro-closed-source) and those reforming (pro-open-source).
Frankly, the Linux movement is mainly a social rebellion to the control of corporations, a way to interact in a similar vein to municipal (community) democracy. It's a reaction to the capitalization of services. The capital forms conglomerates of interest and power, and if the moral target is consumer/citizen choice, it's only a natural reaction that people criticize prosesses in which they are not able to take part.
In my opinion, conformity where it means suffering to those taking part in an activity, is weakness at its best. On the other hand, reforms are never to be expressed in violence against basic or expressly agreed-upon transient human rights.
So does that mean Linux's backward compatibility sucks? if all you did is upgrade to a new kernel and everything starts to fall down on you?
Something to think about I guess.
Also, can't linux kernel(distribution) programmers have some kind of industry standard that makes writing drivers and making them work wouldn't be the worst nightmare for a hardware company?
Just my 2 cents
I agree completely with this. I am aware of at least one major computer manufacturer that is using their clout to get Adaptec to open up their drivers for a RAID On Motherboard driver. I have a feeling this is going to be how things get done now. Take this following hypothetical. Company A sells machines with Company B's HW inside. Company B writes a driver, that will only be distributed as a binary (compatible with only a few kernels). Company A's customers demand the ability to tune their own OS (Linux for instance) and start telling Company A's sales staff that they will buy some other company's product if they don't open their drivers. Comapny A uses its leverage to get Company B to open their driver's under threat of finding a new (and more open source friendly) vendor. Volia, capitalism at work!!!
-- Dave
This post expresses my opinion, not that of my employer. And yes, IAAL.
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);}
By open sourcing the drivers, the potential size of the market for the hardware is increased.
This is because of Customer Good Will and porting efforts of individuals who use platforms for which the drivers are not currently available.
Management may need to be reminded about what the source of revenue is. If they are in the business of selling software, then maybe they should not open source their Golden Goose. However, if they are in the business of making and selling hardware, then maybe they should concentrate their efforts on those things that they do "well", and leave the software to those who want to do that.
If one looks at software costs, say 1 or 2 developers, plus various versions of relevant OS's and platforms, one soon gets a very large cost just in hardware, software, and salaries, without a commensurate return on investment, especially when the size of the market for each one of the Hardware/OS combinations supported.
So, as I look at it, from a purely balance sheet point of view, Open Sourcing the drivers, with a developer or two available to lead and support driver development, and to act as company liaison to the open source community at large, is a win win situation. The company is happy, because they have increased the size of the market they compete in, and their development/support costs are reduced.
"That's Just My Opinion, I could be wrong"
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?
The reason you the drivers have to be recompiled for each kernel is because Linux doesn't provide a binary driver interface. The interface consists of of calls that do not from one kernel version to the next even though the underlying implementation does change. Every other major OS that I know of provides an interface for drivers. It should even make the kernel itself more maintainable. However, there seems to be considerable oposition to it from the "we don't want anyone writing binary drivers" crowd.
I remember a past report where ATI decided to release input/output specs to the XFree86 people. This enabled them to write drivers with no knowledge of the technology, and my ATI64 driver works quite well, thank you. Driver writers need specifications. There is no need for the writer to know the technology used to reach the specification. As to reverse engineering, Kipling wrote the answer many years ago:
"They could copy every thing I did,
But they couldn't copy my mind,
So I left them sweating and cursing
A month and a half behind."
I do not believe ATI personnel are headed for the poorhouse yet.
If you are in the business of making boards plus
:-)
software, how much money are you making off of
the drivers to drive the hardware? (My guess is
pretty much nada). If the drivers are specific
to your hardware, what can competitors gain from
seeing the source the code that drives it? Also,
keep in mind by releasing the code to the public
you get to take advantage of the (hundreds/thousands)
of folks in finding and fixing bugs (all free!!!!)
Still, if you are concerned that the code contains
things you don't want to release (proprietary
compression, encryption, or whatever) posting
hardware specs (and possibly a barebones "driver"
source code )would go a long way to having a
useable version written for Linux (and others).
And by all means, posting binary drivers would
be nice as well
I Am My Own Worst Enemy
It's not that people here think the GPL is the greatest invention ever which gets you moderated down. It's that you continually attack the GPL in a trollish fashion that gets you moderated down.
Wow, not only do GPV zealots try to redefine the word 'free' to suit their ends, they now also redefine 'trollish' to mean 'accurate' too.
I don't subscribe to RMS's GNUtopian vision.
From where I sit, Linux iseasier. It supports all the hardware I have. When I buy new hardware, I make sure it's supported under Linux. Easy!
What kind of users are you sysadmin'ing that use exotic unsupported hardware?
Don't use Linux, then.
It's that simple. If Linux doesn't meet your needs, don't use it. It meets my needs (and the ideology is, for me, something that I need) so I use Linux and I'm happy. If that means that I can't go buy the latest XBidia BeForce Rage Terror Anguish 2048 XLT video card, so be it.
Unlimited growth == Cancer.
Wow, one sale is really going to break a company.
No, but if we team up, it will work....
eventually...
1. Open-source the driver, minus the cool new tech feature.
2. Add a binary file that someone can add-on if they want the new feature.
Mike Roberto
- GAIM: MicroBerto
Berto
With open source, you have more developers porting the drivers to more platforms used by more customers. (And you don't even have to pay the developers!) PHBs still do not get it? Good luck...
Even with closed source, your competition will still find out everything they want to know about your hardware. (See "How to have fun with disassemblers, logic analyzers, microscopes, and other nifty tools".) PHBs don't understand this either? Good luck...
(Also: still guarding technology which was developed a couple of years ago? These days, that is a long time.)
P.S.: Eric S. Raymond addresses the driver question in Why Closing Drivers Loses A Vendor Money, part of The Magic Cauldron. Good stuff.
Hrmm, yes, it's probably true that a microkernel as a general rule should perform better on multiprocessor systems than on single processor systems. A monolithic kernel with robust SMP code should do just as well, however. This is one of the most important points Linus made in the article I linked - most if not all of the research that's been done on speeding up microkernels so that they can approach monoliths in performance can be applied to speed up the monolith as well. Leaving the microkernel as far behind as it was to begin with. Many of the things that were touted as advantages of microkernels circa 1990 (and in some circles still are) turn out to be things that a monolithic kernel can do just as well.
It's ironic that you cite the infamous test where NT beat Linux on an SMP box. NT is no more a microkernel than Linux is. The NT SMP code was just more robust at the time of the test.
If you acknowledge that microkernel performance is necessarily inferior and that portability is a non-issue, I fail to see what is left in practical terms to recomend a microkernel approach. 'Cleaner design' is a rather subjective term, but it certainly seems to me that a properly written monolithic kernel can be very cleanly designed as well...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
... any more than it's posix compliant. They have paid lip service to both, but that doesn't make it true.
For all the lip service, the fact is that the NT Kernel is a monolithic image including among other things the I/O Manager, Object Manager, Security Reference Monitor, Process Manager, Local Procedure Call Facility, and Virtual Memory Manager. These "parts" of the NT kernel are only parts in concept, in application they are a monolithic kernel. This is a single executable that controls the basic functions in kernel space, not user space. The NT design team paid lip service to the idea of a monolithic kernel, sure, but at they also carefully (and wisely) avoided making an actual microkernel system. The reason? Performance, of course.
As Linux himself mentions in the link I posted above.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Yeah, I know, his name is Linus not Linux. Thought I fixed that before I posted *sigh* but netscape was churning my hard drive and about to die so I was in a hurry, sue me :~
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
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.
It has +GOT+ to be "open source" (note: small o, small s). That's why we're here today. That's what it's all about. If you accept closed-source drivers, why not cs apps? What does it matter, as long as they run?
Open, develop, grow.
Patenting new technology is Not bad. You must be sure it really is New, though. If your company truly is afraid to open source the drivers for fear of placing their technology at risk, why don't they patent the technology? If someone used the technology they have patented in any way that is harmful to their prosperity, they will find out. I can only see two reasons why any company would be afraid to open source drivers for any hardware, unless they make money directly from those drivers. Either a) they are unlawfully using patented technology or b) their technology is ugly as hell with kludges A-Z.
--Drew Vogel
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"
- Some of us don't use modules
- Some of us don't use RedHat
- Some of us don't like being stuck using a kernel that is older that what is available today.
What does that mean? Maybe distributing some form of pre compiled driver that gets linked in to the kernel upon compilation. Doing that so it is not dependent upon some kernel version only distributed by Red Hat (without someone finding their diff list and applying it). If you can hit that target, I am sure many of us would be very happy.How about a new GPL but for drivers. I could state that, yea, you can change the code, yea, you have the code, but no, you are not allowed to make hardware products from this code, but anything else could be allowed. Now I am sure that this kind of thing is not beyond the power of the lawyers that these companies have!!!
Paranoia. If the company you are interning with are confident in their ability to stay ahead of the market, then they have nothing to lose or fear by opening the source. Screw'em, let them find out the hard way; spend you time on something more creative :) Jamey
Jamey Kirby
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
The situation in which open source shines is that in which the code is widely understandable. While an idea is too new to pass that test, open source may not be the best choice. Once the idea is well known -- so that it's well known what needs doing and all that remains is to do it and do it right -- then it's time for open source.
Consider whether or not you can split your driver into two pieces
If, as time passes, your secret becomes less of a big deal, you can open the closed module, or merge the two.
Open Source and secrecy do not, of course, work too well together. Fortunately, they're not as much competitors as one might think. Secrecy is advantageous when an idea is new -- not just an implementation but what-to-implement is needed. Open Source is advantageous when an idea is old (of course old is very much a relative term in this business) -- a good method is known and an implementation is all that's needed. If you can separate out what's truly innovative in your product and keep only that secret, I'd judge you're making a reasonable compromise.
With kernel code, one should pay extra special attention to the interface between the two pieces. A bug in your closed source code can affect the whole system, not just an application using your product. For that reason, you should not only be keeping your closed code as short and simple as possible, but document every guarantee you can and can't make. That way, if (heaven forbid) there is a problem with your code, someone working with just the open source part can diagnose your closed module as failing to obey its own constraints.
This scenario isn't as rare as one might think -- it's just that the open/closed boundary is usually (for open source OSs) in the same place as the software/hardware boundary.
I'm no expert when it comes to Linux, drivers, or open-sourcing, but is it possible to just make part of the driver closed? Or even the whole thing? Surely every single thing on your computer doesn't need to be completely open source.
-J
Karma: T-rexcellent.
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.
I might be wrong, but isn't the reason that they have to keep the features limited down to the fact that you have to compile the driver against a kernel version (even if it's available as a module) ? Which means that they either have to maintain binary modules for each and every kernel that comes around (which is lots) or they can release a limited functionality version as source that everyone can compile against the current kernel.
Because Linux development is fairly fast paced, there is generally a new kernel out every month or so. For a company to have to keep their binary modules current, can be a drain on resources. Creative labs failed miserably with the SB Live drivers... I was running a kernel with severe NFS problems, just to be able to have my sound card working. For them, opensourcing the driver worked. I'm not sure how you'd deal with it if you couldn't!
/* Wayne Pascoe
No one seems to think about maybe having CLOSED SOURCE LINUX DRIVERS. Would it hurt you that much to have fully functional drivers that you couldn't crack open? If they worked well enough, doing what you bought said card for, would you NEED to hack anything else? So what if FULLY WORKING drivers aren't GPL'd. The world doesn't come to a crashing halt everytime someone somewhere using something that's not OSS. It might slow to a crawl ( ;) ), but it works completely.
I see a lot of talk about 'You need binaries for every kernel' and while that is a swaying argument, why not make a mini-module architecture that is kernel independant, or allow linking a binary object to some code to make a module for the current kernel. That's probably why they can release windows drivers and keep them updated, becuase even if they support all windows platforms, they only need 3 or 4 different drivers, compliled once. I think it's too much to ask a company to compile 50 different versions of a module just because you use linux. I understand that lots of companys don't want to open source their drivers because of technical concerns, but with a system in place for modules that work independant of kernel version, they would have a way to write the driver and keep one version maintained and release a better driver if they choose to keep it closed source, and I'd rather have good closed source drivers than open ones missing functionality.
Free Online Woodworking Resources Directory
So, a manufacturer completes and compiles a Linux driver for, say, the two most widely used kernels at compile time like Creative did then for the SBLive! Is there a way to make an app that would allow a manufacturer to take their closed source and compile it automagically six or eleven times, saving to different filenames, for six or however many different kernels without headache on their part? Make it as easy as possible for them to do what you'd like to see them do.
Or, maybe a small, spare-time company of you gents that can sign NDA's and run quad/pent boot machines with different versions of the kernel, compiling closed-source drivers for all kinds of kernel revisions and maybe even other OS'es.
You've been moderated down for posts critical of the GPL. I've read some of your posts before, and based on that you may have deserved it - you definately have a tendancy to walk the line between being critical and just attacking, and to attack it in a flamebait (NOT trollish as the other poster stated) manner as well.
Excuse me? I have? Or are you assuming that I am the same person as the original poster?
- In Capitalist America, law violates YOU!
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.
What you have at first appears to be a conflict of interest. If you add the additional functionality to the Linux drivers and open source them, you are allowing your competitors access to solutions that your company has spent time and money developing. Also, what will the M$ Windoze clients you have think to this. Assuming open source for Linux drivers IMHO will impact the price because you will be allowing your competitors to produce a similar product with the same functionality, thus creating competition on price where the Linux solution becomes much less costly than the other solution. I imagine this would lead to some angry calls from your closed source users.
There are IMO two options.
1. Don't open source.
2. Open source
If you decide open source you may lose some competitive advantage on price of whatever you are selling. IMO the way to regain this competetive edge is to provide exellent service to your clients. If you are providing a good solution with excellent after sales service I can't see why opening the source of your drivers will have a detrimental affect.
You may also get some other developers looking at your drivers and making improvements which maybe in a closed source operation would not have been considered.
"Common sense is nothing more than a deposit of prejudices laid down in the mind before you reach 18" Einstein
Yeah, but's whats obsfucated? Ever looked at the source for GCC? EEEEEKKK!
Syllable : It's an Operating System
Don't be torn. This isn't an either-or kind of thing. Closed source drivers means poor support.
To me personally, the biggest reason why closeed source drivers are bad is that they're almost universally x86 only. The leaves those of us on other CPU architectures (I run Linux on PPC and Alpha at home, and Alpha at work) out in the cold. The really sad thing is that vendors wouldn't even have to do the porting themselves if they'd just release the source. There are plenty of us out here who want to put cool hardware in our machines and have the skills to make the drivers work. Unfortunately, it's very hard to quantify the effect this would have on sales, which makes it hard to justify to the suits.
Another reason why closed source drivers means bad support is kernel specificity. Sure, the driver may be certified to work just great with that kernel RedHat 6.2 or SuSe 6.4 installed for you. But what if you're working out on the development branch? You're SOL, that's what.
And of course there's all the other reasons everybody here knows by heart (faster bug fixes, lower code maintenance costs, etc.).
And the whole "somebody's gonna steal our tech" argument is usually bogus. Unless we're talking about something very high-end, the competition for the consumer's dollars will be very fierce. If you have an innovation over your competitor, they'll one-up you in six months time. (For example, look at the pace of the 3D accelerator market ever since it's become mainstream.) In other words, by the time they could reverse engineer whatever it is you're doing, they could have just as well worked out their own newer, better tech. Reverse engineering your competitors in a commodity market is almost never worth it.
CVS is teh suck. Use Vesta instead.
Why don't you just release a binary-only version with all the features and a crippled open-source one (which noone would use)?
:)
Most likely your company hasn't even thrown any funds at developing proper Linux-support, so 'fears about giving away important secrets' are a convenient excuse...
Da Warez D00d
All of my releases are binary-only
wouldn't that completely destroy the original idea of open source, i.e. that you can add your own features and ideas? Da Warez D00d
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.
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?
For some stuff it's pretty trivial. If all you need to do is write a little bit of stuff to I/O ports in a particular order, then there's sod all to it. But that won't tell you much about the hardware.
The problem comes with stuff like WinModem cards. Here, as WinModem victims know all too well, the hardware is pretty dumb, and all the intelligence is in the driver. That driver's had a helluva lot of work put in on it (don't believe me - how long's it taking those guys to duplicate it then?) so releasing it as open-source would essentially release everything about the card, and provide other WinModem competitors with a ready-made template for their driver. OK, maybe they just make the source available but don't release it GPLed, and rely on copyright to stop other companies nicking it? Tough shit - once it's out then it's out! Have you guys not heard of Gnutella? Once it's in the wild, it doesn't matter about copyright or lawyers, it's gone!!! In a lot of high-tech places, the real leading-edge stuff isn't even patented, cos that would tell competitors how to go about doing it, so they could copy you. Maybe you'd be in the right, maybe you'd even win in a court case, but any good lawyer could spin out a case like that for years until it's broken you, so forget it.
Want another place where open-source will never, ever reach? Programmable chips (microcontrollers, programmable logic, etc). Nearly all manufacturers (Microchip are one major exception) keep the programming algorithms secret, protected by NDAs. So there can NEVER, EVER be a universal GPL'ed chip programmer, cos the very act of distributing the source code violates the NDAs by revealing how it's done.
I suggest the "I won't use it unless it's completely free" lobby smell the coffee. Free's nice, but it's not the only game in town. There isn't a computer newbie that I know of who'd want to do kernel recompiles just to add a new joystick or something, so I think Linux needs binary driver support, and fast, otherwise it can't be taken seriously as any sort of a desktop option. If you're seriously worried about system stability, only buy stuff with GPL'ed drivers. For the rest of the world, it's better to have driver support than not to have it, and bugs may happen but the manufacturer's testing should sort most of them, and if a product's known to be buggy (eg. RDRAM now!) then no-one buys it unless they're real suckers.
Grab.
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.
Hypothetical situation - I write a piece of GPL software. It has some clever graphics code, so someone uses that code in their program. They would rather use the BSD licence, but since they use my code, they are obliged to use the GPL. They do this since they don't really care too much as long as people use their code.
Someone else is really impressed by their networking code. They decide to use that. They too are forced to release under the GPL, even though the second person wouldn't have minded if they didn't. I have managed to force the GPL on a piece of software that I had no input to.
This is based on an actual problem someone had, when they wanted to port a Linux driver to FreeBSD.
Person 3 isn't using my code. He still has to GPL it, because I GPL'ed my code. My decision to use the GPL affected the code that I had put no work into at all.
I believe I know the case you are talking about, and I believe in that case the FreeBSD hacker, instead of whining and claiming that he was being "forced" to use someone elses code sucked it up and wrote his own BSD licensed code,
Well, thats efficient use of time isn't it. The driver writers didn't choose to licence under the GPL. Linus did. They didn't have any choice. They were actually quite happy for the driver to be rewritten under for BSD.
Not that this should be an issue, anyway. There is usually very little of interest in terms of patentable algorithms (even in today's world of ultra-liberal software patent) in a driver. Anything that these companies have come up with for drivers has doubtless also been invented by all of their competitors.
A well-crafted lie appears unquestionable - Dama Mahaleo
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Surely if your rivals are capable enough to steal your technology, then they must have the means to reverse engineer your products in different ways, other than by looking at source code to drivers. Conversly, if they need to see the source code to figure out how your devices work, then they are probably not capable of putting your technology to good use.
The downside is that if they don't keep up with the kernel and library releases (also see above driver failure rate :-( ) then it doesn't help a heck of a lot.
I want to delete my account but Slashdot doesn't allow it.
Very well said! Period. Trian
I'm no longer fed up with MS Windows: I go rid of them
And the FSF are the only ones who can write licenses?
I had an ISA sound card whose MIDI port was not working. The problem was that the chipset used by the card was of a later revision to the one supported by the driver in the then current Linux kernel. All I needed to do was to locate the IO port that contained the MIDI settings, then write the correct value to the card. No specs had ever been released, and the manufacturer no longer made sound card chipsets
I played around with the standard Linux kernel driver, adding printk statements to work out what was going wrong, and what values the probe routines returned. I worked out where in the code I could init the port, then got round to discovering what value(s) to write, and which port(s) to write them to.
I located the DOS driver that was loaded in Windows to initialise the card, without any documentation as to the switches to use. A quick inspection of the disassembly located the code that wrote from memory to the range of control I/O ports. I then located a table of IO Port value - bitmask pairs. Next to this table in memory was a simillar list of IRQ - bitmask pairs. By ANDing these pairs together I had the value to write to the IO register. I only needed the register itself.
I then searched the disassembly for a reference to the address of these tables - no such luck. Searching for addresses closer to this located the code that did the table lookup and wrote the correct value into memory. I hardcoded the write into my driver, reloaded the module, and all was now working.
I then spent a few minutes adding a couple of case statements and the odd debug message, then created a patch and submitted it. My patch appeared in the devel kernel a few weeks later.
Since then I've acquired a 6-port serial/synchronous card. Not only do no documents exist for this card, but there only code I can locate is a DOS diagnostic. The card was expected to run under a custom OS which I don't own. I'm not having much luck.
Is it just me or do we see this question every month?
"After three days without programming, life becomes meaningless." - Tao of Programming
i just don't get the mentality of trade secrets in the context of software or hardware. any electrical/computer engineer, with the proper motivation, should be able to reverse engineer your boards and software. in other words, if your competition can buy your product he/she knows how it works.
i do understand trade secrets in terms of production i.e. how much it cost to produce each board, the order of assembly, or how fast they can be produced. here your competition can only estimate.
i don't see how closed-source can protect your companies tech. if the product is unique and lasting get a patent to protect it! my guest is that, as usual in the computer industry, patenting the tech is not worth it, because you'll be using new boards/tech next year. which would mean you want to sell as many board this year as you can ... so make the nerds happy and open-source the damn thing.
Why don't you try a mix of the two? Modify you current open source driver to include an option that will look for a closed source extension that will turn on the extra options. Just make sure that your fully document the extension so the driver can be rewritten for other operating systems.
I have great faith in fools - self confidence my friends call it. - Edgar Allan Poe
It seems to me that the best solution is to release the specs for how the driver communicates w/ the device (all the specs, unlike how nVidia released partial specs). I don't think this information would compromise any IP. Then the Linux folks could write drivers for the device, maybe even better than the company made. Who knows, the new hacked-up drivers could provide some useful tricks that could be incorporated into the Windows drivers.
Company XYZ is squeamish about open-sourcing their driver.
They say it's because it would release sensitive information.
If this is true, there are important functions being performed by software (the aforementioned driver)
Then the hardware is less-than-optimal and your CPU will do unnecessary work.
BUY FROM THE COMPETITION!
Oh, BTW people talk a lot about graphics boards but what about those horrid WinModems and WinPrinters? IMHO, even people who only use Windows should refrain from buying these.
"Standing up to an evil system is exhilarating." --Richard Stallman
The way to deal with this is to design in a hardware-level interface that abstracts out the trade secrets. The driver should just be an interface to the operating system, not the essence of the product.
... 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.
Creative could, if it wishes, provide a library of closed-source functions (well-documented) that would expose only those interfaces needed to talk to the outside environment, while keeping the intellectual property hidden behind a veil.
The advantage to Creative is that they could now concentrate on getting the display routines correct without giving away IP and without having to add staff that knows a number of target operating systems. The advantage to the Linux and FreeBSD communities is that the respective communities can deal with any OS interface problems using the normal channels.
The added bonus to Creative is that they now have a kit to provide to other OS vendors (BeOS, MacOS on Intel, QNX, even Bell Labs if they ever want to get back into the operating system game) that reduces the load on everyone.
Frankly, I'm getting tired of the "Victory or Death!" attitude that permeates portions of the Open Source Movement. Open source has its place. Closed source has its place, too. Let's be engineers and blend the best of the two concepts, instead of religious nuts more interested in the Grail of the Week.
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?
===
This is astounding. You sir are a fool. Who are you to say what these companys should do. Did you put the money into the product? Did you spend months designing the product? Did you spend the mind wracking nights making the product work so that most of the market share can use it? (yes this may mean microsoft software.) Who are you to say that you want the source? Because you are a user?
If you like it or not (more like not) People in this world have to make a living. and that means not giving stuff away when you can prevent it. Yes I agree that the world would be a better place if we could give every thing away, but that isnt going to happen in my lifetime (or in the lifetime of my grandchildren im a thinkin)
All of you kids need to grow up and spend a day in the real world. Yes idoligies (bad spelling) are a good thing as long as you remember its just a IDEAL. Sometimes people dont share them. And companies dont make money off of them. And I dont get payed off of them. And I dont buy stuff (like my computer) off of them.
Sig? whats a sig?
"They said we couldn't do it [Athlon]... but we built it, we shipped it... and we didn't have to recall it." Rich Heye
but to those coders have the right to keep the source closed? Do you have the right to keep your credit card numbers private?
Info only want to be free if the person who "owns" it wants it to be. (owns is a bad word i know but i "own" the info to my bank accounts and nVidia "owns" the info to their drivers.
"They said we couldn't do it [Athlon]... but we built it, we shipped it... and we didn't have to recall it." Rich Heye
I've written many dozens of drivers over the years, for all kinds of devices, and I'm torn on this one. On the one hand, a company puts a lot of hard cash into developing a driver, which they don't want to give away. On the other hand its nice to have lots of knowledgeable people out there reviewing one's code and pointing out errors. I could write a book of war stories of how companies have lost credibility, even hard cash, because they went closed-source.
The paradox is that Linux also provides it's users with the freedom from having to choose from the huge amount of software and hardware in stores like CompUSA which their OS won't support. I agree that it makes life simpler when there isn't much in the store worth buying.
Truly: "Freedom's Just Another Word For Nothing Else To Lose", to quote a dirty hippy from an earlier generation.
There is a very simple answer to the question at hand. If the company is too worried about exposing a certain technology in their card they can release binary versions of their linux driver. I am sure that users who would benefit from the enhanced functionality would have no problem using a precompiled binary from a reputable vendor.
It seems to me that many people associate Linux with open source philosophy almost too much. Not that I am complaining, as I would most likely choose an open sourced solution to a closed one, but this trend seems to be keeping several vendors from exploring the Linux markets. I much rather have a closed source binary distribution of a product than no product at all!
(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.
If they will only release a binary of the driver, that is better than nothing. Linux users will gripe, but at least they will be supported.
But why not release it open source? Any decent hardware hacker can snag a logic analyzer and disassembler and pull the code apart. Besides, it can't be that big of a mystery; your compeditors probably have some engineers working on their own solution--the release of your source won't make a big difference.
Look man:
1.- Do you want to SUPPORT the linux market?
Are you sure?
Is your company sure?
Do a market study to determine the
potential gain of going into the Linux
market.
2.- Once you have (1)...plan ahead and determine the cost of mantaining a binary distribution of Linux. Your market study should have told you which distros give you the most value.
3.- Now think about it. Plan ahead and determine the cost of releasing an open source version of the driver.
What would be the oportunity cost of having somebody clone your device?
Does being the first to use it gives you enough lever to crush the upcomming competition if you do release a GPL show-all driver?
The binary release (if you are thinking about giving true professional support) will be more costly than the OS release. Thats a fact. So compare costs and choose the most convenient solution.
Remember to take into account the reduced cost of mantaining an OS driver (it can be merely an accept/refuse patches job with OS). Compare it with the cost of mantaining a sun-like, look-dont-touch license (it can reduce beta testing costs)....and so on.
Alex
Stop looking at me.
If every post of yours didn't end with a reference to the General Public License in a trollish fashion perhaps it wouldn't be necessary to mark you as a troll...
Ranessin
Maybe its possible to have the two exist together... Open source doesn't require your internal company tech to be given up... if you have patents, then you can give up the specs and open-source the driver without losing any commerce and in fact will make more money because your drivers will work better and make users happy. Your money is in the device that you sell. So it probably is in the best interests of the company to open source the drivers for a proprietary device.
Maybe the best thing if you have a non-proprietary device (i.e. a sb clone, etc.) is to make the item compatible with a standard device... then you concentrate on making your device faster within those constraints... if you find a way to make it better outside those constraints likely its patentable and can be open-sourced without hurting your companies concern... losing money.
The other thing is that the GPL requirements may help you in this case... A new device reverse engineered from your opensource driver could be a derivative work... and thus subject to the same requirements that it be "open-sourced", so you can use any improvements they make in your own device. (Not an expert legal opinion though).
Now, I don't know all that much C yet, but it seems to me that it might be possible to make a closed-source driver that compiled on various different kernel versions and achitechures. Maybe (again, I might not know what I'm talking about here) the company in question could release a binary library of the actual functions of the driver, and then provide source for a kernel module that called up the library to do the real functions. Thus, the secrecy would be preserved, but yet so would the portability. What do you think?
---- I'll take you in a Hunt deathmatch any day.