September 23, 2014
 
 
RSSRSS feed

What Will It Take To Have A Truly Free Kernel?

GNewSense Shines a Bright Light on Blobs

  • December 5, 2008
  • By Bruce Byfield

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.

Sitemap | Contact Us