LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
Recent Features
| |||||||||||||
LWN.net Weekly Edition for June 8, 2006Behavioral standards in the free software communityThe 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:
The difference in values between Ted and the rest of our project
was just too immense. When I was walking out of the room at around
7 in the morning next day my final sentence was "Ted, even if you
spend rest of the Debconf apologizing and making friends, I do not
see a future for you in this project." and the most important was
that Ted and John seemed to agree with me on that
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:
I'd be wary of pursuing just the "women in GNOME" issue, because
many of the same things put off far more than just women. Running
around shouting "pants off" is not, for example, very compatible
with the Japanese cultural expectations.
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:
What X has done is among the most low-class, unprofessional,
and tactless things I have ever experienced in my professional
career.... Bottom line, in my opinion, is that what X did
is unacceptable on its face and he deserves to be held accountable
for it. So he's out.
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.
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:
I disagree there (not speaking for any company just for myself
here): the "clean room" thing is ONLY a USA thing, and is not even
required in the USA. It is a "we want to be extra safe in the USA"
thing only.
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.
The UK Parliament on DRMThe 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.
In the future it must be expected that TPMs [technical protection
measures] will rely more and more
upon specialist hardware functionality and that some systems will
prove to be extremely complex to overcome and to develop generic
evasion technology for. It would therefore be unwise to base public
policy upon a continuation of the situation that TPMs are
relatively easy to overcome. It may well be that propping up
technical measures with legislation will become entirely
irrelevant. Equally, assuming that egregious problems caused by
TPMs can be addressed by just `breaking into the system' may become
unrealistic. (¶ 21).
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:
Copyright is generally understood to be a trade-off. The creator of
copyright material is given a monopoly on exploiting it for a
period of time. Currently for a new song or book this is until the
creator dies plus 70 years. At the end of this period, the created
work enters the public domain and may be exploited by anyone. This
scheme is intended to ensure that there are incentives for
creators, without creating an indefinite monopoly....
However, should all available versions of the material be protected by highly effective TPM systems, it may prove impossible, when the copyright expires, for the exploitation to occur because the material will remain inaccessible except via the monopolistic TPM system. (¶ 32-4). 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:
From a completely different perspective, Intel told us that it was
important that the legal infrastructure does not inhibit technical
innovation and they feel that the `trade-off' should address
this as well! As an example, they pointed out that there were no
portable video jukeboxes on the market just devices capable of
video downloads or playing consumer recordings because it was
against the DVD consortium rules to create a portable device.
(¶ 49).
Alternative licenses from the Creative Commons and elsewhere are touched upon:
Several of the rights-holders were rather negative about these
licenses, suggesting that the creators and performers did not
always understand what they were "giving away forever" and how it
could affect an artist's ability to enter into an exclusive license
at a later stage in their career. Although artists should naturally
consider these matters, we suspect that these licenses are clearer
than many media industry contracts. (¶ 71).
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:
Because, as we have observed, consumers expect to copy CDs, we
believe that all CDs should in future come with a prominent label
saying, "you are not permitted to make any copies of this CD for
any reason"... The prominent label should add, when appropriate,
"and if you try to make a copy, you should note that we have tried
very hard to ensure that you will fail". Doubtless, even clearer
and more accurate wording is possible....
For some types of content the labelling will need to warn the user, "you cannot access some parts of this DVD without a working Internet connection to enable us to record your identity", or "your playing of this song may be recorded in marketing databases in foreign countries". (¶ 100-102). 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:
[W]e recommend that OFCOM publish guidance to make it clear that
companies distributing TPM systems in the UK would, if they have
features such as those in Sony-BMG's MediaMax and XCP systems, run
a significant risk of being prosecuted for criminal actions.
(¶ 118).
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.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||