Leading items

Behavioral standards in the free software community

The GNOME community has recently started a discussion on the adoption of a code of conduct for community members. While a number of people clearly think that such a code makes sense, others are just as clearly uncomfortable with the idea. The free software community is traditionally an open and unregulated group. Its members are concerned with quality of contributions and inclusiveness; there is relatively little interest in conduct rules, and an active dislike for self-appointed enforcers and attempts to exclude potential contributors. So the number of projects with written behavioral codes is relatively small.

Such codes do exist, however, whether or not they are written down. Anybody who doubts this fact may want to ponder on the likely fate of a developer who attempts to contribute plagiarized code. But other standards clearly exist as well. Consider, for example, this case: a Debian developer was not only asked to leave DebConf last month, but was removed from the project altogether. A weblog entry from a nearby participant reads:

Only two months earlier, Debian went through a protracted debate on whether another developer should be forcibly expelled from the project. In both cases, the issue was not one of plagiarism or other crime; instead, these people are being pushed out for being jerks - for somebody's value of "jerk." Their behavior is said to be so unpleasant, and so off-putting for other members of the project, that their presence is no longer welcome. This is the sort of behavior that the proposed GNOME code of conduct seeks to regulate as well. This proposal contains items like "be respectful and considerate" and "don't be racist." Its supporters are trying to maintain a GNOME community which is pleasant to work in, and which does not drive potential contributors away.

They have a point: it has been noted, for example, that female participation in free software projects is often close to zero. That is, as some have observed, below the usual percentage of women in the general population; but it is also well below the percentage of women found working in technical fields. There is a whole population of potential contributors out there who have chosen not to be a part of the free software community. One very possible reason for their absence is the sort of behavior encountered on mailing lists, at conferences, and in other places where the community gathers. Perhaps, if standards of behavior were higher, more people would choose to participate.

(Then again, the problem could be elsewhere: Richard Stallman chimed in with a claim that the use of the term "open source" may be the real reason why women chose not to participate. This particular line of reasoning has not attracted a large following, however).

Alan Cox points out that the issue is a little broader:

One can, without great difficulty, make an argument that, as the free software community "grows up" and tries to expand beyond its "western white male geek" stereotype, it should look harder at how its members behave. If one contributor is sufficiently unpleasant to repel the participation of numerous others, then perhaps the community truly is better off without that person. So maybe the community truly does need to be prepared to expel people who are too difficult to be around. Codes of conduct might just make sense.

But consider an episode from just over three years ago, when a prominent developer (let's call him "X" for the moment) was stripped of his commit privileges and kicked out of an important project. One of the people involved in this action justified it with these words:

This looks like a clear application of a code of conduct; somebody behaves badly, and is booted from the project. Nothing to complain about. Except that X, in this case, was Keith Packard, who was busily trying to reform the XFree86 project. That project's decision to exclude Keith turned out to be fatal; XFree86 still exists - it even put out a release in May - but nobody cares anymore.

This episode highlights the dangers of behavioral codes. They can be used as a way of silencing people who have something inconvenient to say, but sometimes those people need to be heard. Codes of conduct can evolve into a sort of stifling "political correctness" where people become afraid to express their thoughts. The creation of such an environment will suck the life out of a project more quickly than any number of unpleasant people.

The community as a whole may well want to think about how people interact, and how that interaction can be made more pleasant and more globally inclusive. Behavior which is rude, sexist, racist, or worse runs counter to our values (one hopes), and it makes us weaker. So discussions of how we wish to treat each other and how we can avoid pushing away people who could make our community richer are worth having. But we must work toward that goal without silencing our more outspoken members; sometimes they are saying something we should hear, even if it makes us uncomfortable.

Comments (31 posted)

How clean must the room be?

The discussion on what features should be merged into the 2.6.18 kernel has begun (see this week's Kernel Page for the details). One item which was mentioned is the acx100 driver, which has been sitting in the -mm tree for some time. This driver works, is useful to a broad community of users, and appears to be entirely acceptable to the kernel developers who have reviewed it - except for one little problem.

This driver, it seems, was developed by reverse engineering a binary-only driver released by TI for the 2.4 kernels. Reverse engineering is not a problem in itself, as long as due care is taken to avoid copying any code from the non-free driver. The normal way of taking due care is to employ a "clean room" technique: the person who does the reverse engineering work writes a document describing how the hardware functions, but does not write any code. Instead, another developer, who has never looked at the original driver in any way, writes the new driver based on the information in the document. This approach shields the developers from any charges of copying code, since they have never seen the code in question.

The acx100 driver was not developed in this way; instead, the people who did the reverse engineering went on to implement the new driver directly. Nobody has alleged that these developers copied any code in this process. But the process they used opens the door to such charges in the future. So the code is seen as being tainted, even though it is probably entirely legitimate. This taint has been enough to keep the driver out of the kernel.

One kernel developer objects to this course of events, calling it excessive:

He goes on to say that, if the developers can certify that they copied no code, and especially if the work was done outside of the USA, the driver should be able to go into the mainline kernel.

Others disagree, however, noting that "being extra safe" is no bad thing. The SCO case has shown how disruptive a copyright-based challenge to the Linux code base can be. Linux has, by all appearances, come through that challenge looking even better than it did before; the kernel code truly is clean. What a shame it would be to merge code which ends up bringing on another lawyer storm and ruining the kernel's hard-won clean bill of health. Sad though it may be, leaving out the driver might be the better choice.

Still, there is a lingering issue here: which laws should be allowed to control which code is accepted into the kernel? By many accounts, the acx100 driver would pass muster in Europe; it is U.S. laws that are of concern. But the laws of, for example, Haiti, Egypt, and Georgia have not been consulted. Complying with laws across the entire planet would be a tall order. Conflicts with laws on, say, spectrum use, surveillance capabilities, or "piracy prevention" in various parts of the world seem increasingly likely. Steering a global operating system through this maze will be an interesting challenge.

Comments (14 posted)

The UK Parliament on DRM

The All Party Parliamentary Internet Group is an organization in the UK which "exists to provide a discussion forum between new media industries and Parliamentarians for the mutual benefit of both parties." It is open to members of the House of Commons and the House of Lords; its actual makeup (in terms of party representation and such) is not entirely clear. This group decided to have a hard look at the interaction of digital rights management (DRM) schemes and copyright law. To that end, they received written input from dozens of groups on all sides of the copyright dispute and listened to a large number of interested people. The result of all this work is a report [PDF] and a series of recommendations.

This group shows some signs of having actually understood the problem - or parts of it, at least. A reading of the full report is recommended for those who are interested in the issue. For everybody else, here is a set of select quotes.

To start with, the group does not buy the notion that DRM schemes will always be easily overcome.

So the "speed bump" view of DRM does not necessarily apply into the future.

Often, the discussion at the political level appears to have lost track of what copyright is for. So it is somewhat refreshing that this group has not forgotten entirely:

The report goes on, however, to dismiss this concern by claiming that "all available versions" of any given work are unlikely to go under DRM anytime soon. The authors may find themselves surprised by the ambitions of the entertainment industry.

At least some of the costs of DRM are understood:

Alternative licenses from the Creative Commons and elsewhere are touched upon:

The report's authors seem to believe that the worst DRM-related problems will be addressed in the market. But, they say, fully-informed consumers will help to bring that about:

There is also some discussion of what happens if a DRM-using vendor goes out of business or changes policies. The potential loss of an individual's media collection is raised, but the possibility that valuable material could be lost to society as a whole is not.

There is little patience with DRM code which ignores users' commands, hides itself, or endangers the host system:

The authors received input from a number of groups related to free software, but the bulk of that input appears to have been boiled down to about two sentences. The lack of free DVD players is mentioned, as is the effect of governmental DRM mandates. The report claims, however, that no DRM mandates are in view in Europe; evidently broadcast flags and anti-circumvention laws don't count. In general, the needs of the free software community were either not understood or not seen to be important.

So, in the end, the APIG report is not all that one might have hoped for. Still, this document shows a higher level of understanding of the issues than can be found in many other government venues. Let us hope that it is a sign of progress in the right direction.

Comments (7 posted)

Page editor: Jonathan Corbet
Next page: Security>>