Leading items

How many Fedora users are there?

The Fedora Core 6 distribution is nearing release. Even after the recently announced delay, the final version of FC6 is expected to hit the net on October 17. So one would assume that there would be little call for controversial changes at this time in the cycle; the Fedora folks would be expected to be concerned with fixing the final problems and getting the release out the door. So the documentation group was a little surprised, at the end of September, when a request to modify the Firefox startup page showed up.

In particular, the Fedora leadership wanted that page to include a tracking image - an image hosted on a Fedora web site which would allow the project to track how many people were starting up Fedora's version of Firefox, and which IP addresses they came from. It would appear that few people had any sense that there might be objections to this technique; the resulting discussion seemed to take them by surprise. But a discussion did result, focusing on a few questions: why does Fedora want to track its users, why the hurry to get this change into FC6, and isn't there a better way?

At the moment, it seems, the Fedora Project has very little idea of how widely used their work is. That is an ignorance they share with a great many free software projects, but Fedora's situation, it seems, has the potential to make that ignorance expensive. The best description of Fedora's motives came from Greg DeKoenigsberg; it is worth quoting at length:

Fedora has, slowly over the years, become a more open and transparent free software project. It is also clearly a successful project, with a large (if unknown) number of users worldwide. But the fact remains that Fedora is a Red Hat project, with Red Hat being the source of almost all of the funding that keeps Fedora going. This funding is a generous gift from Red Hat to the community (though Red Hat certainly benefits from it as well), but it puts Fedora into a strongly dependent position. Fedora must keep Red Hat happy, and convince Red Hat of its importance, if it is to continue to be funded properly.

According to Max Spevack, there is no concern about Fedora funding being cut; this exercise is, instead, about getting that funding increased. But the evident level of concern belies that claim somewhat. Even if there is no discussion of cutting Fedora funding now, it seems like a subject which could come up in the future. Red Hat is becoming just another company in many ways, and it will make the calculations that companies need to make to survive. It would not take too many bad quarters for Red Hat to start looking very hard at the money spent on Fedora; managers under pressure to improve their numbers can be very short-sighted at times. So it makes sense for the Fedora project to be concerned about its ongoing relationship with Red Hat.

It almost seems that something must have happened to reinforce this idea in the minds of the Fedora leadership. If so, they aren't talking about it. But they have decided that it is important to get some sort of mechanism into FC6 which would give them at least rudimentary statistics. Waiting another cycle for FC7, it seems is not an option. Given the short time available to put anything into FC6, the Fedora folks settled quickly on something which would be easy to implement: a tracking image.

There are obvious problems with the tracking image idea, starting with the privacy concerns. Not everybody wants to be tracked in this way. People with this sort of concern may also not be much comforted by the Fedora privacy policy page, which leads off with this text:

Beyond that, it has been pointed out that this technique only yields IP addresses, which will only be correlated with the number of actual installations in a very rough manner. But that information, it seems, is much better than nothing.

There are alternatives. One idea which has been discussed is a brief user survey which shows up at the end of the installation process. Users could then provide some information - or, crucially, choose not to. Nobody seems to think that such a mechanism could be added to FC6 at this late date, however; though it could show up in FC7.

The Fedora folks could also take advantage of the fact that a new Fedora installation already phones home. It is all for the best of purposes: the yum-updatesd daemon, which runs by default, goes to the central Fedora server to download the lists of repository mirrors. The project has not been using the tracks that this activity leaves - but they could. Greg describes it as "an absolute no-brainer":

This approach is not perfect either. It fails on systems which are offline, while every system running Firefox has a high probability of being connected. It also cannot distinguish systems which are likely to be "desktop" systems - information which is apparently of interest. But it's there now and, as Greg points out, it doesn't seem to set off alarms the way a tracking image would. Hopefully Fedora will share the conclusions it draws from this data - and make good use of it to convince Red Hat management of the project's importance.

Comments (84 posted)

Device drivers and non-disclosure agreements

Anybody who has been working with free software for any period of time knows that hardware support is often one of the community's thorniest problems. Manufacturers are often reluctant to tell their customers how to actually use the hardware they sell. For some strange reason, people buy that hardware anyway, and promptly want it to work with their operating system of choice. If that system is Windows, the manufacturer will usually provide a driver (of uncertain quality). Free software users, instead, are usually on their own.

The situation is better now than it often has been in the past; free operating systems support a wide variety of hardware. In many cases, the vendors have given in and simply released programming information required for anybody to write a driver. In many others, however, this information is provided to a specific company or developer under a non-disclosure agreement (NDA), with the understanding that the resulting driver would then be released under a free license. This approach has, beyond a doubt, made more drivers available for use with our systems; it has become a common way of doing things, especially in the Linux world.

Not everybody is happy with this state of affairs, however. OpenBSD founder Theo de Raadt has started a campaign against the practice of writing drivers under NDA; in the process, he has stepped on, if anything, more than the usual number of toes, to the point that some of the people involved are now refusing to talk to him. Theo's tactics are never subtle, but he does have a point which is worth listening to.

At a first glance, a driver developed under NDA seems like a good thing. It is free software, after all, and it makes the device work under the target operating system. But these drivers can be problematic for the simple reason that they do not document the hardware the way the specification does. Without that documentation, many of the benefits of free software are lost.

In many cases, only the original author can maintain a driver developed under NDA. Nobody else has the documentation required to make any real changes to how the driver operates; nobody else really understands the device. Whenever a new version of the hardware comes out, or whenever somebody needs a feature that the original author didn't see fit to implement, one can only hope that said author is still around and in a mood to work on that driver.

This situation can be worse yet if the author who signed the NDA writes poor quality code, full of constants whose meaning is clear to nobody. In some cases, the vendor may require that the driver be written in that way in order to expose as little information about the hardware as possible. It's worth noting that this is a problem associated with poor hardware documentation in general. Your editor recently had cause to dig into the OmniVision OV7x20 sensor driver. The data sheet for this device can be found by anybody with access to a search engine, but that data sheet is little help for anybody trying to understand this code:

    /* Settings for (color) OV7620 camera chip */
    static struct ovcamchip_regvals regvals_init_7620[] = {
	{ 0x12, 0x80 }, /* reset */
	{ 0x00, OV7620_DFL_GAIN },
	{ 0x01, 0x80 },
	{ 0x02, 0x80 },
	{ 0x03, OV7620_DFL_SAT },
	{ 0x06, OV7620_DFL_BRIGHT },
	{ 0x07, 0x00 },
	{ 0x0c, 0x24 },
	{ 0x0c, 0x24 },
	{ 0x0d, 0x24 },
	/* ... 45 lines of this stuff removed ... */
	{ 0x74, 0x00 },
	{ 0x75, 0x8e },
	{ 0x76, 0x00 },
	{ 0x77, 0xff },
	{ 0x78, 0x80 },
	{ 0x79, 0x80 },
	{ 0x7a, 0x80 },
	{ 0x7b, 0xe2 },
	{ 0x7c, 0x00 },
	{ 0xff, 0xff },	/* END MARKER */
    };

It's not clear that anybody really knows what all those register settings do; they involve a number of bits and registers which are marked "reserved" in the documentation. For all practical purposes, they constitute a form of opaque firmware which must be loaded into the device for it to operate correctly. Pain will come to anyone who attempts anything more than the most trivial tweaks to these values.

Similar issues (in an entirely different context) recently led Linus Torvalds to exclaim:

Without complete hardware documentation, we will not understand what our peripherals are doing.

Finally, a big problem with drivers written under NDA is that they only work on one system, and they can be very little help for anybody trying to make the device work on a different kernel. That, of course, has a lot to do with why there is a lot of criticism of this approach coming from the BSD world while the Linux community tends to be more accepting of it. It is probably safe to say that most developers who are able to get this sort of access to documentation are working on Linux drivers. If we were pounding our heads against our monitors in an attempt to reverse-engineer hardware by way of obscure BSD drivers written under NDA, we might see the situation in a different light.

Theo has picked out two targets for special attention: Intel and the One Laptop Per Child (OLPC) project. Intel has gotten a fair amount of good press supporting its hardware under Linux. The truth of the matter, however, is that a number of drivers for Intel hardware are written in-house, with little or no hardware documentation provided to the community. As long as Intel remains interested in maintaining those drivers, things will work well enough - for Linux users. BSD users are not so lucky, however, and we may all be out of luck if a change of management or focus at Intel causes the company to drop its Linux drivers. If Intel truly wants to be known as an open-source friendly company, it would do well to make its hardware truly open. The OpenBSD developers are currently running a campaign aimed at pushing Intel in that direction.

Disclosure time
Readers of this article should be aware that your editor is in the final stages of writing a GPL-licensed driver for the OLPC camera controller - and that he signed an NDA to obtain the requisite hardware documentation. As a result, he is, according to Theo de Raadt, "part of the problem."

In the OLPC case, Theo's criticism has been centered upon (but not limited to) the driver for the Marvell wireless networking chip. Some very special things are being done with wireless on the OLPC, with the result that it will be able to function as a mesh network router with the CPU powered down. Enabling this involves a lot of close work with the chipset manufacturer - and a driver written under NDA. There are other NDA-covered drivers on the OLPC as well.

Theo is unhappy that the OLPC will be, as he sees it, a closed system for OpenBSD. [Mr. de Raadt has taken exception to the previous sentence, consider it removed]. But Theo is even more unhappy because, in his view, the OLPC project has squandered an opportunity to use its economic power with the manufacturers to force the hardware documentation out into the open. This failure is not just a lost opportunity; to Theo it also sends a message to other vendors that they need not worry about releasing hardware documentation. So, he says, the OLPC folks have not only failed to do the best they could; they have also actively made things worse for the free software community as a whole.

The OLPC folks have several responses to this criticism. The arrangement they have now, they say, is the best they could achieve within their particular set of goals - which, it should be remembered, is the provision of economical computers to children worldwide. OLPC was not founded with the primary goal of helping the free software community, though, in fact, that has been the result of much of its work. OLPC developers make the point that this computer will be one of the most open systems built in many years. The BIOS is free software, as is the VSA microcode which implements x86 emulation on the Geode CPU. The system's SD controller was redesigned (by Marvell) for the express purpose of allowing a driver to be written for it without having to sign the SD Association's particularly unpleasant NDAs. Even the firmware blob which runs on the wireless processor is slated for replacement with free software - though that code does not exist at this point.

Meanwhile, work continues on getting the hardware documentation released. It should be remembered, however, that much of this hardware does not actually exist yet. It would be rare indeed for a manufacturer to openly release this sort of information for a product which is not yet generally available. OLPC's plan appears to be to continue to work with the vendors to get the documentation released as the hardware comes onto the market. Heavy-handed pressure tactics, they feel, would be counterproductive in the end.

The crux of the matter, thus, is this: if we accept that the community needs open hardware documentation to function as it should, what is the best way to get vendors to release that documentation? Some groups encourage ongoing engagement with these companies, with the intent of guiding them toward open source enlightenment. Under this line of thought, these companies will come to realize that the community will do great things with their hardware - growing the market - given the right information; they will see that it is in their economic interest to make the documentation available.

The contrary argument is that this approach has never worked well, that hardware companies will never be brought around in this way. What is required, instead, is an intransigent insistence that the documentation must be released from the outset, and a refusal to sign NDAs to get it. Only when the vendors see themselves locked out of the free software market entirely will they realize that their interest lies in openness, not secrecy. Until that time, there is no reason to cooperate with uncooperative vendors; the preferred approach, instead, would appear to be to attempt to shame them publicly.

There has been enough history of drivers written under NDA that it should be possible to come to some sort of conclusion as to which approach is more effective. The OpenBSD camp has arguably had some high-profile success with the public shame approach. Corporate conversions through quiet engagement tend to be more, say, quiet, however. Your editor would be most interested to hear about examples of companies changing their approach to hardware documentation as a result of working with free software developers under NDA. The question is not just academic: if we want to bring about an improvement in the hardware documentation situation, it behooves us to understand which tactics work best.

Comments (46 posted)

Iceweasel == madness and fundamentalism?

Steven J. Vaughan-Nichols is a mainstream technology reporter who has often shown a reasonably high level of clue regarding the free software community. A recent article, titled Open Source Madness!, shows where that clue ends, however. More to the point, it shows an area where the free software community is having a hard time making itself understood.

The article in question takes issue with the Debian project's plan to drop Firefox from etch (see this LWN article from September for more information), and with the existence of Gnuzilla and Iceweasel, which are versions of the Mozilla suite and Firefox browser which are intended to be truly freely redistributable. Mr. Vaughan-Nichols presents the issue as being only about logos, calls the Debian developers "fundamentalists," and states:

So why is it that the Debian developers have done this terrible thing? Maybe it is time to look at the reasoning behind this move.

The logo issue is real. It is provided under terms which are not compatible with the Debian Free Software Guidelines, and, as a result, cannot be shipped with the core Debian release. For some time, Debian was able to ship a version of Firefox without the logo, but Mozilla Corporation has called an end to that. As a result, Debian is in the position of being asked to ship something it sees as non-free.

The logo issue might be enough to push Firefox out of a distribution like Debian, but there are more serious issues as well. The Mozilla trademark policy only allows a distributor to ship "Firefox" if it is an unmodified copy of what the Mozilla people have released. Some relatively trivial changes are allowed if the distributor calls the result the "Firefox Community Edition"; anything beyond that cannot use the name "Firefox" at all. The only exception is if explicit permission has been obtained from the Mozilla Corporation prior to distribution.

Distributors often do want to make changes to Firefox - just like they change many other programs they ship. At a minimum, they often want to apply their own security fixes, since Mozilla's approach to security patches tends to be rather distributor-hostile. Having Mozilla review every patch as required will slow the process down, even if there are no disagreements about specific changes. This policy makes it hard to provide quick security updates to Firefox; this matters, especially, when a distributor is trying to maintain a version of the browser that Mozilla Corp. has long since abandoned.

Perhaps most important, however, is this: even if a distributor gets permission to ship a specific modified version of Firefox, there is nothing which automatically gives anybody else that permission. Using one distribution as a base for another is a time-honored practice in the Linux community; there are, in fact, very few distributions out there which were truly started from scratch. But what is a distribution based on (say) Debian to do with a modified version of Firefox? The creator of the derived distribution has no permission from Mozilla Corporation to distribute that modified version - even if no further changes are made. The presence of this modified package creates a trap which any second-stage distributor must find and defuse; it makes the distribution less redistributable, less free.

In the end, however, Mozilla's code is free software; all that is needed to avoid all of this trouble is to change its name. That is just what Debian is doing - and other distributors may yet follow suit.

Mr. Vaughan-Nichols fears that this change will confuse users and send them screaming back to the comfort and stability of Windows. It would seem that the "Firefox" trademark has become so important that we must use it, or the dream of World Domination on the desktop will come to an untimely and ignominious end. "Freedom," says the article, "trumps common sense."

The problems is...freedom is what this is all about. There would appear to be an increasing number of people who are calling for the community to "bend a little" on freedom in the name of winning the desktop battle. It may (or may not) be true that Linux could advance more quickly on the desktop if it were to become more like Windows. But what would be the point? If the choice is forced upon us, it would seem better to dispense with an overly-controlled name and keep our desktop free, supportable, and redistributable.

Comments (21 posted)

Page editor: Jonathan Corbet
Next page: Security>>