Pragmatic Questions about Binary-Only Drivers

by chromatic

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.


Egon Spengler
2006-12-25 10:20:16
Thank you for a concise summation of the situation. Well-reasoned and nicely done.
2006-12-25 20:17:42
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.

2006-12-25 21:08:52
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.
2006-12-26 05:29:51
"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.

2006-12-27 19:17:53
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. ;)
Nick C.
2006-12-27 19:42:41
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.

2006-12-27 20:08:22
@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.

2006-12-28 01:16:04
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.

2006-12-28 14:36:24
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.

Sum Yung Gai
2006-12-28 17:33:47
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.

2006-12-29 13:24:37
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.

2006-12-29 13:42:33
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.

Caitlyn Martin
2006-12-29 13:47:56
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.

2007-01-02 14:56:55
@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.

Caitlyn Martin
2007-01-05 12:48:04
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.

2007-01-05 13:02:30
@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.