The GNOME community has recently started a
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
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
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,
Alan Cox points out that the issue is a
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
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.
Comments (31 posted)
The discussion on what features should be merged into the 2.6.18 kernel has
begun (see this week's Kernel
for the details). One item which was mentioned is the acx100 driver
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
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
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"
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
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 All Party Parliamentary Internet
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
[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
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.
Alternative licenses from the Creative Commons and elsewhere are touched
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.
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
Inside this week's LWN.net Weekly Edition
- Security: Firefox and Thunderbird security releases; New vulnerabilities in evolution, mysql, spamassassin, ...
- Kernel: What's not going into 2.6.18; Putting a lid on USB power; SMPnice.
- Distributions: The ROCK Linux Mission Statement; 64-bit Xandros Server; Ubuntu 6.06 LTS; the "Dzongkha Linux launch"
- Development: The current state of the BusyBox project, lookahead at KOffice 2.0,
new versions of SQLite, LAT, Apache SpamAssassin, mnoGoSearch, Plone,
Grace, GNOME, GARNOME, KDE, Covered, XCircuit, OpenExposition, GIMP, Wine,
Firefox, Thunderbird, PHP libs.
- Press: OO.o virus debunked, State of Linux 2006, KDE 4 multimedia,
Red Hat Summit, Lenovo flip-flops on Linux, SanDisk and Rockbox, Red Hat
acquires JBoss, Death by DMCA, Denmark's resolution on open standards,
Ubuntu interviews, new grep features, Migrating to Open Source/Open Data Standards, suspending laptops, GNU Radio, OSDBC.
- Announcements: JBoss joins NetBeans program, Carrier Grade Debian, EFF on Web Privacy Ruling,
Linux Journal collecting timeline info, Linux Brochure Project 1.3.0, downloadable software patent book, Samba eXPerience materials,
Akademy CFP, Firebird Conf CFP, LinuxWorld UK, Java Distributor's License FAQ.