Given that the Linux kernel contains proprietary firmware blobs, determining whether a GNU/Linux distribution is actually free has gotten far less clear.
Knowing when a GNU/Linux distribution is free used to be simple. If all its software had licenses approved by the Free Software Foundation (FSF) or the Open Source Initiative, then a distribution was free. Otherwise, it wasn't.
However, the release of the GNewSense distribution a few years ago has complicated the situation, pitting idealists against pragmatists and sending some distributions scrambling for a compromise that is unlikely to satisfy anyone.
The GNewSense team was the first to point out that the Linux kernel contained proprietary firmware blobs, and that many kernel drivers depended on external proprietary blobs, and has dedicated itself to producing an operating system with all this material removed.
As a result, the FSF has changed the definition of a free distribution, and a search for how to respond to this new definition is now well underway. Who wins and what solutions are implemented could have a major effect on the future of free and open source software.
The core of the debate
In some distros, people have advocated a kernel that meets the new definition, perhaps using Alexandre Oliva's linux-libre kernel. In some cases, these free kernels are being made available from non-official sources, such as Ali Gunduz's free kernels for Debian-based distributions. These solutions are supported by free software advocates, who see such efforts as a logical extension of basic definitions of software freedom.
However, others actively resist such solutions. Fedora Leader Paul Frields says, "Fedora's position on firmware is that firmware is something that you can't consider in the same case as the code that is running on a CPU. We don't find that a compelling argument for considering those things in the same way." A similar position was expressed on the debian-devel list earlier this month by developer Loic Minier, who suggests that, since the firmware is required for peripherals rather than for the CPU itself, it ought to fall into a separate category in discussions of freedom. Unsurprisingly, such claims are dismissed by free software advocates as meaningless hair-splitting.
A more logically consistent argument against a kernel that meets the new definition of freedom is that removing proprietary firmware would leave GNU/Linux considerably weaker, especially in support for wireless cards and webcams. Kernel developer David Woodhouse describes such solutions as "bizarre" and its supporters as "fanatics," adding that, in discussions in the Fedora Project, "There was, understandably, a lot of resistance to the idea of just shipping a partially-disabled kernel."
In other words, the issue reveals the usual polarizations in the community between free software supporters, who value freedom above anything else, and open source advocates, for whom the issue is software quality and user convenience. The debate has often become heated, but several distributions -- among them Debian, Fedora, and Ubuntu -- are now looking for solutions that will satisfy both sides.
Looking for solutions
One of the more interesting approaches to the problem has been unfolding for the last couple of months on the debian-devel list. The Debian distribution has always supported both software freedom and user convenience by dividing packages by repositories: Those that are free go into the main repository, those that are free but depend on other proprietary software go into contrib, and proprietary software into non-free.
With this arrangement, those who want a free system can easily obtain it by only enabling the main repository in their list of software sources, while others can enable contrib and non-free. Recent discussion has centered on where to put proprietary firmware -- either in contrib or non-free, or in a new category. Alternatively, the definition of what qualifies for the main repository might be changed to allow the firmware to be placed there. The Debian developers are now slowly moving towards a general resolution to decide how to handle the situation, although discussion seems bogged down about what solutions and approaches to include on the ballot and how each should be worded.
Continued: Ubuntu and Fedora's approach
By contrast, Ubuntu and Fedora are taking another approach. In their latest releases, they have moved the offending firmware into a separate software package. These packages are installed by default with each kernel, but can removed by those with moderate expertise in each distribution's package tools. Ubuntu even has an install option for not including the package, although the option was broken in the first version of its latest release, causing the installer to include the package regardless of what choice was made.
According to Woodhouse, such solutions are in keeping with the modern kernel practice of removing firmware from the kernel. New drivers already follow this practice, and old ones are being rewritten to follow it in what he calls largely routine "janitorial work to bring drivers up to date with how we do things these days."
"There are plenty of technical reasons why it's better to do that," Woodhouse says. "It's much easier to change firmware and experiment with it, and it avoids taking up unswappable kernel memory for something which is only required occasionally."
The process is not yet complete, but Woodhouse estimates that it should be done for the release of the 2.6.29 kernel -- in other words, within 3-6 months, given the usual pace of kernel development.
This solution, he says, has several advantages. It avoids the problem of including with the kernel, which is released under the second version of the GNU General Public License (GPL), firmware that is incompatible with the license. In addition, it satisfies companies who are worried that including their drivers in a GPL work like the kernel might oblige them to offer their source code.
Most important of all, the arrangement simplifies the maintenance issues of satisfying free software advocates. "They're using the same kernel build as the rest of us, and the support and the installer issues don't make us all want to curl up under the table and cry."
There is, of course the other solution of following distributions like GNewSense and Blag and shipping a free kernel, either on its own or as an alternative. However, the process of making this switch is time-consuming, and, with open source supporters not seeing much reason to make the effort, large, well-established distributions are unlikely to consider it for long. Under these circumstances, the compromise of removing the firmware to a separate software package is likely to be the preferred course for most distributions, especially since it is happening anyway.
Objections to the separate package
But, like most compromises, having a separate package for the firmware is unlikely to satisfy everyone. Oliva, who campaigned hard for a free kernel in Fedora, notes that many firmware blobs remain in the latest Linux kernel, a fact he can verify because of the scripts he wrote for the linux-libre project to remove them. However, if Woodhouse is correct, these blobs should be removed soon. And, at any rate, the FSF definition of a free distribution does not insist on complete compliance with itself -- only good faith efforts to comply.
More seriously, Oliva points out that, in Fedora, installing a new kernel will automatically add the firmware package as well, requiring you to remove it with each kernel upgrade. In other words, the default is still a non-free system, which contradicts Fedora's claim that it ships only free software.
However, Oliva does concede that, were Debian to move all blobs to its non-free repository, that "would be an actual step forward." At least by using only the main repository, users could be assured that they had a completely free system.
Continued: Richard Stallman's view
Yet, as Richard Stallman, FSF founder and president, points out, including proprietary firmware at all is a violation of the GPL.
In fact, he points out that, "Strictly speaking, redistribution [of the standard kernel] violates the GPL. However, he points out that, in practice, "that violation has no effect: the copyright holders of Linux do not enforce the GPL against those who redistribute Linux with blobs, and might be unable to do so successfully after having themselves approved the inclusion of the blobs."
Still, in Stallman's view, having separate firmware package "does nothing to address the ethical problem of their presence in the GNU/Linux distribution or their installation in your machine."
For Stallman, the situation "is an example of how those who do not value freedom highly tend to lose it." In his view, by not guarding against proprietary intrusions into the kernel or its drivers, open source supporters are betraying the promise of the licenses they use and the communities of which they are a part.
Such objections are unlikely to sway those who do not already hold free software views. Perhaps the arguments that would be most convincing to Oliva and Stallman's opposition are the practical ones that Oliva makes in passing -- finding all these solutions, Oliva points out, is a lot more work than shipping a linux-libre kernel.
He adds, "I really can't figure out why distros want so badly to undertake part of the costs of maintaining and distributing the firmware, costs that the hardware vendors are dumping on the community." In comparison, those on the open source side have yet to suggest an ideal reason why free software supporters should support shipping the blobs or the attempted compromise.
Still, in the end, neither side is likely to convince the other, because they are arguing from irreconcilable starting points. The compromise of a separate firmware package may continue for other reasons, but it is unlikely to stop the debate. Those who want to remove all proprietary elements are probably a minority, but they are a large minority, articulate and committed, and unlikely to abandon the idea of reshaping the distributions in which they are involved to fit their ideals.
And while you might wonder at the energy going into the debate, especially if you are not a developer, one thing is clear: The debate over firmware is still some ways from being settled.