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.
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?
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.