The perpetual debate over the legality, practicality, and wisdom of using, distributing, producing, and supporting binary-only drivers flared up again recently, with a recent debate on the Linux Kernel Mailing List over the legality of binary-only drivers simmering down and Ubuntu company Canonical considering enabling binary drivers by default in the next release.
Neither of those address entirely whether end-users should use binary-only drivers.
To some people, the choice is easy: freedoms (especially the four freedoms) trump pragmatic concerns. It’s better to do without a piece of hardware or a feature for which there is no free driver support than to give up freedoms to use it.
This issue raises passionate debates, and those debates often walk the lines of a false dilemma: freedom versus pragmatism. The reality of the situation is that there are degrees of freedom and pragmatism in everyone’s choice. Though some people choose to avoid binary driver out of pure philosophy, many others do so to avoid very real risks.
Hardware Risks
What happens when the binary driver vendor does not support your current platform? The hardware might work just fine with your hardware, but you’re in for trouble if you want to use an x86-only driver on a PPC machine or a Sparc.
You might be in luck if you want a 64-bit driver… but the further you get from the vendor’s supported platform, the less likely things are to work. At some point, it’s worth asking whether choosing the underlying platform based on the availibility of binary drivers for a single piece of hardware is worth it.
Even if the vendor supports your current platform, will that support continue? Vendors go out of business or merge or drop support for older hardware when it’s no longer in their best interests. Do their best interest match yours?
Software Risks
A well-known aphorism is that Unix’s method of portability and backwards compatibility is source code distribution. With well-written source code, a simple recompilation fixes most binary-incompatible changes. With a binary driver, when you can’t recompile against a new library, you may be unable to upgrade other parts of your system.
This can be a problem when you need an updated kernel to use another feature of your system — or another driver. This can even be hazardous, when the update involves a security fix.
Binary drivers can have security problems themselves. A recent NVidia binary driver root exploit remained in the driver for two years.
The risk not only affects your decision to update; it may render that choice moot as well. The Fedora advisory board recently decided against an X.org update so as not to break binary-only drivers. While the update did not contain any security fixes and was to a mature project, it does demonstrate how users who choose to use binary-only drivers can restrict the available choices for users who choose free drivers.
Vendors have at least one additional concern, if they choose to distribute binary-only drivers: what are the legal considerations of this choice? Regardless of the status of the source code, it’s difficult to argue against the claim that a compiled piece of software is a copyrighted work. Thus distributing that software in a compiled form requires the permission of the entity who holds the copyright of the source code.
Certainly a free software distribution could negotiate permission to distribute necessary binary components (even OpenBSD requests vendors to allow it to distribute binary firmware, when absolutely necessary), but can the distributor pass that permission on to all recipients of the distribution?
It would be a pity if people who refuse to use binary-only drivers on either philosophical or pragmatic grounds were unable to give CDs of their favorite distributions to other people because of the short-term pragmatic solution of not only accepting binary-only drivers, but redistributing them.
Use binary-only drivers if you must. It’s your choice. However, please consider how your choice to do so affects everyone else as much as you consider how your choice to do so may limit your current and future options as well.
Thank you for a concise summation of the situation. Well-reasoned and nicely done.
It's better to do without a piece of hardware or a feature for which there is no free driver support than to give up freedoms to use it.
One can choose to use, or choose not to use, binary-only drivers. Choosing one way or the other does not mean giving up any kind of freedom to use the hardware. One can always choose to remove the binary-only driver when a free driver is available.
Well I am looking forward to modem support coming to Ubuntu. I have a few people who I could upgrade from win 98/ME but having to go around and reinstall modem drivers each time there is a kernel patch....
Mind you one is able to go to ADSL and I am going to install for her shortly.
Her daughter bought her a camera with no support for ME.
After Feisty a few more might be on the cards.
"freedom versus pragmatism"
These two are often pitched against each other this way (not in this article though).
It is a false representation since what is called "philisophy" is really "long term community practicality", and *real* "practicality" is really just "short term ego-centric practicality".
Now noone can be 100 percent social all the time. In the real world sometimes short term gratification trumps long term benefits.
But such an anti-social act should never be praised as something good or acceptable.
This is why I'm patiently waiting for Nouveau. (The open 3D driver for Nvidia cards). Its gonna be a while, but it'll be worth the wait. ;)
Firmware and binary drivers are not AT ALL the same thing. Firmware that runs on the device is not part of the host operating system; the only reason that it is not stored in ROM with the device is cost saving.
A device driver that runs on the host processor as part of the host operating system is a different matter entirely. Many people object to this; giving unaudited code that level of access to the machine and operating system internals is worrying to many people.
@Nick, good point. I don't mean to equate them as strongly as I did. I merely meant that distributing binary components has copyright concerns, but that it's possible for free software groups to negotiate with the copyright holders appropriately.
This was a great article, very well thought out and good summary of why proprietary binary blobs are bad.
One thing though, what about how it stifles innovation and slows down development of free software. For instance "XGL" is just a hack, and they had to do a lot more work, so the binary graphics chipset drivers would work. But the more proper method for desiging the system is "AIGLX". But all that time and code was wasting trying to run circles around Nvidia and ATI with "XGL" because of their proprietary drivers.
The author asks what if the vendor does not support your hardware and suggests it may not be in their interest to do so. This is of course a valid point. But there is also the same issue for open source / free software - what if no individual has appeared who is interested in writing a driver for you hardware? Same problem.
I have the problem at the moment with a piece of hardware that very people are interested in. Ask a question on a forum and no one answers it - no one is interested.
A very big problem in the open source world is when the original developer of a piece of software tires of working on it, often before it has been finished (e.g. still in alpha and in the most difficult phase of bug fixing a large piece of code), and no one else steps in to continue development.
The only truly pragmatic approach is to choose hardware for which there are openly (i. e. without NDA) published programming specifications. Alternately, though not optimal, we could use hardware for which there are F/OSS drivers (e. g. Atheros and Broadcom wireless, even though I despise both).
Back during World War II, a "pragmatic" approach to fighting the Japanese was made by the US Government. That "pragmatic", i. e. "we gotta do somethin' NOW" approach resulted in the illegal internment of American citizens simply because of their genetics ("those Jap-Americans *might* be enemies, gotta jail 'em"). Oh, but white Germans weren't rounded up and jailed; after all, they're white. Sorry, there's nothing "pragmatic" about that; that's a racially-motivated police state.
The "choice" of buying proprietary hardware, i. e. hardware with no published specifications, or even hardware for which no specs but F/OSS drivers exist, is NOT at all pragmatic, any more than allowing the cops to bust into your house, guns blazing, with no search warrant, is. Eric Raymond and Mark Shuttleworth both have it totally wrong here; Richard Stallman and Theo de Raadt are right on.
The only *truly* pragmatic approach here is to purchase hardware that's supported by F/OSS drivers. Anything else is pie in the sky and indefensible.
To StolenNomenclature, regarding your hardware device with "little developer support:"
You are correct in that a F/OSS developer of a driver can stop at any time. You are further correct that some devices get more F/OSS developer attention than others. But you're forgetting something else very important.
That forgotten "something" is this: if your hardware has openly published programming documentation, *you* can write/maintain the doggone driver yourself. Alternately, you--or your organization if you work for a company--could hire a hacker to do just that if you personally don't (yet) have the skill. You have the *FREEDOM* to actually *do* something about it. Whether or not you choose to exercise that freedom is also a free choice of yours, but at least the opportunity is there and exists.
By contrast, with "NDA-only" programming documentation for a device (e. g. anything from Texas Instruments, Broadcom, or Marvell), you have to beg Microsoft/Apple/OtherBigProprietaryCompany and hope that they'll listen to you. In this scenario, you have *no* recourse at all, unless the Big Proprietary Companies see dollar $igns for doing it. Unless you reverse-engineer the device (an *EXCEEDINGLY* difficult task, at best), you cannot hack a driver yourself, and you cannot hire any hacker of your choosing to do it for you. You're screwed, with no way out.
That's the difference, and that's why choosing hardware with truly open programming documentation is so important.
Nick C.: Firmware is definitely not a part of the operating system. However, it is software, and if compiled in the kernel, it is linked to GPL code. So, it must either be opened, or be out of distribution. (You are free to link it in for your own usage, but GPL prohibits you to distribute the resulting combo.) So, Canonical will be in a GPL violation if it enables the binary drivers in the kernel by default.
This may be good or bad, right or wrong - but it is a legal fact. Either GPL is a license, and should be honored, or it is moot. And if it is moot, it is moot not only for what Canonical, me or you don't like, but for the copyleft principle, too.
At work most people have their hardware chosen by corporate standards and many corporations neither understand nor support F/OSS. Server vendors, in particular (think HP, IBM, Dell), deliberately include proprietary hardware and propreitary Linux drivers for that hardware. Given a choice between not having Linux be functional in the workplace on one hand and using binary blobs on the other I do think the pragmatic choice is the best one for the Linux community. What has fueled the growth of Linux and generated widespread interest in F/OSS is Linux capturing significant market share in the corporate server room.
Look, don't get me wrong. I agree that binary blobs are a bad thing. However, until we can convince large enterprise users that they should demand open drivers for hardware it's going to be awfully tough to move away from them.
@Caitlyn, can you be more specific about the proprietary drivers in corporate computers? I'm not sure it's entirely as important an issue; do people have permission to install open systems on these machines? Is this hardware vital to the operation of the machines?
The drivers I had in mind were for modems, 3D accelerators, wireless cards, and printers. I've not seen a lot of need for those for standard business desktops, but I may have overlooked something.
Where do I even begin? Dell has propreitary drivers for their PERC raid controllers in many of their servers. HP has a slew of proprietary drivers for their servers. Some have open source alternatives (i.e.: qlogic hba drivers) but if you don't use HP's there is a question of support.
We're talking about severs here -- server that sometimes come with Windows and get repurposed but more often servers that come with Linux preloaded. When it comes time to upgrade the OS (usually Red Hat or SuSe Enterprise) the system administrator often has to choose between using supported drivers from the manufacturer and ones that the OS distributor has which may or may not be open source. Sometimes there just plain is no choice, as with the aforementioned RAID controller drivers for the PERC 4.
@Caitlyn, that's exactly what I wanted to know. Thank you! (I had overlooked the requirement to keep the environment pristine in order to receive support.) I haven't been a system administrator for seven years.