Bruce Byfield interviewed me about GNU Linux-libre to write an article for the [GNU/]Linux Pro magazine.

Give a little background about yourself and your work in free software.

I started getting involved with GNU back in 1991, initially as a user who occasionally reported and tried to fix bugs, and a couple of years later as a contributor and maintainer of various development tools, such as the autotools and GCC. It was the latter that got me a job at Red Hat in 2000, where I also got involved with binutils, glibc, and GDB.

I started giving speeches about Free Software philosophy that year, very much along the lines of Richard Stallman's speech that had changed my life in 1996, and a few years later I helped start FSF Latin America, a sister organization of the other Free Software Foundations.

There, besides the activism of writing articles, giving public speeches and running campaigns to promote these ideas, I maintain IRPF-Livre, a Free (as in Freedom) alternative to the proprietary program Brazilian taxpayers are required to use to fill in their tax returns, and GNU Linux-libre, a Free alternative to the kernel Linux.

I write kernel Linux, instead of Linux kernel, to avoid the ambiguity in English that leads some people to mistake the latter as “the kernel of the Linux project”, which makes little sense given that Linux names the kernel that Mr Torvalds has published since 1991.

Why is GNU Linux-libre needed? What parts of the kernel are non-free, and how did they get into the kernel in the first place?

We need GNU Linux-libre to be able to offer people who want to run Linux under the GNU operating system a way to do so without giving up their software freedom, that is, control over their computations and digital lives. It's the same reasoning that led to the development of a Free operating system to begin with.

When Linux was first published, in 1991, it was not Free Software: its license did not permit commercial distribution. In 1992, it was relicensed under the GNU GPL, and it remained Free until 1996 or so, when the first blob was added to its source code base.

A blob is a piece of non-Free object code, most often the program that runs on some peripheral's microprocessor to limit an arbitrarily programmable general purpose computer to the behaviors aligned with peripheral's manufacturer's (but not necesarily the users') business requirements. This limitation arises not from the code itself, but from the fact that the code is non-Free: as with every piece of non-Free Software, the user is controlled and subjugated by the manufacturer.

The first blobs in Linux were very small pieces of object code, disguised in the source code as arrays of characters, licensed under lax permissive Free Software licenses, but only available as object code, i.e., without corresponding source code, thus non-Free regardless of the license.

Once the gates were open, other blobs with various other 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, GPL-compatible except for the lack of source code, but they're no longer tiny: some are entire operating systems that run on peripherals, weighting more than early versions of Linux itself! There's one blob that wouldn't even fit in a 3.5" floppy disk of yore!

The reason these blobs got in there is that people in charge of Linux decided to accept them, instead of rejecting them for being an attack on users' control over their computers and on the Free Software community. Instead of pressuring hardware manufacturers to share with users the benefits of programmable hardware in peripherals, they sided with the manufacturers in keeping users divided and helpless.

How was the need for a free kernel discovered?

I don't know exactly how or when that happened, but I'm told that around 2005, Ututo, the first wholly Free GNU/Linux distro, was also the first in cleaning up their kernel, after somehow finding out there were blobs hidden in there. Not a long time after that, the first release of gNewSense was announced, also with a Free version of Linux, along with tools to help locate blobs in disguise in its source code.

Before that, I was as misled as most other users still are, into believing that Linux was Free Software. Or Open Source Software, as some of its developers put it, even though Linux isn't Open Source Software either.

Why is a separate project needed? Why isn't Linux-libre part of the main kernel project?

The problem for us is that the Linux project does not share the Free Software values: the top decision makers there do not agree that users deserve freedom in all 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 the developer holds over the user who falls in the trap.

I'm told there were early attempts to submit patches to fix, in certain Linux drivers, such problems as containing, recommending and requiring blobs. I'm told they were not only rejected, but disparaged, for they were not aligned with the directions the project wanted to go. I think it was at about that point that Jeff Moe, then the main developer of BLAG Linux and GNU, used gNewSense's scripts to clean up and publish a Free distribution of the kernel Linux dubbed Linux-libre, that he encouraged other Free GNU/Linux distros to adopt.

A few years later, when I had already started maintaining Linux-libre myself, Linux started moving most firmware to separate files, some still within its own “source” tree, others to a separate repository. Although this may have addressed some uncertainty as to whether the object code disguised as source code was compliant with the GPL, it does nothing to fix the problem that there is code in Linux that opposes the fundamental value of the Free Software community, recommending and often requiring users to give up their essential freedoms.

What has been the reception of the project? Which distributions use Linux-libre?

It didn't take long for all wholly Free distros to either use the cleaned-up tarballs we publish, or use our cleaning up scripts as a starting point to clean things up on their own or at least to verify that their own cleaning up infrastructure is not missing something.

http://www.gnu.org/distros/ lists the GNU/Linux distros recommended by the GNU project, that have vowed to and been verified to abide by the Free System Distribution Guidelines. Currently, the list names Ututo XS, gNewSense, BLAG, Dragora, dyne:bolic, Musix, Parabola, Trisquel and LibreWRT. GNU Guix also uses GNU Linux-libre. There are other distros that have vowed to respect users' software freedoms but that haven't been verified yet: Connochaetos, VegnuX NeonatoX and Kongoni come to mind.

As for the most popular distros, many of which mislead users into believing they are Free as in Freedom while they really aren't, volunteers give users the option of recovering their freedom without abandoning their favorite distro by making binary packages available; we have packages for Ubuntu and Fedora, and our web site links to third party packages for some other distros. http://linux-libre.fsfla.org/

I'm not entirely sure whether Replicant, the Free Android, has adopted GNU Linux-libre as its kernel or just done some deblobbing on Android's kernel, but I do know a friend of mine is working on a variant of Firefox OS that will ship with GNU Linux-libre. These are exciting times!

Can you give me some statistics about the project? How many people are involved? How many downloads and commits does it get per month?

Rolling out deblobbing scripts and source tarballs is something I do pretty much on my own, but there's a growing network of volunteers who hang out on the #linuxlibre channel on Freenode, some of which package binaries for users; Aurélien Desbrières, Jason Self, Juan Jacobo Nájera and myself are the ones who maintain the binary package repositories that are available out of our main site and mirrors.

I don't have the faintest clue as to the number of downloads and users: these are data points that are not relevant for the dimension in which I find the project important (I mean freedom), so I prefer to keep myself in the dark about them, so I don't run the risk of neither getting disappointed nor feeling too powerful

As for commits... There are various kinds of commits to count. The deblobbing scripts get few commits in our repository per quarter, most often when I adjust them for an upcoming major release. Our source releases, that generally come out a few hours after an upstream release does, contain all the commits that went in the corresponding upstream release, be it a major release published by Mr Torvalds, be it a stable/patch release published by the maintainers of the various stable branches. However, we don't publish a repository with the entire cleaned-up revision history yet, so the commits proper aren't visible from our side.

We also have one commit in our repositories for each build for gNewSense/yeeloong (the mips64el netbook manufactured by Lemote, that runs on Free Software even down to its BIOS!); with one build per major and stable release, that makes for 3-8 commits per week. And then, there are Freed-ora builds; that's a GNU Linux-libre distribution of kernel binaries that tracks the Fedora kernels, building corresponding kernels without the blobs or requests for blobs; that's another 3-12 commits per week, that the Fedora project rejected when I offered to maintain alternative Free kernels for them.

Can you describe the process of producing a free kernel? What steps are involved, and how long does the process take?

There are two different major steps to this end: updating deblobbing scripts, and running them to get a Free kernel in source form.

The updating takes place once per major release cycle: I take an -rc 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 to not 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.

After that, cleaning up any tarball or tree of the same vintage is as simple as running the appropriate script: deblob-3.11, for example, if run within a directory containing the exploded sources of any kernel in the 3.11.* series, will clean up all files that need cleaning up in that series. In order to clean up a tarball, you'd use deblob-main instead; to verify a tarball, or clean individual files, the script to use is the huge deblob-check, that the other scripts rely on as well.

Updating the scripts for a new major release often takes me about a full workday; the deblobbing of a source tree takes just a few minutes, far less than compressing the deblobbed tarball so as to publish it.

Can you describe the experience users of a free kernel are likely to have when a.) compiling and b.) using a free kernel?

The build process for GNU Linux-libre is no different from that of building any Linux variant Linux: having an exploded source tarball, you run any of the various options available to configure the kernel, build the kernel (and optionally the loadable modules), and install them.

As for using them, the differences will be more or less visible depending on the specific drivers that are activated.

Nowadays, most of the drivers that ask for blobs do so using the request_firmware kernel interface; while in Linux this may result in a request for the userland hotplug script to supply a blob with a given name (or, more recently, in the kernel's searching default firmware directories before or instead), when using GNU Linux-libre this request is blocked when the requested program is known to be a blob. Where Linux drivers will print an error message to the effect that the blob with that given name could not be found, GNU Linux-libre drivers are modified to report that Free firmware is missing for that device.

The few Linux drivers that still have blobs disguised as source code will silently refrain from uploading the blobs to the peripheral.

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. That's arguably a feature: if the device is not operational, it probably won't control or spy on the user. Actually, evil hardware designers could make it so that, without a firmware upload, the device will cease to perform its normal operations, but it will still abuse its privileged access to system memory and other peripherals to perform spying functions under the hood; call me naïve, but I hope this doesn't happen. I have nothing but hope to offer for this sort of concern.

Is there anything that the project wants to do that it can't do now? In general, what are the future plans for the project?

An item that's high in our wishlist is not requiring changes to the kernel code when a former blob becomes Free firmware in order to render the device operational; users had to wait for us to roll out revised source tarballs and binaries that didn't block the loading of the ath6k htc firmware when it became Free Software, and that waiting is not desirable. Of course, users could tweak the deblobbing scripts or manually revert their changes and then build a new kernel or just the reenabled driver, since that code is all Free Software, but that's a lot more effort than we could hope for.

Indeed, I became aware that some users have got the idea that blocking the loading of blobs is a feature. It's not; it's just a bug that's quite difficult to fix. The decision on whether or not to use a piece of software, be it Free or not, should belong to the users, and it's not our intent to make that difficult.

What we don't want to do is to bait users into a trap, so our plan to address both issues above is to reinstate the requests, but using some form of hashing on the blob name so that, if you chose to install it, it will be found (by the kernel itself, or by a suitably modified hotplug script), but if you don't, it won't lead you to the trap.

Another item in the wishlist is a git repository with the deblobbed history, with one commit corresponding to each upstream commit, so that we can maintain and publish a source repository that does not contain anything we wouldn't publish in any of our releases. We need to add some smarts to the deblobbing script to make that viable.

It would also be desirable to be able to mark each such commit as equivalent to an upstream commit, in a way that 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 didn't require either party to carry both entire revision histories. It's not yet clear what infrastructure needs to be added to git, if any, to make this sort of interoperation possible.

Is there anything else you would like to say about the project?

I find it very ironic that the mascot of a program that's neither Free nor Open Source came to be recognized worldwide as the icon for Open Source and Free Software. I wish more people would get to know about GNU, about how they deserve freedom and control over the software they use, and how important it is that we all join forces to restore freedom and avert worldwide spying and remote control of our computers. But for those who just love penguins, we have Freedo, a clean penguin

GNU has just turned 30 years old, but in spite of all our efforts, it often feels like many of the problems it was created to solve got worse, because most people aren't even aware of the problems that need fixing, and of what they can do to help fix it, even if they can't write a single line of code.

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, but the result of that has been the dilution of the whatever small power the Free Software community had among people who are told that blobs and other proprietary programs are not a problem, so how could we expect their help in fixing it? If the incompatibility between specific pieces of hardware and a users' 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?

The Free Software Movement started because RMS couldn't control a new peripheral as much as he did the older printer it replaced, because the code that controlled it was not Free! That's why he started GNU, and that's why I was very happy when Linux-libre was accepted as a GNU package a few years ago: I can now work on it without feeling like I'm competing with GNU, rather than helping advance it.

Edward Snowden's revelations about all the spying and remote controlling of computers by governments and corporations provided us, software freedom activists, with a great opportunity to bring software freedom issues into the public agenda, and it has been a point of growing concern even for non-hackers. Let's not miss it!