The issue of binary kernel blobs cropped up on the gNewSense Mailing list recently. The discussion I saw was friendly enough, but the real benefit for me was that I got to see just why kernel blobs are so, well... contentious.

Just imagine, if you will, watching the discussion unfold before your very eyes - or part of it anyway. A BLAG developer suggests some kernel blobs are actually GPL'ed - their source is directly in the kernel - and that the gNewSense team should most likely feel free to keep them in the distribution. But one after another responds to the effect that, despite the license, they will need to verify that each meets the 4 Freedoms defined by the FSF. An unwitting witness might instantly assume these gNewSense guys are serious, frothing, Free Software fanatics beyond your wildest imaginations. However, asking a few questions goes a long way.

I asked Kevin Dean, in particular, about his response, which initially threw my mind into an infinite loop of its own. He started off saying, effectively, that it was possible for a GPL'ed program to not actually respect all of the 4 Freedoms. You can probably see the loop starting already. He then gave this example:

For instance, several of the drivers in the Linux kernel are licensed under the GNU GPL but since the sources themselves do direct memory accesses - preventing the user from understanding the process of WHY these edits do a given thing - we feel that they do NOT respect freedom 1. Furthermore, without understanding what the direct memory edits are doing, you really don't have freedom to change how they function.

Ok, I thought. It's GPL'ed, but it doesn't respect the 4 Freedoms? How the heck is that possible - blob or no blob? That is essentially the question I posed to Dean. What's so special about blobs? After all, you have the sources. In reality, I was a little concerned that these gNewSense guys had gone way off the deep end. Not being a developer, I felt a bit lost. Dean was kind enough to humor me and took my question seriously.

I am including the second half of his response by his permission, and you should note that his response is his own (he is not speaking for the gNewSense project). He started off with a basic crash course in how programs are converted into the binary signals that a processor can actually work with, and pointed out that this is where the issue arises...

While it is possible to look at the C code and say "Oh, this activates power saving mode" it is also, in the C source code, possible to give instructions that ARE NOT traslated into assembly when the code is compiled. You can, in C, say "Find the bit of data at memory address 0x0f and change it to 0xff".

In the first example, the user who can read C has the ability to look at code and even edit the behavior of the device (a video card in this example) because he can see how the code is handled during each step.

In the case where you don't have human readable code, only assembly instructions written in C, it looks like alphabet soup. Someone can look at the code and see that data (in bits) was put here and there but not WHY that data was there or what event triggered the need for the change. Because he can't see what's happening, the ability to edit it drops exponentially. Sure, the user COULD begin changing numbers around and things would happen but the user still has no control over the device.

Let's make this even more complicated...

Sometimes this "assembly in C" is licensed as Free Software. Fitting in with our fictional example, lets look at the ATI Radeon driver. The very beginning of this driver contains "microcode" which is a form of binary blob. This block of memory addresses is a "configuration" file (so the Radeon developers at Xorg tell me, I do trust their word) that is then sent from the software to the card and the card says "Hey, I should start up" - the computer understands what this string of numbers means, but the user, once again, has no way to see exactly what data is being sent to the card and had no reliable way to change what is in that data.

The implications of this can become almost frightening if you change the "configuration file" to "some unknown chunk of data" and change our fictional device from a video card to a wireles network interface.

So, even though a certain blob may be GPL'ed, the way it is implemented does not respect the user's right to study the software. According to Paul O'Malley, "They are for want of a description precompiled and then published with permission to alter them in their compiled format." Even the best developers would have difficulty making sense of what is happening in these cases. But, most importantly, the developer cannot discern why. Without knowing why something happens, you'd be hard pressed to know what changes to make. Other developers not related to the gNewSense project have confirmed the issue.

Sorting through this kind of issue is seriously tricky stuff, since the software is released as Free/Libre (and even under the GPL), but nevertheless fails to respect all four freedoms as defined by the FSF. It is fairly common knowledge that Debian ships with blobs, and only BLAG, gNewSense and OpenBSD have considered them a threat. Dean pointed out the fact that some fairly serious flame wars have cropped up in various lists over this very point. No Doubt. The ultimate question I found myself asking is, How Free is Free enough? Dean encourages people to keep an open mind. Issues like this can generate hurt feelings and ill will all around, so best to keep an open mind.

In further conversation, Dean went on to express his personal view that, "I don't believe any license could forbid the use of binary blobs and still be a libre license. Some devices simply will NOT function without them. I'd MUCH rather have someone run the Radeon driver (which has libre microcode) than use the fglrx (?) driver to "unlock" 3D features. I'd also much rather AMD design their cards in a manner that doesn't require a blob in the first place." I agree that avoiding the need for blobs is the best policy. I fear, though, that most manufacturers don't really care about this issue as much as many in our community do.

To keep things in perspective, it appears that most of the blobs involved in this case are for rarely-used hardware, and unlikely to affect most users. How the gNewSense team will ultimately handle the issue remains to be seen. BLAG has apparently allowed them to remain, since they are GPL'ed. Presumably, so will Fedora, which is cleaning up its repositories. As far as I know, only OpenBSD strictly forbids binary blobs. I believe the FSF prefers that the blobs go away, but doubt they are pushing the issue of GPL'ed blobs. I have not seen any condemnation from the FSF regarding GPL'ed blobs, and the GPLv3 does not address them at all.

I think it is a great idea for all distribution developers to consider the impact of blobs on users' freedom. In fact, I think every user needs to give a little serious attention to the issue of freedom in software, and define for themselves where they draw the line when it comes to how free Free needs to be. Personally, I would probably go ahead and allow the GPL blobs to stay in - at least for now. Even so, it certainly seems worth investigating how to avoid blobs and encouraging hardware manufacturers to establish a policy of avoiding them. I can honestly see why binary blobs are problematic and believe they really should be avoided.

The way I understand things, I can actually control what my kernel loads. If I don't want it to load a binary blob, I can make the appropriate changes and re-compile. I may lose some functionality, but I certainly don't need my kernel loading stuff that I don't use. In the non-Free world, I wouldn't even have the ability to choose what to load in my kernel. And this, I think is the real issue. What choice does the user have? And does the user know they have a choice? After all, is not choice the birthright of freedom?