Who controls glibc?


Welcome to LWN.net

The following subscription-only content has been made available to you
by an LWN subscriber. Thousands of subscribers depend on LWN for the
best news from the Linux and free software communities. If you enjoy this
article, please consider accepting the trial offer on the right. Thank you
for visiting LWN.net!

Free trial subscription

Try LWN for free for 1 month: no payment
or credit card required. Activate
your trial subscription now
and see why thousands of
readers subscribe to LWN.net.

By Jonathan Corbet
May 7, 2018

The removal of an old joke from the GNU C Library manual might not seem
like the sort of topic that would inspire a heated debate. At times,
though, a small action can serve as an inadvertent proxy for a more
significant question, one which is relevant to both the developers and the
users of the project. In this case, that question would be:
how is the project governed and who
makes decisions about which patches are applied?

Toward the end of April, Raymond Nicholson posted a patch to the glibc manual removing a joke
that he didn’t think was useful to readers. The joke played on the documentation
for abort()
to make a statement about US government policy on
providing information about abortions. As Nicholson noted: “The joke
does not provide any useful information about the abort() function so
removing it will not hinder use of glibc
“. On April 30, Zack
Weinberg applied the patch to the glibc

Richard Stallman, who added the joke sometime in the 1990s, asked that it not be removed. The resulting
discussion touched on a number of issues. Carlos O’Donell, who has been
trying hard to resolve the issue with some degree of consensus, suggested that the joke could hurt people who
have had bad experiences associated with abortion. He proposed a
couple of possible alternatives, including avoiding jokes entirely or
discussing such issues in a different forum. Stallman, however, replied that “a GNU manual, like a
course in history, is not meant to be a ‘safe space’
“. He suggested
the possibility of adding a trigger warning about functions that create
child processes, since childbirth is “far more traumatic than having an

Whether the joke belongs in the glibc manual is an issue for the glibc
developers to decide and wouldn’t normally be of much interest beyond the
project itself. But in this case, it raises the question of how the
developers make this decision. The project’s wiki
states that the project “uses a consensus-based community-driven
development model
“. In this case, there seems to be a fairly clear
consensus among the actual glibc developers that this joke is not
appropriate in the project’s manual. Weinberg’s application of the patch
was based on this consensus.

Stallman, however, has made it clear that there are limits to the extent to
which glibc is consensus-based; his response was: “My decision is to keep
the joke
“. Weinberg stated his
refusal to revert the change; Stallman answered: “I stand by my decision to
keep the joke
“. O’Donell apologized
for not contacting Stallman directly about the removal, but also stood by
the decision to remove it. He asked:

A large group of developers, serious senior developers, at least 3
project stewards (GNU Developers for the project), are indicating
that they do not share your same view on the joke. Please consider
their input and work with me to reach a consensus position.

Weinberg defended his application of the

I don’t think I did anything wrong procedurally. RMS may be the
project leader, but he is not a glibc maintainer. His wishes
regarding glibc are perhaps to be given _some_ more weight than
those of any other individual, particularly when he is also the
author of text under dispute, but we have never, to my knowledge,
treated them as mandates.

Stallman was unimpressed, though, and fell back to a pure authority play,
saying: “As the head of the GNU
Project, I am in charge of what we publish in GNU manuals. I decide the
criteria to decide by, too
“. He later added:

I exercise my authority over Glibc very rarely — and when I have
done so, I have talked with the official maintainers. So rarely
that some of you thought that you are entirely autonomous. But
that is not the case. On this particular question, I made a
decision long ago and stated it where all of you could see it.

O’Donell repeated that a discussion was
underway and that the maintainers did not intend to revert the patch. He
also asked whether the change violated any GNU policies — a question that
went unanswered as of this writing. He also stated clearly that the joke would not return
in any form until some sort of consensus was reached.

One could argue that the consensus is already there if one looks at the
developers who actually work on glibc; it is difficult to find any of them
arguing for the joke’s return. The number of people arguing for the joke
in general is quite small. That did not stop Alexandre Oliva, who
evidently has a high opinion of Stallman’s
sense of humor, from reverting
the change early on May 7 — his first glibc change in 2018. He did
not post his change to the mailing
list (and only explained it after being
asked); his attempt to justify it as a return to consensus did not fly with O’Donell. This discussion,
one suspects, is not done.

Each project has its own governance model. The “authoritarian leader”
model is quite common in this space, with many projects subject to the will
of a (hopefully benevolent) dictator who can decide to accept or reject any
change. Sometimes that model works better than others; glibc itself
improved its processes and inclusiveness considerably when its single
leader was replaced by a more consensus-oriented model. Usually, though,
such leaders are at least active developers in the projects they manage;
that is not the case for the GNU projects. It can be discouraging for a
developer to discover that their changes are subject to a veto from on
high by somebody who is not otherwise involved with the project’s
development. The echoes of this action may thus persist in the glibc
for some time.

Did you like this article? Please accept our
trial subscription offer to be
able to see more content like it and to participate in the discussion.

Log in to post comments)

Read More

This site uses Akismet to reduce spam. Learn how your comment data is processed.