That is why Alexandre Oliva started the GNU Linux-libre project, so that free software advocates can become aware of the problem and use a truly free kernel with their operating system. Oliva has been an active member of The GNU Project since 1991, starting as a bug-reporter and, after a couple of years, maintaining Autotools and the GNU Compiler Collection. After this work landed him a job with Red Hat in 2000, he also became involved with binutils, glibc, and the GNU Project Debugger. He has since become known as a regular speaker about the free software project and as one of the founders of FSF Latin America.

According to Oliva, the Linux kernel was originally free when it was relicensed in 1992 under the second version of the GNU General Public License (GPL). However, since about 1996, it has been accepting what are known as firmware blobs – binary, proprietary bits of code best-known to occur in drivers for wireless and other peripherals. Since the source code for the blobs is not available, Oliva and other free software advocates argue that they make the entire kernel non-free.

“The first blobs in Linux,” Oliva explains, “were very small pieces of object code, disguised in the source code as arrays of characters [and] licensed under lax permissive free software licenses.” However,

[O]nce the gates were open, other blobs with various misfeatures started to flow into the Linux sources: some had licenses that were clearly proprietary, explicitly stating they were generated out of secret source code, forbidding reverse engineering and imposing several other GPL-incompatible restrictions. Others have free software licenses, [and are] GPL-compatible except for the lack of source code, but they’re no longer tiny: some are entire operating systems that run on peripherals, weighing more than early versions of Linux itself.

Over the years, some attempts have been made to submit patches to reduce dependency on firmware blobs, but “they were not only rejected, but disparaged.” The most that the Linux kernel project would do is move the blobs into separate files, which made them easier to find but did nothing to change the basic problem.

The presence of blobs went unnoticed until around 2005, when Ututo, the first wholly free Linux distribution, noticed them and started removing them from their own releases. Soon after, gNewSense, another free distribution, released its first version that included tools to help locate blobs in source code, and Oliva began Linux-libre.

So why has this basic problem not been addressed? “The Linux project does not share the free software values,” Oliva says bluntly. “The top decision makers there do not agree that users deserve freedom in all the software they use or that any software that takes their freedom away is a problem, a tool for subjugation that can and will be abused to extend the power.”

He notes, too, that many popular distributions “mislead users into believing they are Free as in Freedom” while they really aren’t. Oliva doesn’t say, but no doubt the common practice of including non-free software like the Acrobat Flash Player for convenience serves as a precedence for distributions not being concerned about firmware blobs. After all, insisting on a completely free kernel can still cause hardware compatibility problems, even today.

Making and Using a Free Kernel

Today, Linux-libre or its scripts are used by all the distributions that the Free Software Foundation lists as completely free. Volunteers also uses the project’s kernels to help create free kernels for Debian, Ubuntu, and Fedora, which “gives users the option of recovering their freedom without abandoning their favorite distros.”

Most of the basic work of creating a Linux-libre kernel is done by Oliva, although creating binaries for specific distributions are often done by other project members as well.

Oliva’s work consists of updating the “deblobbing scripts,” then running them against the Linux kernel’s source code:

The updating takes place once per major release cycle: I take a [release] published by Mr Torvalds, run the previous release’s deblobbing script on it, and adjust the script until it runs without errors. Then, I run the deblobbing script in hunting mode, so that it reports any new blobs or requests for blobs that aren’t covered, and adjust the patterns so as not to flag false positives, and so as to deblob new patterns correctly, repeating this step until the entire tree is regarded as blob-free. Finally, I compare the changes introduced by deblobbing with those in the previous release, and make any further adjustments to the handling of files that were over – or under – deblobbed.

Once this preliminary work is done cleaning a tarball or source code tree based on the same release requires only the running of the appropriate scripts. Updating the deblobbing scripts generally takes an entire workday, whereas deblobbing a source tree takes only a few minutes – often less time than archiving it in a tarball.

The tarball of a deblobbed kernel is compiled exactly the same as any other kernel. Whether users notice anything different depends on their distribution and hardware. In a distribution that hides boot messages, users notice nothing unless they read the startup logs. In a distribution that displays boot messages, they may notice a message that free firmware is missing for a peripheral device. This message, however, does not necessarily mean that the device is unsupported – it may just that the free driver will be loaded later in the boot process. Alternatively, “the few Linux drivers that still have blobs disguised as source code will silently refrain from uploading the blobs to the peripheral.”

Additionally, Oliva says, “a number of devices will operate even in the absence of a firmware upload, but others will be rendered non-functional by the absence of firmware.” These cases may be annoying, but he argues that this situation may not be an altogether bad thing, pointing out that “if the device is not operational, it probably won’t control or spy on the user.”

The Reason for It All

This basic process has worked well for several years. All the same, Oliva mentions several problems or possible improvements.

For instance, Oliva suggests that the blocking of the loading of blobs is not a feature of Linux-libre kernels so much as “a bug that’s quite difficult to fix.” He suggests that it interferes with user’s ability to decide whether or not to load the firmware. Also, when a blob becomes a free driver – as happened with the ath6k htc driver for Atheros wireless cards – users have to wait for a revised free kernel before they can use the newly free driver. He is currently considering a revision of the debugging scripts that allows users to make their own choices about whether to load firmware blobs.

Oliva would also like to create a Git repository with a complete history in which each commit corresponds to a commit in the Linux kernel itself. With this arrangement, “git users using the free repository could cooperate with those whose trees are blob-ridden, performing merges and cherry-picking patches in a way that doesn’t require either party to carry both entire revision histories.” However, he adds that, “It’s not yet clear what infrastructure needs to be added to Git, if any, to make this sort of interoperation possible.”

However, even without such improvements, Oliva remains convinced of the importance of Linux-libre’s work.

“I’ve often heard arguments along the lines that there’s a need to compromise on freedom at times to gain critical mass and change the game,” he says. “[But] if the incompatibility between specific pieces of hardware and a user’s freedom is hidden from the user, if popular distros mislead users into believing blob-ridden repositories contain only free software, and if knowledgeable developers refer to the whole system by the name of a kernel where the blobs aren’t even regarded as a problem, what hope is there that users will learn about the problem and take a stand for freedom?”

Oliva has a point, but at least with the inroads that Linux-libre has made in the few years of its existence, there is a possibility that users – or at least the makers of distributions – can educate themselves about the issues and make informed choices.