Leading items

Resolved: firmware is not software

On July 17, the Debian release team posted an update on the upcoming "etch" distribution. Things appeared to be moving along nicely. Many of the important transitions have been made, the kernel was set to be frozen on July 30, and the final release (to be numbered 4.0) was on track to happen, as scheduled, on December 4 of this year. It all looks like the smoothest release process Debian has had in quite some time.

For experienced Debian watchers, this seems too good to be true. And, in fact, that's exactly what it might be; behind the scenes, it looks like the etch release may get caught up on an old problem. On August 3, Debian developer Nathanael Nerode claimed that the etch timeline is unrealistic because the kernel will not be ready in time. The issue, in particular, is that of device firmware.

Some background: most devices attached to a modern systems are special-purpose computers in their own right, running their own software. Some of these devices store that software ("firmware") in a ROM within the device itself. Over the years, however, manufacturers have found that loading the firmware from the host system is both cheaper and more flexible. As a result, much current hardware is unable to function in any useful way until the host computer has fed it the requisite firmware. This firmware load is handled by the device driver.

Once upon a time, a great many drivers had the necessary firmware linked into the kernel itself. In many cases, over time, that firmware has been stripped out into a separate file which can be fed to the kernel at device initialization time. In others, however, the firmware remains in the kernel itself. Often, that firmware carries explicit permission which allows it to be distributed in that way, so licensing issues do not usually come into the picture.

The Debian Project, however, is not satisfied with distributable firmware - or, at least, many vocal Debian developers are not satisfied. Unless there is accompanying source which can be used to rebuild that firmware, said firmware is not seen to be truly free, and, thus, has no part in Debian. According to this point of view, it is not possible to ship a kernel which is compliant with the Debian Free Software Guidelines (DFSG) until all of that firmware has been torn out of it. Since this work has not been done - the Debian kernel maintainers being more concerned with the production of a working and secure kernel - the kernel cannot be frozen, and the etch timeline cannot be met.

There is another point of view within the project however. According to this perspective, Debian is shipping an operating system for the host CPU, not for all of the peripherals attached to that CPU. As long as the core operating system is free, that is good enough. The peripheral devices will, regardless of anything Debian does, be running non-free software. Adopting a policy which favors devices having their proprietary software in ROM (where it can never, ever be changed) over those which accept their firmware from the host (where, maybe, someday it could be rebuilt and tinkered with) seems like a step in the wrong direction. To people who see things this way, trying to purge non-free firmware distracts developers from more useful work while simultaneously making things harder for Debian's users.

This is, to put it mildly, not a particularly new discussion. Despite having come around many times over the years, however, this question has never really been resolved. In an effort to bring it to a resolution this time around, Steve Langasek has proposed a general resolution stating, in essence, that Debian can ship "data" without the need for accompanying source. Data, in this sense, includes things like graphics (splash screens, icons, etc.), videos, and fonts. If this resolution is voted on and passes, the position taken by the project will be that, as long as the "data" itself is freely distributable, the project can ship it without source and remain true to its goals.

The final part of the proposed resolution takes things one step further by stating explicitly that firmware is, for the purposes of the DFSG's source requirements, not a program. Device firmware is, instead, data which, under the terms of the resolution, can be shipped without source.

Needless to say, this proposal has inspired some discussion. Many developers are in favor of the proposal, and have seconded it. Others have requested that it be split into two parts, with the firmware-as-data issue being voted upon separately. Some remain firmly opposed to shipping anything without source; these people do not like the resolution at all.

Then, there is the position taken by Sven Luther, a member of the Debian kernel team. Sven states that calling firmware "data" is fundamentally dishonest, and that this fiction will inevitably lead Debian toward becoming a non-free distribution. What he would like to see, instead, is a resolution that, while firmware remains a problem, it is one which has been with Debian for a long time and which is not going to be solved within the etch release schedule. So, Sven proposes:

Sven will likely format this proposal into a competing resolution for a vote by the developers.

What this alternative resolution really looks like, of course, is yet another decision to defer the issue and argue about it again in the next release cycle. But this could be just how the decision goes in the end. Many developers have little patience with the firmware battles and with the push to break working drivers. There is also a real unease, however, with shipping binary firmware blobs, and simply rebranding those blobs as "data" may not be enough to make people feel better about it. So Debian may well punt the issue again; expect its return in a year or two.

Comments (41 posted)

Who maintains RPM?

RPM is an important piece of Linux infrastructure. It is the native package manager for a number of major distributions, including Red Hat's enterprise offerings, Fedora, and SUSE. The Linux Standard Base specification requires that all compliant systems offer RPM - even those which are built around a different package management system. If RPM does not work, the system is not generally manageable. So it may be a little surprising to learn that the current status and maintainership of RPM is unclear at best.

Once upon a time, RPM was the "Red Hat Package Manager." In a bid to establish RPM as a wider standard - and, perhaps, to get some development help - Red Hat tried to turn RPM into a community project - rebranding it as the "RPM Package Manager" in the process. But core RPM development remained at Red Hat, under the care of an employee named Jeff Johnson. That, it would seem, is where the trouble starts.

Back in early 2004, an RPM bug report was filed. The reporting user had made a little mistake, in that he had tried to install a package on a system where /usr was mounted read-only. Needless to say, this operation did not work as intended - an outcome which the bug reporter could live with. This person, however, did think that it might have been better if RPM had not corrupted its internal database in the process of failing. He suggested that RPM should keep its internal records in order, even if the system administrator has requested something which cannot be done.

The ensuing conversation - lasting for over two years - deserves to become a textbook example in how not to respond to bug reports. Mr. Johnson took the position that, since RPM was being asked to do something erroneous, its subsequent mangling of the package database was not a bug. Instead, it seems, this behavior should be seen as an appropriate consequence for having done something stupid. Mr. Johnson repeatedly closed the bug, stating his refusal to fix it. Numerous other participants in the discussion made it clear that they disagreed with this "resolution" of the bug, but nothing, it seemed, could convince the RPM maintainer to put in a fix.

In February, 2006 - almost two years after the bug report had been entered - Mr. Johnson posted a one-line comment to the effect that read-only mounts were properly detected in RPM-4.4.5. This might seem like the end of the story, except for one little problem: Fedora currently ships version 4.4.2, and even the Fedora development repository has not gone beyond that. SUSE remains at 4.4.2, and the current RHEL offerings have rather older versions. Mr. Johnson has continued to make RPM releases, but the distributors are not picking them up. They are, instead, shipping an older version of this crucial tool, augmented with a rather hefty list of patches.

Part of what is happening here is that Mr. Johnson is no longer a Red Hat employee, having been encouraged to pursue other opportunities. He does, however, continue to show up on the Red Hat bug tracker when RPM issues are being discussed; as a current example shows, he does not appear to have adopted a friendlier attitude toward RPM users (or his former employer) over time. There has been talk on the mailing lists about removing his access to the bugzilla database - an action which may have occurred by now.

Red Hat's Greg DeKoenigsberg, who has responsibility for the company's relations with the development community has stood up and pointed out, however, that simply silencing one difficult personality will not address the real problem:

So, when Jeff Johnson walked out the door at Red Hat, he took RPM with him. Since then, few distributors have wanted to use his releases, but no other organized project around RPM has come into existence. For the purposes of the people using distributions from Red Hat and SUSE, RPM is essentially unmaintained.

There has been no clear message to users about the state of RPM. Some Fedora users have asked, via yet another bugzilla entry, for an update to Jeff Johnson's current release, but nobody has posted a definitive reason as to why that will not happen. But it does appear that there is no interest within Fedora to depend on Mr. Johnson for anything, much less an important piece of infrastructure, so Fedora appears unlikely to move to the newer releases.

What Greg DeKoenigsberg has said - backed up by Michael Tiemann - is that the time has come for Fedora and Red Hat to own up to what has happened and formalize the new status of RPM. The current situation, where RPM has been forked but nobody is saying so, will not lead to anything good in the long run. The new RPM - perhaps the "Red Hat Package Manager" yet again - needs to have its existence acknowledged and its maintainership made clear. Either that, or Red Hat and Fedora should acknowledge the current RPM maintainer and move toward rejoining with his version of the code. Until one of those things happen, there will continue to be a dark cloud of uncertainty surrounding a tool which is heavily depended upon by vast numbers of Linux users.

(See also: the the Fedora rpm-devel wiki page, which lists features found in the current RPM release but not in Fedora's version).

Comments (63 posted)

What is a Linux laptop?

Recently, Lenovo announced that it would be supporting Linux on one of its Thinkpad laptop models. This announcement was seen as a big turnaround, given that the company had said, only a few months ago, that it was no longer interested in Linux. Since Thinkpads tend to be relatively nice machines, and since support for Linux among laptop manufacturers tends to be nonexistent, Lenovo's announcement looks like good news. It is not, however, as good as many in the community might have hoped.

Your editor had a brief conversation with Lenovo, and was able to confirm the news that came out of LinuxWorld: Lenovo's "Linux-supported" laptop does not, in fact, come with Linux installed. This machine is shipped with a blank disk and a note instructing the purchaser to go buy a copy of SUSE Linux Enterprise Desktop 10 and install it him- or herself. The only real differences with this offering are that (1) the proud owner has some reasonable assurance that the installation will actually work - a valuable thing - and (2) there is no Windows certificate to throw away.

The other surprise is that this machine features the ATI "Mobility FireGL V5200" video adapter. This adapter is, by all accounts, a nice piece of hardware, but it lacks a free driver. The associated ThinkWiki page goes into what must be done to get this card working properly on a Linux system; it involves installing ATI's proprietary driver. So people who have bought this "Linux supported" system are not, in the end, running free software.

Doubtless there will be customers who are happy with this deal - though Lenovo's pricing does not seem particularly attractive. But this offering raises an important question: what does it really mean for a vendor or a computer to "support Linux"? How can customers for such systems know whether they are getting a truly free system, or, instead, one which forces the use of proprietary software?

Somehow, we need to get a handle on the claim of "supporting Linux" and make the distinction between free and proprietary systems clear. Without this transparency, there will be little incentive for manufacturers to create truly free systems. An independent body which could certify 100% free Linux systems would be ideal, but this body does not currently exist and it is not clear who could credibly take on that task. In its absence, all we can do is to insist that systems vendors be clear about just what they are selling.

Comments (38 posted)