a visit to VA Research, a Santa Clara-based company
selling workstations with the GNU/Linux operating
system preinstalled. Convened by Raymond, the meeting
was small. The invite list included VA founder Larry
Augustin, a few VA employees, and Christine Peterson,
president of the Foresight Institute, a Silicon Valley
think tank specializing in nanotechnology.
"The meeting's agenda boiled down to one item: how to
take advantage of Netscape's decision so that other
companies might follow suit?" Raymond doesn't recall
the conversation that took place, but he does remember
the first complaint addressed. Despite the best efforts
of Stallman and other hackers to remind people that the
word "free" in free software stood for freedom and not
price, the message still wasn't getting through. Most
business executives, upon hearing the term for the
first time, interpreted the word as synonymous with
"zero cost," tuning out any follow up messages in short
order. Until hackers found a way to get past this
cognitive dissonance, the free software movement faced
an uphill climb, even after Netscape.
Peterson, whose organization had taken an active
interest in advancing the free software cause, offered
an alternative: open source.
Looking back, Peterson says she came up with the open
source term while discussing Netscape's decision with a
friend in the public relations industry. She doesn't
remember where she came upon the term or if she
borrowed it from another field, but she does remember
her friend disliking the term.5
At the meeting, Peterson says, the response was
dramatically different. "I was hesitant about
suggesting it," Peterson recalls. "I had no standing
with the group, so started using it casually, not
highlighting it as a new term." To Peterson's surprise,
the term caught on. By the end of the meeting, most of
the attendees, including Raymond, seemed pleased by it.
Raymond says he didn't publicly use the term "open
source" as a substitute for free software until a day
or two after the Mozilla launch party, when O'Reilly
had scheduled a meeting to talk about free software.
Calling his meeting "the Freeware Summit," O'Reilly
says he wanted to direct media and community attention
to the other deserving projects that had also
encouraged Netscape to release Mozilla. "All these guys
had so much in common, and I was surprised they didn't
all know each other," says O'Reilly. "I also wanted to
let the world know just how great an impact the free
software culture had already made. People were missing
out on a large part of the free software tradition."
In putting together the invite list, however, O'Reilly
made a decision that would have long-term political
consequences. He decided to limit the list to
west-coast developers such as Wall, Eric Allman,
creator of sendmail, and Paul Vixie, creator of BIND.
There were exceptions, of course: Pennsylvania-resident
Raymond, who was already in town thanks to the Mozilla
launch, earned a quick invite. So did Virginia-resident
Guido van Rossum, creator of Python. "Frank Willison,
my editor in chief and champion of Python within the
company, invited him without first checking in with
me," O'Reilly recalls. "I was happy to have him there,
but when I started, it really was just a local gathering."
For some observers, the unwillingness to include
Stallman's name on the list qualified as a snub. "I
decided not to go to the event because of it," says
Perens, remembering the summit. Raymond, who did go,
says he argued for Stallman's inclusion to no avail.
The snub rumor gained additional strength from the fact
that O'Reilly, the event's host, had feuded publicly
with Stallman over the issue of software-manual
copyrights. Prior to the meeting, Stallman had argued
that free software manuals should be as freely copyable
and modifiable as free software programs. O'Reilly,
meanwhile, argued that a value-added market for nonfree
books increased the utility of free software by making
it more accessible to a wider community. The two had
also disputed the title of the event, with Stallman
insisting on "Free Software" over the less politically
laden "Freeware."
Looking back, O'Reilly doesn't see the decision to
leave Stallman's name off the invite list as a snub.
"At that time, I had never met Richard in person, but
in our email interactions, he'd been inflexible and
unwilling to engage in dialogue. I wanted to make sure
the GNU tradition was represented at the meeting, so I
invited John Gilmore and Michael Tiemann, whom I knew
personally, and whom I knew were passionate about the
value of the GPL but seemed more willing to engage in a
frank back-and-forth about the strengths and weaknesses
of the various free software projects and traditions.
Given all the later brouhaha, I do wish I'd invited
Richard as well, but I certainly don't think that my
failure to do so should be interpreted as a lack of
respect for the GNU Project or for Richard personally."
Snub or no snub, both O'Reilly and Raymond say the term
"open source" won over just enough summit-goers to
qualify as a success. The attendees shared ideas and
experiences and brainstormed on how to improve free
software's image. Of key concern was how to point out
the successes of free software, particularly in the
realm of Internet infrastructure, as opposed to playing
up the GNU/Linux challenge to Microsoft Windows. But
like the earlier meeting at VA, the discussion soon
turned to the problems associated with the term "free
software." O'Reilly, the summit host, remembers a
particularly insightful comment from Torvalds, a summit attendee.
"Linus had just moved to Silicon Valley at that point,
and he explained how only recently that he had learned
that the word `free' had two meanings-free as in
`libre' and free as in `gratis'-in English."
Michael Tiemann, founder of Cygnus, proposed an
alternative to the troublesome "free software" term:
sourceware. "Nobody got too excited about it," O'Reilly
recalls. "That's when Eric threw out the term `open source.'"
Although the term appealed to some, support for a
change in official terminology was far from unanimous.
At the end of the one-day conference, attendees put the
three terms-free software, open source, or
sourceware-to a vote. According to O'Reilly, 9 out of
the 15 attendees voted for "open source." Although some
still quibbled with the term, all attendees agreed to
use it in future discussions with the press. "We wanted
to go out with a solidarity message," O'Reilly says.
The term didn't take long to enter the national
lexicon. Shortly after the summit, O'Reilly shepherded
summit attendees to a press conference attended by
reporters from the New York Times, the Wall Street
Journal, and other prominent publications. Within a few
months, Torvalds' face was appearing on the cover of
Forbes magazine, with the faces of Stallman, Perl
creator Larry Wall, and Apache team leader Brian
Behlendorf featured in the interior spread. Open source
was open for business.
For summit attendees such as Tiemann, the solidarity
message was the most important thing. Although his
company had achieved a fair amount of success selling
free software tools and services, he sensed the
difficulty other programmers and entrepreneurs faced.
"There's no question that the use of the word free was
confusing in a lot of situations," Tiemann says. "Open
source positioned itself as being business friendly and
business sensible. Free software positioned itself as
morally righteous. For better or worse we figured it
was more advantageous to align with the open source crowd.
For Stallman, the response to the new "open source"
term was slow in coming. Raymond says Stallman briefly
considered adopting the term, only to discard it. "I
know because I had direct personal conversations about
it," Raymond says.
By the end of 1998, Stallman had formulated a position:
open source, while helpful in communicating the
technical advantages of free software, also encouraged
speakers to soft-pedal the issue of software freedom.
Given this drawback, Stallman would stick with the term
free software.
Summing up his position at the 1999 LinuxWorld
Convention and Expo, an event billed by Torvalds
himself as a "coming out party" for the Linux
community, Stallman implored his fellow hackers to
resist the lure of easy compromise.
"Because we've shown how much we can do, we don't have
to be desperate to work with companies or compromise
our goals," Stallman said during a panel discussion.
"Let them offer and we'll accept. We don't have to
change what we're doing to get them to help us. You can
take a single step towards a goal, then another and
then more and more and you'll actually reach your goal.
Or, you can take a half measure that means you don't
ever take another step and you'll never get there."
Even before the LinuxWorld show, however, Stallman was
showing an increased willingness to alienate his more
conciliatory peers. A few months after the Freeware
Summit, O'Reilly hosted its second annual Perl
Conference. This time around, Stallman was in
attendance. During a panel discussion lauding IBM's
decision to employ the free software Apache web server
in its commercial offerings, Stallman, taking advantage
of an audience microphone, disrupted the proceedings
with a tirade against panelist John Ousterhout, creator
of the Tcl scripting language. Stallman branded
Ousterhout a "parasite" on the free software community
for marketing a proprietary version of Tcl via
Ousterhout's startup company, Scriptics. "I don't think
Scriptics is necessary for the continued existence of
Tcl," Stallman said to hisses from the fellow audience members.See Malcolm
Maclachlan, "Profit Motive Splits Open
Source Movement," TechWeb News (August 26, 1998).
http://content.techweb.com/wire/story/TWB19980824S0012
"It was a pretty ugly scene," recalls Prime Time
Freeware's Rich Morin. "John's done some pretty
respectable things: Tcl, Tk, Sprite. He's a real contributor."
Despite his sympathies for Stallman and Stallman's
position, Morin felt empathy for those troubled by
Stallman's discordant behavior.
Stallman's Perl Conference outburst would momentarily
chase off another potential sympathizer, Bruce Perens.
In 1998, Eric Raymond proposed launching the Open
Source Initiative, or OSI, an organization that would
police the use of the term "open source" and provide a
definition for companies interested in making their own
programs. Raymond recruited Perens to draft the definition.See Bruce Perens et
al., "The Open Source Definition,"
The Open Source Initiative (1998).
http://www.opensource.org/docs/definition.html
Perens would later resign from the OSI, expressing
regret that the organization had set itself up in
opposition to Stallman and the FSF. Still, looking back
on the need for a free software definition outside the
Free Software Foundation's auspices, Perens understands
why other hackers might still feel the need for
distance. "I really like and admire Richard," says
Perens. "I do think Richard would do his job better if
Richard had more balance. That includes going away from
free software for a couple of months."
Stallman's monomaniacal energies would do little to
counteract the public-relations momentum of open source
proponents. In August of 1998, when chip-maker Intel
purchased a stake in GNU/Linux vendor Red Hat, an
accompanying New York Times article described the
company as the product of a movement "known
alternatively as free software and open source."See Amy Harmon, "For Sale: Free
Operating System," New
York Times (September 28, 1998).
http://www.nytimes.com/library/tech/98/09/biztech/articles/28linux.html
Six months later, a John Markoff article on Apple
Computer was proclaiming the company's adoption of the
"open source" Apache server in the article headline.See John Markoff, "Apple
Adopts `Open Source' for its
Server Computers," New York Times (March 17, 1999).
http://www.nytimes.com/library/tech/99/03/biztech/articles/17apple.html
Such momentum would coincide with the growing momentum
of companies that actively embraced the "open source"
term. By August of 1999, Red Hat, a company that now
eagerly billed itself as "open source," was selling
shares on Nasdaq. In December, VA Linux-formerly VA
Research-was floating its own IPO to historical effect.
Opening at $30 per share, the company's stock price
exploded past the $300 mark in initial trading only to
settle back down to the $239 level. Shareholders lucky
enough to get in at the bottom and stay until the end
experienced a 698% increase in paper wealth, a Nasdaq record.
Among those lucky shareholders was Eric Raymond, who,
as a company board member since the Mozilla launch, had
received 150,000 shares of VA Linux stock. Stunned by
the realization that his essay contrasting the
Stallman-Torvalds managerial styles had netted him $36
million in potential wealth, Raymond penned a follow-up
essay. In it, Raymond mused on the relationship between
the hacker ethic and monetary wealth: Reporters often
ask me these days if I think the open-source community
will be corrupted by the influx of big money. I tell
them what I believe, which is this: commercial demand
for programmers has been so intense for so long that
anyone who can be seriously distracted by money is
already gone. Our community has been self-selected for
caring about other things-accomplishment, pride,
artistic passion, and each other.See Eric Raymond, "Surprised by Wealth," Linux
Today
(December 10, 1999).
http://linuxtoday.com/news_story.php3?ltsn=1999-12-10-001-05-NW-LF
Whether or not such comments allayed suspicions that
Raymond and other open source proponents had simply
been in it for the money, they drove home the open
source community's ultimate message: all you needed to
sell the free software concept is a friendly face and a
sensible message. Instead of fighting the marketplace
head-on as Stallman had done, Raymond, Torvalds, and
other new leaders of the hacker community had adopted a
more relaxed approach-ignoring the marketplace in some
areas, leveraging it in others. Instead of playing the
role of high-school outcasts, they had played the game
of celebrity, magnifying their power in the process.
"On his worst days Richard believes that Linus Torvalds
and I conspired to hijack his revolution," Raymond
says. "Richard's rejection of the term open source and
his deliberate creation of an ideological fissure in my
view comes from an odd mix of idealism and
territoriality. There are people out there who think
it's all Richard's personal ego. I don't believe that.
It's more that he so personally associates himself with
the free software idea that he sees any threat to that
as a threat to himself."
Ironically, the success of open source and open source
advocates such as Raymond would not diminish Stallman's
role as a leader. If anything, it gave Stallman new
followers to convert. Still, the Raymond territoriality
charge is a damning one. There are numerous instances
of Stallman sticking to his guns more out of habit than
out of principle: his initial dismissal of the Linux
kernel, for example, and his current unwillingness as a
political figure to venture outside the realm of
software issues.
Then again, as the recent debate over open source also
shows, in instances when Stallman has stuck to his
guns, he's usually found a way to gain ground because
of it. "One of Stallman's primary character traits is
the fact he doesn't budge," says Ian Murdock. "He'll
wait up to a decade for people to come around to his
point of view if that's what it takes."
Murdock, for one, finds that unbudgeable nature both
refreshing and valuable. Stallman may no longer be the
solitary leader of the free software movement, but he
is still the polestar of the free software community.
"You always know that he's going to be consistent in
his views," Murdock says. "Most people aren't like
that. Whether you agree with him or not, you really
have to respect that."
A Brief Journey Through Hacker Hell
Richard Stallman stares, unblinking, through the
windshield of a rental car, waiting for the light to
change as we make our way through downtown Kihei.
The two of us are headed to the nearby town of Pa'ia,
where we are scheduled to meet up with some software
programmers and their wives for dinner in about an hour
or so.
It's about two hours after Stallman's speech at the
Maui High Performance Center, and Kihei, a town that
seemed so inviting before the speech, now seems
profoundly uncooperative. Like most beach cities, Kihei
is a one-dimensional exercise in suburban sprawl.
Driving down its main drag, with its endless succession
of burger stands, realty agencies, and bikini shops,
it's hard not to feel like a steel-coated morsel
passing through the alimentary canal of a giant
commercial tapeworm. The feeling is exacerbated by the
lack of side roads. With nowhere to go but forward,
traffic moves in spring-like lurches. 200 yards ahead,
a light turns green. By the time we are moving, the
light is yellow again.
For Stallman, a lifetime resident of the east coast,
the prospect of spending the better part of a sunny
Hawaiian afternoon trapped in slow traffic is enough to
trigger an embolism. Even worse is the knowledge that,
with just a few quick right turns a quarter mile back,
this whole situation easily could have been avoided.
Unfortunately, we are at the mercy of the driver ahead
of us, a programmer from the lab who knows the way and
who has decided to take us to Pa'ia via the scenic
route instead of via the nearby Pilani Highway.
"This is terrible," says Stallman between frustrated
sighs. "Why didn't we take the other route?"
Again, the light a quarter mile ahead of us turns
green. Again, we creep forward a few more car lengths.
This process continues for another 10 minutes, until we
finally reach a major crossroad promising access to the
adjacent highway.
The driver ahead of us ignores it and continues through
the intersection.
"Why isn't he turning?" moans Stallman, throwing up his
hands in frustration. "Can you believe this?"
I decide not to answer either. I find the fact that I
am sitting in a car with Stallman in the driver seat,
in Maui no less, unbelievable enough. Until two hours
ago, I didn't even know Stallman knew how to drive.
Now, listening to Yo-Yo Ma's cello playing the mournful
bass notes of "Appalachian Journey" on the car stereo
and watching the sunset pass by on our left, I do my
best to fade into the upholstery.
When the next opportunity to turn finally comes up,
Stallman hits his right turn signal in an attempt to
cue the driver ahead of us. No such luck. Once again,
we creep slowly through the intersection, coming to a
stop a good 200 yards before the next light. By now,
Stallman is livid.
"It's like he's deliberately ignoring us," he says,
gesturing and pantomiming like an air craft carrier
landing-signals officer in a futile attempt to catch
our guide's eye. The guide appears unfazed, and for the
next five minutes all we see is a small portion of his
head in the rearview mirror.
I look out Stallman's window. Nearby Kahoolawe and
Lanai Islands provide an ideal frame for the setting
sun. It's a breathtaking view, the kind that makes
moments like this a bit more bearable if you're a
Hawaiian native, I suppose. I try to direct Stallman's
attention to it, but Stallman, by now obsessed by the
inattentiveness of the driver ahead of us, blows me off.
When the driver passes through another green light,
completely ignoring a "Pilani Highway Next Right," I
grit my teeth. I remember an early warning relayed to
me by BSD programmer Keith Bostic. "Stallman does not
suffer fools gladly," Bostic warned me. "If somebody
says or does something stupid, he'll look them in the
eye and say, `That's stupid.'"
Looking at the oblivious driver ahead of us, I realize
that it's the stupidity, not the inconvenience, that's
killing Stallman right now.
"It's as if he picked this route with absolutely no
thought on how to get there efficiently," Stallman says.
The word "efficiently" hangs in the air like a bad
odor. Few things irritate the hacker mind more than
inefficiency. It was the inefficiency of checking the
Xerox laser printer two or three times a day that
triggered Stallman's initial inquiry into the printer
source code. It was the inefficiency of rewriting
software tools hijacked by commercial software vendors
that led Stallman to battle Symbolics and to launch the
GNU Project. If, as Jean Paul Sartre once opined, hell
is other people, hacker hell is duplicating other
people's stupid mistakes, and it's no exaggeration to
say that Stallman's entire life has been an attempt to
save mankind from these fiery depths.
This hell metaphor becomes all the more apparent as we
take in the slowly passing scenery. With its multitude
of shops, parking lots, and poorly timed street lights,
Kihei seems less like a city and more like a poorly
designed software program writ large. Instead of
rerouting traffic and distributing vehicles through
side streets and expressways, city planners have
elected to run everything through a single main drag.
From a hacker perspective, sitting in a car amidst all
this mess is like listening to a CD rendition of nails
on a chalkboard at full volume.
"Imperfect systems infuriate hackers," observes Steven
Levy, another warning I should have listened to before
climbing into the car with Stallman. "This is one
reason why hackers generally hate driving cars-the
system of randomly programmed red lights and oddly laid
out one-way streets causes delays which are so goddamn
unnecessary [Levy's emphasis] that the impulse is to
rearrange signs, open up traffic-light control boxes .
. . redesign the entire system."See Steven Levy, Hackers (Penguin USA
[paperback],
1984): 40.
More frustrating, however, is the duplicity of our
trusted guide. Instead of searching out a clever
shortcut-as any true hacker would do on instinct-the
driver ahead of us has instead chosen to play along
with the city planners' game. Like Virgil in Dante's
Inferno, our guide is determined to give us the full
guided tour of this hacker hell whether we want it or not.
Before I can make this observation to Stallman, the
driver finally hits his right turn signal. Stallman's
hunched shoulders relax slightly, and for a moment the
air of tension within the car dissipates. The tension
comes back, however, as the driver in front of us slows
down. "Construction Ahead" signs line both sides of the
street, and even though the Pilani Highway lies less
than a quarter mile off in the distance, the two-lane
road between us and the highway is blocked by a dormant
bulldozer and two large mounds of dirt.
It takes Stallman a few seconds to register what's
going on as our guide begins executing a clumsy
five-point U-turn in front of us. When he catches a
glimpse of the bulldozer and the "No Through Access"
signs just beyond, Stallman finally boils over.
"Why, why, why?" he whines, throwing his head back.
"You should have known the road was blocked. You should
have known this way wouldn't work. You did this deliberately."
The driver finishes the turn and passes us on the way
back toward the main drag. As he does so, he shakes his
head and gives us an apologetic shrug. Coupled with a
toothy grin, the driver's gesture reveals a touch of
mainlander frustration but is tempered with a
protective dose of islander fatalism. Coming through
the sealed windows of our rental car, it spells out a
succinct message: "Hey, it's Maui; what are you gonna do?"
Stallman can take it no longer.
"Don't you fucking smile!" he shouts, fogging up the
glass as he does so. "It's your fucking fault. This all
could have been so much easier if we had just done it
my way."
Stallman accents the words "my way" by gripping the
steering wheel and pulling himself towards it twice.
The image of Stallman's lurching frame is like that of
a child throwing a temper tantrum in a car seat, an
image further underlined by the tone of Stallman's
voice. Halfway between anger and anguish, Stallman
seems to be on the verge of tears.
Fortunately, the tears do not arrive. Like a summer
cloudburst, the tantrum ends almost as soon as it
begins. After a few whiny gasps, Stallman shifts the
car into reverse and begins executing his own U-turn.
By the time we are back on the main drag, his face is
as impassive as it was when we left the hotel 30
minutes earlier.
It takes less than five minutes to reach the next
cross-street. This one offers easy highway access, and
within seconds, we are soon speeding off toward Pa'ia
at a relaxing rate of speed. The sun that once loomed
bright and yellow over Stallman's left shoulder is now
burning a cool orange-red in our rearview mirror. It
lends its color to the gauntlet wili wili trees flying
past us on both sides of the highway.
For the next 20 minutes, the only sound in our vehicle,
aside from the ambient hum of the car's engine and
tires, is the sound of a cello and a violin trio
playing the mournful strains of an Appalachian folk
tune. Endnote
Continuing the Fight
For Richard Stallman, time may not heal all wounds, but
it does provide a convenient ally.
Four years after " The Cathedral and the Bazaar,"
Stallman still chafes over the Raymond critique. He
also grumbles over Linus Torvalds' elevation to the
role of world's most famous hacker. He recalls a
popular T-shirt that began showing at Linux tradeshows
around 1999. Designed to mimic the original promotional
poster for Star Wars, the shirt depicted Torvalds
brandishing a lightsaber like Luke Skywalker, while
Stallman's face rides atop R2D2. The shirt still grates
on Stallmans nerves not only because it depicts him as
a Torvalds' sidekick, but also because it elevates
Torvalds to the leadership role in the free
software/open source community, a role even Torvalds
himself is loath to accept. "It's ironic," says
Stallman mournfully. "Picking up that sword is exactly
what Linus refuses to do. He gets everybody focusing on
him as the symbol of the movement, and then he won't
fight. What good is it?"
Then again, it is that same unwillingness to "pick up
the sword," on Torvalds part, that has left the door
open for Stallman to bolster his reputation as the
hacker community's ethical arbiter. Despite his
grievances, Stallman has to admit that the last few
years have been quite good, both to himself and to his
organization. Relegated to the periphery by the
unforeseen success of GNU/Linux, Stallman has
nonetheless successfully recaptured the initiative. His
speaking schedule between January 2000 and December
2001 included stops on six continents and visits to
countries where the notion of software freedom carries
heavy overtones-China and India, for example.
Outside the bully pulpit, Stallman has also learned how
to leverage his power as costeward of the GNU General
Public License (GPL). During the summer of 2000, while
the air was rapidly leaking out of the 1999 Linux IPO
bubble, Stallman and the Free Software Foundation
scored two major victories. In July, 2000, Troll Tech,
a Norwegian software company and developer of Qt, a
valuable suite of graphics tools for the GNU/Linux
operating system, announced it was licensing its
software under the GPL. A few weeks later, Sun
Microsystems, a company that, until then, had been
warily trying to ride the open source bandwagon without
giving up total control of its software properties,
finally relented and announced that it, too, was dual
licensing its new OpenOffice application suite under
the Lesser GNU Public License (LGPL) and the Sun
Industry Standards Source License (SISSL).
Underlining each victory was the fact that Stallman had
done little to fight for them. In the case of Troll
Tech, Stallman had simply played the role of free
software pontiff. In 1999, the company had come up with
a license that met the conditions laid out by the Free
Software Foundation, but in examining the license
further, Stallman detected legal incompatibles that
would make it impossible to bundle Qt with
GPL-protected software programs. Tired of battling
Stallman, Troll Tech management finally decided to
split the Qt into two versions, one GPL-protected and
one QPL-protected, giving developers a way around the
compatibility issues cited by Stallman.
In the case of Sun, they desired to play according to
the Free Software Foundation's conditions. At the 1999
O'Reilly Open Source Conference, Sun Microsystems
cofounder and chief scientist Bill Joy defended his
company's "community source" license, essentially a
watered-down compromise letting users copy and modify
Sun-owned software but not charge a fee for said
software without negotiating a royalty agreement with
Sun. A year after Joy's speech, Sun Microsystems vice
president Marco Boerries was appearing on the same
stage spelling out the company's new licensing
compromise in the case of OpenOffice, an
office-application suite designed specifically for the
GNU/Linux operating system.
"I can spell it out in three letters," said Boerries. "GPL."
At the time, Boerries said his company's decision had
little to do with Stallman and more to do with the
momentum of GPL-protected programs. "What basically
happened was the recognition that different products
attracted different communities, and the license you
use depends on what type of community you want to
attract," said Boerries. "With [OpenOffice], it was
clear we had the highest correlation with the GPL community."See Marco
Boerries, interview with author (July, 2000).
Such comments point out the under-recognized strength
of the GPL and, indirectly, the political genius of man
who played the largest role in creating it. "There
isn't a lawyer on earth who would have drafted the GPL
the way it is," says Eben Moglen, Columbia University
law professor and Free Software Foundation general
counsel. "But it works. And it works because of
Richard's philosophy of design."
A former professional programmer, Moglen traces his pro
bono work with Stallman back to 1990 when Stallman
requested Moglen's legal assistance on a private
affair. Moglen, then working with encryption expert
Phillip Zimmerman during Zimmerman's legal battles with
the National Security Administration, says he was
honored by the request. "I told him I used Emacs every
day of my life, and it would take an awful lot of
lawyering on my part to pay off the debt."
Since then, Moglen, perhaps more than any other
individual, has had the best chance to observe the
crossover of Stallman's hacker philosophies into the
legal realm. Moglen says the difference between
Stallman's approach to legal code and software code are
largely the same. "I have to say, as a lawyer, the idea
that what you should do with a legal document is to
take out all the bugs doesn't make much sense," Moglen
says. "There is uncertainty in every legal process, and
what most lawyers want to do is to capture the benefits
of uncertainty for their client. Richard's goal is the
complete opposite. His goal is to remove uncertainty,
which is inherently impossible. It is inherently
impossible to draft one license to control all
circumstances in all legal systems all over the world.
But if you were to go at it, you would have to go at it
his way. And the resulting elegance, the resulting
simplicity in design almost achieves what it has to
achieve. And from there a little lawyering will carry
you quite far."
As the person charged with pushing the Stallman agenda,
Moglen understands the frustration of would-be allies.
"Richard is a man who does not want to compromise over
matters that he thinks of as fundamental," Moglen says,
"and he does not take easily the twisting of words or
even just the seeking of artful ambiguity, which human
society often requires from a lot of people."
Because of the Free Software Foundation's unwillingness
to weigh in on issues outside the purview of GNU
development and GPL enforcement, Moglen has taken to
devoting his excess energies to assisting the
Electronic Frontier Foundation, the organization
providing legal aid to recent copyright defendants such
as Dmitri Skylarov. In 2000, Moglen also served as
direct counsel to a collection of hackers that were
joined together from circulating the DVD decryption
program deCSS. Despite the silence of his main client
in both cases, Moglen has learned to appreciate the
value of Stallman's stubbornness. "There have been
times over the years where I've gone to Richard and
said, `We have to do this. We have to do that. Here's
the strategic situation. Here's the next move. Here's
what he have to do.' And Richard's response has always
been, `We don't have to do anything.' Just wait. What
needs doing will get done."
"And you know what?" Moglen adds. "Generally, he's been right."
Such comments disavow Stallman's own self-assessment:
"I'm not good at playing games," Stallman says,
addressing the many unseen critics who see him as a
shrewd strategist. "I'm not good at looking ahead and
anticipating what somebody else might do. My approach
has always been to focus on the foundation, to say
`Let's make the foundation as strong as we can make it.'"
The GPL's expanding popularity and continuing
gravitational strength are the best tributes to the
foundation laid by Stallman and his GNU colleagues.
While no longer capable of billing himself as the "last
true hacker," Stallman nevertheless can take sole
credit for building the free software movement's
ethical framework. Whether or not other modern
programmers feel comfortable working inside that
framework is immaterial. The fact that they even have a
choice at all is Stallman's greatest legacy.
Discussing Stallman's legacy at this point seems a bit
premature. Stallman, 48 at the time of this writing,
still has a few years left to add to or subtract from
that legacy. Still, the autopilot nature of the free
software movement makes it tempting to examine
Stallman's life outside the day-to-day battles of the
software industry and within a more august, historical setting.
To his credit, Stallman refuses all opportunities to
speculate. "I've never been able to work out detailed
plans of what the future was going to be like," says
Stallman, offering his own premature epitaph. "I just
said `I'm going to fight. Who knows where I'll get?'"
There's no question that in picking his fights,
Stallman has alienated the very people who might
otherwise have been his greatest champions. It is also
a testament to his forthright, ethical nature that many
of Stallman's erstwhile political opponents still
manage to put in a few good words for him when pressed.
The tension between Stallman the ideologue and Stallman
the hacker genius, however, leads a biographer to
wonder: how will people view Stallman when Stallman's
own personality is no longer there to get in the way?
In early drafts of this book, I dubbed this question
the "100 year" question. Hoping to stimulate an
objective view of Stallman and his work, I asked
various software-industry luminaries to take themselves
out of the current timeframe and put themselves in a
position of a historian looking back on the free
software movement 100 years in the future. From the
current vantage point, it is easy to see similarities
between Stallman and past Americans who, while somewhat
marginal during their lifetime, have attained
heightened historical importance in relation to their
age. Easy comparisons include Henry David Thoreau,
transcendentalist philosopher and author of On Civil
Disobedience, and John Muir, founder of the Sierra Club
and progenitor of the modern environmental movement. It
is also easy to see similarities in men like William
Jennings Bryan, a.k.a. "The Great Commoner," leader of
the populist movement, enemy of monopolies, and a man
who, though powerful, seems to have faded into
historical insignificance.
Although not the first person to view software as
public property, Stallman is guaranteed a footnote in
future history books thanks to the GPL. Given that
fact, it seems worthwhile to step back and examine
Richard Stallman's legacy outside the current time
frame. Will the GPL still be something software
programmers use in the year 2102, or will it have long
since fallen by the wayside? Will the term "free
software" seem as politically quaint as "free silver"
does today, or will it seem eerily prescient in light
of later political events?
Predicting the future is risky sport, but most people,
when presented with the question, seemed eager to bite.
"One hundred years from now, Richard and a couple of
other people are going to deserve more than a
footnote," says Moglen. "They're going to be viewed as
the main line of the story."
The "couple other people" Moglen nominates for future
textbook chapters include John Gilmore, Stallman's GPL
advisor and future founder of the Electronic Frontier
Foundation, and Theodor Holm Nelson, a.k.a. Ted Nelson,
author of the 1982 book, Literary Machines . Moglen
says Stallman, Nelson, and Gilmore each stand out in
historically significant, nonoverlapping ways. He
credits Nelson, commonly considered to have coined the
term "hypertext," for identifying the predicament of
information ownership in the digital age. Gilmore and
Stallman, meanwhile, earn notable credit for
identifying the negative political effects of
information control and building organizations-the
Electronic Frontier Foundation in the case of Gilmore
and the Free Software Foundation in the case of
Stallman-to counteract those effects. Of the two,
however, Moglen sees Stallman's activities as more
personal and less political in nature.
"Richard was unique in that the ethical implications of
unfree software were particularly clear to him at an
early moment," says Moglen. "This has a lot to do with
Richard's personality, which lots of people will, when
writing about him, try to depict as epiphenomenal or
even a drawback in Richard Stallman's own life work."
Gilmore, who describes his inclusion between the
erratic Nelson and the irascible Stallman as something
of a "mixed honor," nevertheless seconds the Moglen
argument. Writes Gilmore: My guess is that Stallman's
writings will stand up as well as Thomas Jefferson's
have; he's a pretty clear writer and also clear on his
principles . . . Whether Richard will be as influential
as Jefferson will depend on whether the abstractions we
call "civil rights" end up more important a hundred
years from now than the abstractions that we call
"software" or "technically imposed restrictions."
Another element of the Stallman legacy not to be
overlooked, Gilmore writes, is the collaborative
software-development model pioneered by the GNU
Project. Although flawed at times, the model has
nevertheless evolved into a standard within the
software-development industry. All told, Gilmore says,
this collaborative software-development model may end
up being even more influential than the GNU Project,
the GPL License, or any particular software program
developed by Stallman: Before the Internet, it was
quite hard to collaborate over distance on software,
even among teams that know and trust each other.
Richard pioneered collaborative development of
software, particularly by disorganized volunteers who
seldom meet each other. Richard didn't build any of the
basic tools for doing this (the TCP protocol, email
lists, diff and patch, tar files, RCS or CVS or
remote-CVS), but he used the ones that were available
to form social groups of programmers who could
effectively collaborate. Lawrence Lessig, Stanford law
professor and author of the 2001 book, The Future of
Ideas , is similarly bullish. Like many legal scholars,
Lessig sees the GPL as a major bulwark of the current
so-called "digital commons," the vast agglomeration of
community-owned software programs, network and
telecommunication standards that have triggered the
Internet's exponential growth over the last three
decades. Rather than connect Stallman with other
Internet pioneers, men such as Vannevar Bush, Vinton
Cerf, and J. C. R. Licklider who convinced others to
see computer technology on a wider scale, Lessig sees
Stallman's impact as more personal, introspective, and,
ultimately, unique: [Stallman] changed the debate from
is to ought. He made people see how much was at stake,
and he built a device to carry these ideals forward . .
. That said, I don't quite know how to place him in the
context of Cerf or Licklider. The innovation is
different. It is not just about a certain kind of code,
or enabling the Internet. [It's] much more about
getting people to see the value in a certain kind of
Internet. I don't think there is anyone else in that
class, before or after. Not everybody sees the Stallman
legacy as set in stone, of course. Eric Raymond, the
open source proponent who feels that Stallman's
leadership role has diminished significantly since
1996, sees mixed signals when looking into the 2102
crystal ball: I think Stallman's artifacts (GPL, Emacs,
GCC) will be seen as revolutionary works, as
foundation-stones of the information world. I think
history will be less kind to some of the theories from
which RMS operated, and not kind at all to his personal
tendency towards territorial, cult-leader behavior. As
for Stallman himself, he, too, sees mixed signals: What
history says about the GNU Project, twenty years from
now, will depend on who wins the battle of freedom to
use public knowledge. If we lose, we will be just a
footnote. If we win, it is uncertain whether people
will know the role of the GNU operating system-if they
think the system is "Linux," they will build a false
picture of what happened and why.
But even if we win, what history people learn a hundred
years from now is likely to depend on who dominates
politically. Searching for his own 19th-century
historical analogy, Stallman summons the figure of John
Brown, the militant abolitionist regarded as a hero on
one side of the Mason Dixon line and a madman on the other.
John Brown's slave revolt never got going, but during
his subsequent trial he effectively roused national
demand for abolition. During the Civil War, John Brown
was a hero; 100 years after, and for much of the 1900s,
history textbooks taught that he was crazy. During the
era of legal segregation, while bigotry was shameless,
the US partly accepted the story that the South wanted
to tell about itself, and history textbooks said many
untrue things about the Civil War and related events.
Such comparisons document both the self-perceived
peripheral nature of Stallman's current work and the
binary nature of his current reputation. Although it's
hard to see Stallman's reputation falling to the level
of infamy as Brown's did during the post-Reconstruction
period-Stallman, despite his occasional war-like
analogies, has done little to inspire violence-it's
easy to envision a future in which Stallman's ideas
wind up on the ash-heap. In fashioning the free
software cause not as a mass movement but as a
collection of private battles against the forces of
proprietary temptation, Stallman seems to have created
a unwinnable situation, especially for the many
acolytes with the same stubborn will.
Then again, it is that very will that may someday prove
to be Stallman's greatest lasting legacy. Moglen, a
close observer over the last decade, warns those who
mistake the Stallman personality as counter-productive
or epiphenomenal to the "artifacts" of Stalllman's
life. Without that personality, Moglen says, there
would be precious few artifiacts to discuss. Says
Moglen, a former Supreme Court clerk: Look, the
greatest man I ever worked for was Thurgood Marshall. I
knew what made him a great man. I knew why he had been
able to change the world in his possible way. I would
be going out on a limb a little bit if I were to make a
comparison, because they could not be more different.
Thurgood Marshall was a man in society, representing an
outcast society to the society that enclosed it, but
still a man in society. His skill was social skills.
But he was all of a piece, too. Different as they were
in every other respect, that the person I most now
compare him to in that sense, all of a piece, compact,
made of the substance that makes stars, all the way
through, is Stallman. In an effort to drive that image
home, Moglen reflects on a shared moment in the spring
of 2000. The success of the VA Linux IPO was still
resonating in the business media, and a half dozen free
software-related issues were swimming through the news.
Surrounded by a swirling hurricane of issues and
stories each begging for comment, Moglen recalls
sitting down for lunch with Stallman and feeling like a
castaway dropped into the eye of the storm. For the
next hour, he says, the conversation calmly revolved
around a single topic: strengthening the GPL.
"We were sitting there talking about what we were going
to do about some problems in Eastern Europe and what we
were going to do when the problem of the ownership of
content began to threaten free software," Moglen
recalls. "As we were talking, I briefly thought about
how we must have looked to people passing by. Here we
are, these two little bearded anarchists, plotting and
planning the next steps. And, of course, Richard is
plucking the knots from his hair and dropping them in
the soup and behaving in his usual way. Anybody
listening in on our conversation would have thought we
were crazy, but I knew: I knew the revolution's right
here at this table. This is what's making it happen.
And this man is the person making it happen."
Moglen says that moment, more than any other, drove
home the elemental simplicity of the Stallman style.
"It was funny," recalls Moglen. "I said to him,
`Richard, you know, you and I are the two guys who
didn't make any money out of this revolution.' And then
I paid for the lunch, because I knew he didn't have the
money to pay for it .'" Endnote
Epilogue:
Crushing Loneliness Writing the biography of a living
person is a bit like producing a play. The drama in
front of the curtain often pales in comparison to the
drama backstage.
In The Autobiography of Malcolm X, Alex Haley gives
readers a rare glimpse of that backstage drama.
Stepping out of the ghostwriter role, Haley delivers
the book's epilogue in his own voice. The epilogue
explains how a freelance reporter originally dismissed
as a "tool" and "spy" by the Nation of Islam
spokesperson managed to work through personal and
political barriers to get Malcolm X's life story on paper.
While I hesitate to compare this book with The
Autobiography of Malcolm X, I do owe a debt of
gratitude to Haley for his candid epilogue. Over the
last 12 months, it has served as a sort of instruction
manual on how to deal with a biographical subject who
has built an entire career on being disagreeable. From
the outset, I envisioned closing this biography with a
similar epilogue, both as an homage to Haley and as a
way to let readers know how this book came to be.
The story behind this story starts in an Oakland
apartment, winding its way through the various locales
mentioned in the book-Silicon Valley, Maui, Boston, and
Cambridge. Ultimately, however, it is a tale of two
cities: New York, New York, the book-publishing capital
of the world, and Sebastopol, California, the
book-publishing capital of Sonoma County.
The story starts in April, 2000. At the time, I was
writing stories for the ill-fated BeOpen web site
(http://www.beopen.com/). One of my first assignments
was a phone interview with Richard M. Stallman. The
interview went well, so well that Slashdot
(http://www.slashdot.org/), the popular "news for
nerds" site owned by VA Software, Inc. (formerly VA
Linux Systems and before that, VA Research), gave it a
link in its daily list of feature stories. Within
hours, the web servers at BeOpen were heating up as
readers clicked over to the site.
For all intents and purposes, the story should have
ended there. Three months after the interview, while
attending the O'Reilly Open Source Conference in
Monterey, California, I received the following email
message from Tracy Pattison, foreign-rights manager at
a large New York publishing house:
To: sam@BeOpen.com Subject: RMS InterviewDate: Mon, 10
Jul 2000 15:56:37 -0400Dear Mr. Williams,
I read your interview with Richard Stallman on BeOpen
with great interest. I've been intrigued by RMS and his
work for some time now and was delighted to find your
piece which I really think you did a great job of
capturing some of the spirit of what Stallman is trying
to do with GNU-Linux and the Free Software Foundation.
What I'd love to do, however, is read more - and I
don't think I'm alone. Do you think there is more
information and/or sources out there to expand and
update your interview and adapt it into more of a
profile of Stallman? Perhaps including some more
anecdotal information about his personality and
background that might really interest and enlighten
readers outside the more hardcore programming scene?
The email asked that I give Tracy a call to discuss the
idea further. I did just that. Tracy told me her
company was launching a new electronic book line, and
it wanted stories that appealed to an early-adopter
audience. The e-book format was 30,000 words, about 100
pages, and she had pitched her bosses on the idea of
profiling a major figure in the hacker community. Her
bosses liked the idea, and in the process of searching
for interesting people to profile, she had come across
my BeOpen interview with Stallman. Hence her email to me.
That's when Tracy asked me: would I be willing to
expand the interview into a full-length feature profile?
My answer was instant: yes. Before accepting it, Tracy
suggested I put together a story proposal she could
show her superiors. Two days later, I sent her a
polished proposal. A week later, Tracy sent me a follow
up email. Her bosses had given it the green light.
I have to admit, getting Stallman to participate in an
e-book project was an afterthought on my part. As a
reporter who covered the open source beat, I knew
Stallman was a stickler. I'd already received a half
dozen emails at that point upbraiding me for the use of
"Linux" instead of "GNU/Linux."
Then again, I also knew Stallman was looking for ways
to get his message out to the general public. Perhaps
if I presented the project to him that way, he would be
more receptive. If not, I could always rely upon the
copious amounts of documents, interviews, and recorded
online conversations Stallman had left lying around the
Internet and do an unauthorized biography.
During my research, I came across an essay titled
"Freedom-Or Copyright?" Written by Stallman and
published in the June, 2000, edition of the MIT
Technology Review, the essay blasted e-books for an
assortment of software sins. Not only did readers have
to use proprietary software programs to read them,
Stallman lamented, but the methods used to prevent
unauthorized copying were overly harsh. Instead of
downloading a transferable HTML or PDF file, readers
downloaded an encrypted file. In essence, purchasing an
e-book meant purchasing a nontransferable key to
unscramble the encrypted content. Any attempt to open a
book's content without an authorized key constituted a
criminal violation of the Digital Millennium Copyright
Act, the 1998 law designed to bolster copyright
enforcement on the Internet. Similar penalties held for
readers who converted a book's content into an open
file format, even if their only intention was to read
the book on a different computer in their home. Unlike
a normal book, the reader no longer held the right to
lend, copy, or resell an e-book. They only had the
right to read it on an authorized machine, warned
Stallman: We still have the same old freedoms in using
paper books. But if e-books replace printed books, that
exception will do little good. With "electronic ink,"
which makes it possible to download new text onto an
apparently printed piece of paper, even newspapers
could become ephemeral. Imagine: no more used book
stores; no more lending a book to your friend; no more
borrowing one from the public library-no more "leaks"
that might give someone a chance to read without
paying. (And judging from the ads for Microsoft Reader,
no more anonymous purchasing of books either.) This is
the world publishers have in mind for us.See "Safari Tech Books Online;
Subscriber Agreement:
Terms of Service."
http://safari.oreilly.com/mainhlp.asp?help=service
Needless to say, the essay caused some concern. Neither
Tracy nor I had discussed the software her company
would use nor had we discussed the type of copyright
that would govern the e-book's usage. I mentioned the
Technology Review article and asked if she could give
me information on her company's e-book policies. Tracy
promised to get back to me.
Eager to get started, I decided to call Stallman anyway
and mention the book idea to him. When I did, he
expressed immediate interest and immediate concern.
"Did you read my essay on e-books?" he asked.
When I told him, yes, I had read the essay and was
waiting to hear back from the publisher, Stallman laid
out two conditions: he didn't want to lend support to
an e-book licensing mechanism he fundamentally opposed,
and he didn't want to come off as lending support. "I
don't want to participate in anything that makes me
look like a hypocrite," he said.
For Stallman, the software issue was secondary to the
copyright issue. He said he was willing to ignore
whatever software the publisher or its third-party
vendors employed just so long as the company specified
within the copyright that readers were free to make and
distribute verbatim copies of the e-book's content.
Stallman pointed to Stephen King's The Plant as a
possible model. In June, 2000, King announced on his
official web site that he was self-publishing The Plant
in serial form. According to the announcement, the
book's total cost would be $13, spread out over a
series of $1 installments. As long as at least 75% of
the readers paid for each chapter, King promised to
continue releasing new installments. By August, the
plan seemed to be working, as King had published the
first two chapters with a third on the way.
"I'd be willing to accept something like that,"
Stallman said. "As long as it also permitted verbatim copying."
I forwarded the information to Tracy. Feeling confident
that she and I might be able to work out an equitable
arrangement, I called up Stallman and set up the first
interview for the book. Stallman agreed to the
interview without making a second inquiry into the
status issue. Shortly after the first interview, I
raced to set up a second interview (this one in Kihei),
squeezing it in before Stallman headed off on a 14-day
vacation to Tahiti.
It was during Stallman's vacation that the bad news
came from Tracy. Her company's legal department didn't
want to adjust its copyright notice on the e-books.
Readers who wanted to make their books transferable
would either have to crack the encryption code or
convert the book to an open format such as HTML. Either
way, the would be breaking the law and facing criminal penalties.
With two fresh interviews under my belt, I didn't see
any way to write the book without resorting to the new
material. I quickly set up a trip to New York to meet
with my agent and with Tracy to see if there was a
compromise solution.
When I flew to New York, I met my agent, Henning
Guttman. It was our first face-to-face meeting, and
Henning seemed pessimistic about our chances of forcing
a compromise, at least on the publisher's end. The
large, established publishing houses already viewed the
e-book format with enough suspicion and weren't in the
mood to experiment with copyright language that made it
easier for readers to avoid payment. As an agent who
specialized in technology books, however, Henning was
intrigued by the novel nature of my predicament. I told
him about the two interviews I'd already gathered and
the promise not to publish the book in a way that made
Stallman "look like a hypocrite." Agreeing that I was
in an ethical bind, Henning suggested we make that our
negotiating point.
Barring that, Henning said, we could always take the
carrot-and-stick approach. The carrot would be the
publicity that came with publishing an e-book that
honored the hacker community's internal ethics. The
stick would be the risks associated with publishing an
e-book that didn't. Nine months before Dmitri Skylarov
became an Internet cause celebre, we knew it was only a
matter of time before an enterprising programmer
revealed how to hack e-books. We also knew that a major
publishing house releasing an encryption-protected
e-book on Richard M. Stallman was the software
equivalent of putting "Steal This E-Book" on the cover.
After my meeting with Henning, I put a call into
Stallman. Hoping to make the carrot more enticing, I
discussed a number of potential compromises. What if
the publisher released the book's content under a split
license, something similar to what Sun Microsystems had
done with Open Office, the free software desktop
applications suite? The publisher could then release
commercial versions of the e-book under a normal
format, taking advantage of all the bells and whistles
that went with the e-book software, while releasing the
copyable version under a less aesthetically pleasing
HTML format.
Stallman told me he didn't mind the split-license idea,
but he did dislike the idea of making the freely
copyable version inferior to the restricted version.
Besides, he said, the idea was too cumbersome. Split
licenses worked in the case of Sun's Open Office only
because he had no control over the decision making. In
this case, Stallman said, he did have a way to control
the outcome. He could refuse to cooperate.
I made a few more suggestions with little effect. About
the only thing I could get out of Stallman was a
concession that the e-book's copyright restrict all
forms of file sharing to "noncommercial redistribution."
Before I signed off, Stallman suggested I tell the
publisher that I'd promised Stallman that the work
would be free. I told Stallman I couldn't agree to that
statement but that I did view the book as unfinishable
without his cooperation. Seemingly satisfied, Stallman
hung up with his usual sign-off line: "Happy hacking."
Henning and I met with Tracy the next day. Tracy said
her company was willing to publish copyable excerpts in
a unencrypted format but would limit the excerpts to
500 words. Henning informed her that this wouldn't be
enough for me to get around my ethical obligation to
Stallman. Tracy mentioned her own company's contractual
obligation to online vendors such as Amazon.com. Even
if the company decided to open up its e-book content
this one time, it faced the risk of its partners
calling it a breach of contract. Barring a change of
heart in the executive suite or on the part of
Stallman, the decision was up to me. I could use the
interviews and go against my earlier agreement with
Stallman, or I could plead journalistic ethics and back
out of the verbal agreement to do the book.
Following the meeting, my agent and I relocated to a
pub on Third Ave. I used his cell phone to call
Stallman, leaving a message when nobody answered.
Henning left for a moment, giving me time to collect my
thoughts. When he returned, he was holding up the cell phone.
"It's Stallman," Henning said.
The conversation got off badly from the start. I
relayed Tracy's comment about the publisher's
contractual obligations.
"So," Stallman said bluntly. "Why should I give a damn
about their contractual obligations?"
Because asking a major publishing house to risk a legal
battle with its vendors over a 30,000 word e-book is a
tall order, I suggested.
"Don't you see?" Stallman said. "That's exactly why I'm
doing this. I want a signal victory. I want them to
make a choice between freedom and business as usual."
As the words "signal victory" echoed in my head, I felt
my attention wander momentarily to the passing foot
traffic on the sidewalk. Coming into the bar, I had
been pleased to notice that the location was less than
half a block away from the street corner memorialized
in the 1976 Ramones song, "53rd and 3rd," a song I
always enjoyed playing in my days as a musician. Like
the perpetually frustrated street hustler depicted in
that song, I could feel things falling apart as quickly
as they had come together. The irony was palpable.
After weeks of gleefully recording other people's
laments, I found myself in the position of trying to
pull off the rarest of feats: a Richard Stallman compromise.
When I continued hemming and hawing, pleading the
publisher's position and revealing my growing sympathy
for it, Stallman, like an animal smelling blood, attacked.
"So that's it? You're just going to screw me? You're
just going to bend to their will?"
I brought up the issue of a dual-copyright again.
"You mean license," Stallman said curtly.
"Yeah, license. Copyright. Whatever," I said, feeling
suddenly like a wounded tuna trailing a rich plume of
plasma in the water.
"Aw, why didn't you just fucking do what I told you to
do!" he shouted.
I must have been arguing on behalf of the publisher to
the very end, because in my notes I managed to save a
final Stallman chestnut: "I don't care. What they're
doing is evil. I can't support evil. Good-bye."
As soon as I put the phone down, my agent slid a
freshly poured Guinness to me. "I figured you might
need this," he said with a laugh. "I could see you
shaking there towards the end."
I was indeed shaking. The shaking wouldn't stop until
the Guinness was more than halfway gone. It felt weird,
hearing myself characterized as an emissary of "evil."
It felt weirder still, knowing that three months
before, I was sitting in an Oakland apartment trying to
come up with my next story idea. Now, I was sitting in
a part of the world I'd only known through rock songs,
taking meetings with publishing executives and drinking
beer with an agent I'd never even laid eyes on until
the day before. It was all too surreal, like watching
my life reflected back as a movie montage.
About that time, my internal absurdity meter kicked in.
The initial shaking gave way to convulsions of
laughter. To my agent, I must have looked like a
another fragile author undergoing an untimely emotional
breakdown. To me, I was just starting to appreciate the
cynical beauty of my situation. Deal or no deal, I
already had the makings of a pretty good story. It was
only a matter of finding a place to tell it. When my
laughing convulsions finally subsided, I held up my
drink in a toast.
"Welcome to the front lines, my friend," I said,
clinking pints with my agent. "Might as well enjoy it."
If this story really were a play, here's where it would
take a momentary, romantic interlude. Disheartened by
the tense nature of our meeting, Tracy invited Henning
and I to go out for drinks with her and some of her
coworkers. We left the bar on Third Ave., headed down
to the East Village, and caught up with Tracy and her friends.
Once there, I spoke with Tracy, careful to avoid shop
talk. Our conversation was pleasant, relaxed. Before
parting, we agreed to meet the next night. Once again,
the conversation was pleasant, so pleasant that the
Stallman e-book became almost a distant memory.
When I got back to Oakland, I called around to various
journalist friends and acquaintances. I recounted my
predicament. Most upbraided me for giving up too much
ground to Stallman in the preinterview negotiation. A
former j-school professor suggested I ignore Stallman's
"hypocrite" comment and just write the story. Reporters
who knew of Stallman's media-savviness expressed
sympathy but uniformly offered the same response: it's
your call.
I decided to put the book on the back burner. Even with
the interviews, I wasn't making much progress. Besides,
it gave me a chance to speak with Tracy without running
things past Henning first. By Christmas we had traded
visits: she flying out to the west coast once, me
flying out to New York a second time. The day before
New Year's Eve, I proposed. Deciding which coast to
live on, I picked New York. By February, I packed up my
laptop computer and all my research notes related to
the Stallman biography, and we winged our way to JFK
Airport. Tracy and I were married on May 11. So much
for failed book deals.
During the summer, I began to contemplate turning my
interview notes into a magazine article. Ethically, I
felt in the clear doing so, since the original
interview terms said nothing about traditional print
media. To be honest, I also felt a bit more comfortable
writing about Stallman after eight months of radio
silence. Since our telephone conversation in September,
I'd only received two emails from Stallman. Both
chastised me for using "Linux" instead of "GNU/Linux"
in a pair of articles for the web magazine Upside
Today. Aside from that, I had enjoyed the silence. In
June, about a week after the New York University
speech, I took a crack at writing a 5,000-word
magazine-length story about Stallman. This time, the
words flowed. The distance had helped restore my lost
sense of emotional perspective, I suppose.
In July, a full year after the original email from
Tracy, I got a call from Henning. He told me that
O'Reilly & Associates, a publishing house out of
Sebastopol, California, was interested in the running
the Stallman story as a biography. The news pleased me.
Of all the publishing houses in the world, O'Reilly,
the same company that had published Eric Raymond's The
Cathedral and the Bazaar, seemed the most sensitive to
the issues that had killed the earlier e-book. As a
reporter, I had relied heavily on the O'Reilly book
Open Sources as a historical reference. I also knew
that various chapters of the book, including a chapter
written by Stallman, had been published with copyright
notices that permitted redistribution. Such knowledge
would come in handy if the issue of electronic
publication ever came up again.
Sure enough, the issue did come up. I learned through
Henning that O'Reilly intended to publish the biography
both as a book and as part of its new Safari Tech Books
Online subscription service. The Safari user license
would involve special restrictions,1 Henning warned,
but O'Reilly was willing to allow for a copyright that
permitted users to copy and share and the book's text
regardless of medium. Basically, as author, I had the
choice between two licenses: the Open Publication
License or the GNU Free Documentation License.
I checked out the contents and background of each
license. The Open Publication License (OPL)See "The Open Publication License:
Draft v1.0" (June 8, 1999).
http://opencontent.org/openpub/
gives readers the right to reproduce and distribute a
work, in whole or in part, in any medium "physical or
electronic," provided the copied work retains the Open
Publication License. It also permits modification of a
work, provided certain conditions are met. Finally, the
Open Publication License includes a number of options,
which, if selected by the author, can limit the
creation of "substantively modified" versions or
book-form derivatives without prior author approval.
The GNU Free Documentation License (GFDL),See "The GNU Free Documentation
License: Version 1.1"
(March, 2000).
http://www.gnu.org/copyleft/fdl.html
meanwhile, permits the copying and distribution of a
document in any medium, provided the resulting work
carries the same license. It also permits the
modification of a document provided certain conditions.
Unlike the OPL, however, it does not give authors the
option to restrict certain modifications. It also does
not give authors the right to reject modifications that
might result in a competitive book product. It does
require certain forms of front- and back-cover
information if a party other than the copyright holder
wishes to publish more than 100 copies of a protected
work, however.
In the course of researching the licenses, I also made
sure to visit the GNU Project web page titled "Various
Licenses and Comments About Them."See
http://www.gnu.org/philosophy/license-list.html On that page, I
found a Stallman critique of the Open Publication
License. Stallman's critique related to the creation of
modified works and the ability of an author to select
either one of the OPL's options to restrict
modification. If an author didn't want to select either
option, it was better to use the GFDL instead, Stallman
noted, since it minimized the risk of the nonselected
options popping up in modified versions of a document.
The importance of modification in both licenses was a
reflection of their original purpose-namely, to give
software-manual owners a chance to improve their
manuals and publicize those improvements to the rest of
the community. Since my book wasn't a manual, I had
little concern about the modification clause in either
license. My only concern was giving users the freedom
to exchange copies of the book or make copies of the
content, the same freedom they would have enjoyed if
they purchased a hardcover book. Deeming either license
suitable for this purpose, I signed the O'Reilly
contract when it came to me.
Still, the notion of unrestricted modification
intrigued me. In my early negotiations with Tracy, I
had pitched the merits of a GPL-style license for the
e-book's content. At worst, I said, the license would
guarantee a lot of positive publicity for the e-book.
At best, it would encourage readers to participate in
the book-writing process. As an author, I was willing
to let other people amend my work just so long as my
name always got top billing. Besides, it might even be
interesting to watch the book evolve. I pictured later
editions looking much like online versions of the
Talmud, my original text in a central column surrounded
by illuminating, third-party commentary in the margins.
My idea drew inspiration from Project Xanadu
(http://www.xanadu.com/), the legendary software
concept originally conceived by Ted Nelson in 1960.
During the O'Reilly Open Source Conference in 1999, I
had seen the first demonstration of the project's open
source offshoot Udanax and had been wowed by the
result. In one demonstration sequence, Udanax displayed
a parent document and a derivative work in a similar
two-column, plain-text format. With a click of the
button, the program introduced lines linking each
sentence in the parent to its conceptual offshoot in
the derivative. An e-book biography of Richard M.
Stallman didn't have to be Udanax-enabled, but given
such technological possibilities, why not give users a
chance to play around?Anybody willing to "port" this book over to Udanax, the
free software version of Xanadu, will receive
enthusiastic support from me. To find out more about
this intriguing technology, visit
http://www.udanax.com/.
When Laurie Petrycki, my editor at O'Reilly, gave me a
choice between the OPL or the GFDL, I indulged the
fantasy once again. By September of 2001, the month I
signed the contract, e-books had become almost a dead
topic. Many publishing houses, Tracy's included, were
shutting down their e-book imprints for lack of
interest. I had to wonder. If these companies had
treated e-books not as a form of publication but as a
form of community building, would those imprints have survived?
After I signed the contract, I notified Stallman that
the book project was back on. I mentioned the choice
O'Reilly was giving me between the Open Publication
License and the GNU Free Documentation License. I told
him I was leaning toward the OPL, if only for the fact
I saw no reason to give O'Reilly's competitors a chance
to print the same book under a different cover.
Stallman wrote back, arguing in favor of the GFDL,
noting that O'Reilly had already used it several times
in the past. Despite the events of the past year, I
suggested a deal. I would choose the GFDL if it gave me
the possibility to do more interviews and if Stallman
agreed to help O'Reilly publicize the book. Stallman
agreed to participate in more interviews but said that
his participation in publicity-related events would
depend on the content of the book. Viewing this as only
fair, I set up an interview for December 17, 2001 in Cambridge.
I set up the interview to coincide with a business trip
my wife Tracy was taking to Boston. Two days before
leaving, Tracy suggested I invite Stallman out to dinner.
"After all," she said, "he is the one who brought us together."
I sent an email to Stallman, who promptly sent a return
email accepting the offer. When I drove up to Boston
the next day, I met Tracy at her hotel and hopped the T
to head over to MIT. When we got to Tech Square, I
found Stallman in the middle of a conversation just as
we knocked on the door.
"I hope you don't mind," he said, pulling the door open
far enough so that Tracy and I could just barely hear
Stallman's conversational counterpart. It was a
youngish woman, mid-20s I'd say, named Sarah.
"I took the liberty of inviting somebody else to have
dinner with us," Stallman said, matter-of-factly,
giving me the same cat-like smile he gave me back in
that Palo Alto restaurant.
To be honest, I wasn't too surprised. The news that
Stallman had a new female friend had reached me a few
weeks before, courtesy of Stallman's mother. "In fact,
they both went to Japan last month when Richard went
over to accept the Takeda Award," Lippman told me at
the time.Alas, I didn't find out about the Takeda Foundation's
decision to award Stallman, along with Linus Torvalds
and Ken Sakamura, with its first-ever award for
"Techno-Entrepreneurial Achievement for Social/Economic
Well-Being" until after Stallman had made the trip to
Japan to accept the award. For more information about
the award and its accompanying $1 million prize, visit
the Takeda site, http://www.takeda-foundation.jp/.
On the way over to the restaurant, I learned the
circumstances of Sarah and Richard's first meeting.
Interestingly, the circumstances were very familiar.
Working on her own fictional book, Sarah said she heard
about Stallman and what an interesting character he
was. She promptly decided to create a character in her
book on Stallman and, in the interests of researching
the character, set up an interview with Stallman.
Things quickly went from there. The two had been dating
since the beginning of 2001, she said.
"I really admired the way Richard built up an entire
political movement to address an issue of profound
personal concern," Sarah said, explaining her
attraction to Stallman.
My wife immediately threw back the question: "What was
the issue?"
"Crushing loneliness."
During dinner, I let the women do the talking and spent
most of the time trying to detect clues as to whether
the last 12 months had softened Stallman in any
significant way. I didn't see anything to suggest they
had. Although more flirtatious than I remembered-a
flirtatiousness spoiled somewhat by the number of times
Stallman's eyes seemed to fixate on my wife's
chest-Stallman retained the same general level of
prickliness. At one point, my wife uttered an emphatic
"God forbid" only to receive a typical Stallman rebuke.
"I hate to break it to you, but there is no God,"
Stallman said.
Afterwards, when the dinner was complete and Sarah had
departed, Stallman seemed to let his guard down a
little. As we walked to a nearby bookstore, he admitted
that the last 12 months had dramatically changed his
outlook on life. "I thought I was going to be alone
forever," he said. "I'm glad I was wrong."
Before parting, Stallman handed me his "pleasure card,"
a business card listing Stallman's address, phone
number, and favorite pastimes ("sharing good books,
good food and exotic music and dance") so that I might
set up a final interview.
<Graphic file:/home/craigm/books/free_ep10.png>
Stallman's "pleasure" card, handed to me the night of
our dinner.
The next day, over another meal of dim sum, Stallman
seemed even more lovestruck than the night before.
Recalling his debates with Currier House dorm maters
over the benefits and drawbacks of an immortality
serum, Stallman expressed hope that scientists might
some day come up with the key to immortality. "Now that
I'm finally starting to have happiness in my life, I
want to have more," he said.
When I mentioned Sarah's "crushing loneliness" comment,
Stallman failed to see a connection between loneliness
on a physical or spiritual level and loneliness on a
hacker level. "The impulse to share code is about
friendship but friendship at a much lower level," he
said. Later, however, when the subject came up again,
Stallman did admit that loneliness, or the fear of
perpetual loneliness, had played a major role in
fueling his determination during the earliest days of
the GNU Project.
"My fascination with computers was not a consequence of
anything else," he said. "I wouldn't have been less
fascinated with computers if I had been popular and all
the women flocked to me. However, it's certainly true
the experience of feeling I didn't have a home, finding
one and losing it, finding another and having it
destroyed, affected me deeply. The one I lost was the
dorm. The one that was destroyed was the AI Lab. The
precariousness of not having any kind of home or
community was very powerful. It made me want to fight
to get it back."
After the interview, I couldn't help but feel a certain
sense of emotional symmetry. Hearing Sarah describe
what attracted her to Stallman and hearing Stallman
himself describe the emotions that prompted him to take
up the free software cause, I was reminded of my own
reasons for writing this book. Since July, 2000, I have
learned to appreciate both the seductive and the
repellent sides of the Richard Stallman persona. Like
Eben Moglen before me, I feel that dismissing that
persona as epiphenomenal or distracting in relation to
the overall free software movement would be a grievous
mistake. In many ways the two are so mutually defining
as to be indistinguishable.
While I'm sure not every reader feels the same level of
affinity for Stallman-indeed, after reading this book,
some might feel zero affinity-I'm sure most will agree.
Few individuals offer as singular a human portrait as
Richard M. Stallman. It is my sincere hope that, with
this initial portrait complete and with the help of the
GFDL, others will feel a similar urge to add their own
perspective to that portrait.
Appendix A : Terminology
For the most part, I have chosen to use the term
GNU/Linux in reference to the free software operating
system and Linux when referring specifically to the
kernel that drives the operating system. The most
notable exception to this rule comes in Chapter 9 . In
the final part of that chapter, I describe the early
evolution of Linux as an offshoot of Minix. It is safe
to say that during the first two years of the project's
development, the operating system Torvalds and his
colleagues were working on bore little similarity to
the GNU system envisioned by Stallman, even though it
gradually began to share key components, such as the
GNU C Compiler and the GNU Debugger.
This decision further benefits from the fact that,
prior to 1993, Stallman saw little need to insist on credit.
Some might view the decision to use GNU/Linux for later
versions of the same operating system as arbitrary. I
would like to point out that it was in no way a
prerequisite for gaining Stallman's cooperation in the
making of this book. I came to it of my own accord,
partly because of the operating system's modular nature
and the community surrounding it, and partly because of
the apolitical nature of the Linux name. Given that
this is a biography of Richard Stallman, it seemed
inappropriate to define the operating system in
apolitical terms.
In the final phases of the book, when it became clear
that O'Reilly & Associates would be the book's
publisher, Stallman did make it a condition that I use
"GNU/Linux" instead of Linux if O'Reilly expected him
to provide promotional support for the book after
publication. When informed of this, I relayed my
earlier decision and left it up to Stallman to judge
whether the resulting book met this condition or not.
At the time of this writing, I have no idea what
Stallman's judgment will be.
A similar situation surrounds the terms "free software"
and "open source." Again, I have opted for the more
politically laden "free software" term when describing
software programs that come with freely copyable and
freely modifiable source code. Although more popular, I
have chosen to use the term "open source" only when
referring to groups and businesses that have championed
its usage. But for a few instances, the terms are
completely interchangeable, and in making this decision
I have followed the advice of Christine Peterson, the
person generally credited with coining the term. "The
`free software' term should still be used in
circumstances where it works better," Peterson writes.
"[`Open source'] caught on mainly because a new term
was greatly needed, not because it's ideal."
Appendix B Hack, Hackers, and Hacking
To understand the full meaning of the word " hacker,"
it helps to examine the word's etymology over the years.
The New Hacker Dictionary , an online compendium of
software-programmer jargon, officially lists nine
different connotations of the word "hack" and a similar
number for "hacker." Then again, the same publication
also includes an accompanying essay that quotes Phil
Agre, an MIT hacker who warns readers not to be fooled
by the word's perceived flexibility. "Hack has only one
meaning," argues Agre. "An extremely subtle and
profound one which defies articulation."
Regardless of the width or narrowness of the
definition, most modern hackers trace the word back to
MIT, where the term bubbled up as popular item of
student jargon in the early 1950s. In 1990 the MIT
Museum put together a journal documenting the hacking
phenomenon. According to the journal, students who
attended the institute during the fifties used the word
"hack" the way a modern student might use the word
"goof." Hanging a jalopy out a dormitory window was a
"hack," but anything harsh or malicious-e.g., egging a
rival dorm's windows or defacing a campus statue-fell
outside the bounds. Implicit within the definition of
"hack" was a spirit of harmless, creative fun.
This spirit would inspire the word's gerund form:
"hacking." A 1950s student who spent the better part of
the afternoon talking on the phone or dismantling a
radio might describe the activity as "hacking." Again,
a modern speaker would substitute the verb form of
"goof"-"goofing" or "goofing off"-to describe the same activity.
As the 1950s progressed, the word "hack" acquired a
sharper, more rebellious edge. The MIT of the 1950s was
overly competitive, and hacking emerged as both a
reaction to and extension of that competitive culture.
Goofs and pranks suddenly became a way to blow off
steam, thumb one's nose at campus administration, and
indulge creative thinking and behavior stifled by the
Institute's rigorous undergraduate curriculum. With its
myriad hallways and underground steam tunnels, the
Institute offered plenty of exploration opportunities
for the student undaunted by locked doors and "No
Trespassing" signs. Students began to refer to their
off-limits explorations as "tunnel hacking." Above
ground, the campus phone system offered similar
opportunities. Through casual experimentation and due
diligence, students learned how to perform humorous
tricks. Drawing inspiration from the more traditional
pursuit of tunnel hacking, students quickly dubbed this
new activity "phone hacking."
The combined emphasis on creative play and
restriction-free exploration would serve as the basis
for the future mutations of the hacking term. The first
self-described computer hackers of the 1960s MIT campus
originated from a late 1950s student group called the
Tech Model Railroad Club. A tight clique within the
club was the Signals and Power (S&P) Committee-the
group behind the railroad club's electrical circuitry
system. The system was a sophisticated assortment of
relays and switches similar to the kind that controlled
the local campus phone system. To control it, a member
of the group simply dialed in commands via a connected
phone and watched the trains do his bidding.
The nascent electrical engineers responsible for
building and maintaining this system saw their activity
as similar in spirit to phone hacking. Adopting the
hacking term, they began refining it even further. From
the S&P hacker point of view, using one less relay to
operate a particular stretch of track meant having one
more relay for future play. Hacking subtly shifted from
a synonym for idle play to a synonym for idle play that
improved the overall performance or efficiency of the
club's railroad system at the same time. Soon S&P
committee members proudly referred to the entire
activity of improving and reshaping the track's
underlying circuitry as "hacking" and to the people who
did it as "hackers."
Given their affinity for sophisticated electronics-not
to mention the traditional MIT-student disregard for
closed doors and "No Trespassing" signs-it didn't take
long before the hackers caught wind of a new machine on
campus. Dubbed the TX-0, the machine was one of the
first commercially marketed computers. By the end of
the 1950s, the entire S&P clique had migrated en masse
over to the TX-0 control room, bringing the spirit of
creative play with them. The wide-open realm of
computer programming would encourage yet another
mutation in etymology. "To hack" no longer meant
soldering unusual looking circuits, but cobbling
together software programs with little regard to
"official" methods or software-writing procedures. It
also meant improving the efficiency and speed of
already-existing programs that tended to hog up machine
resources. True to the word's roots, it also meant
writing programs that served no other purpose than to
amuse or entertain.
A classic example of this expanded hacking definition
is the game Spacewar, the first interactive video game.
Developed by MIT hackers in the early 1960s, Spacewar
had all the traditional hacking definitions: it was
goofy and random, serving little useful purpose other
than providing a nightly distraction for the dozen or
so hackers who delighted in playing it. From a software
perspective, however, it was a monumental testament to
innovation of programming skill. It was also completely
free. Because hackers had built it for fun, they saw no
reason to guard their creation, sharing it extensively
with other programmers. By the end of the 1960s,
Spacewar had become a favorite diversion for mainframe
programmers around the world.
This notion of collective innovation and communal
software ownership distanced the act of computer
hacking in the 1960s from the tunnel hacking and phone
hacking of the 1950s. The latter pursuits tended to be
solo or small-group activities. Tunnel and phone
hackers relied heavily on campus lore, but the
off-limits nature of their activity discouraged the
open circulation of new discoveries. Computer hackers,
on the other hand, did their work amid a scientific
field biased toward collaboration and the rewarding of
innovation. Hackers and "official" computer scientists
weren't always the best of allies, but in the rapid
evolution of the field, the two species of computer
programmer evolved a cooperative-some might say
symbiotic-relationship.
It is a testament to the original computer hackers'
prodigious skill that later programmers, including
Richard M. Stallman, aspired to wear the same hacker
mantle. By the mid to late 1970s, the term "hacker" had
acquired elite connotations. In a general sense, a
computer hacker was any person who wrote software code
for the sake of writing software code. In the
particular sense, however, it was a testament to
programming skill. Like the term "artist," the meaning
carried tribal overtones. To describe a fellow
programmer as hacker was a sign of respect. To describe
oneself as a hacker was a sign of immense personal
confidence. Either way, the original looseness of the
computer-hacker appellation diminished as computers
became more common.
As the definition tightened, "computer" hacking
acquired additional semantic overtones. To be a hacker,
a person had to do more than write interesting
software; a person had to belong to the hacker
"culture" and honor its traditions the same way a
medieval wine maker might pledge membership to a
vintners' guild. The social structure wasn't as rigidly
outlined as that of a guild, but hackers at elite
institutions such as MIT, Stanford, and Carnegie Mellon
began to speak openly of a "hacker ethic": the
yet-unwritten rules that governed a hacker's day-to-day
behavior. In the 1984 book Hackers, author Steven Levy,
after much research and consultation, codified the
hacker ethic as five core hacker tenets.
In many ways, the core tenets listed by Levy continue
to define the culture of computer hacking. Still, the
guild-like image of the hacker community was undermined
by the overwhelmingly populist bias of the software
industry. By the early 1980s, computers were popping up
everywhere, and programmers who once would have had to
travel to top-rank institutions or businesses just to
gain access to a machine suddenly had the ability to
rub elbows with major-league hackers via the ARPAnet.
The more these programmers rubbed elbows, the more they
began to appropriate the anarchic philosophies of the
hacker culture in places like MIT. Lost within the
cultural transfer, however, was the native MIT cultural
taboo against malicious behavior. As younger
programmers began employing their computer skills to
harmful ends-creating and disseminating computer
viruses, breaking into military computer systems,
deliberately causing machines such as MIT Oz, a popular
ARPAnet gateway, to crash-the term "hacker" acquired a
punk, nihilistic edge. When police and businesses began
tracing computer-related crimes back to a few renegade
programmers who cited convenient portions of the
hacking ethic in defense of their activities, the word
"hacker" began appearing in newspapers and magazine
stories in a negative light. Although books like
Hackers did much to document the original spirit of
exploration that gave rise to the hacking culture, for
most news reporters, "computer hacker" became a synonym
for "electronic burglar."
Although hackers have railed against this perceived
misusage for nearly two decades, the term's rebellious
connotations dating back to the 1950s make it hard to
discern the 15-year-old writing software programs that
circumvent modern encryption programs from the 1960s
college student, picking locks and battering down doors
to gain access to the lone, office computer terminal.
One person's creative subversion of authority is
another person's security headache, after all. Even so,
the central taboo against malicious or deliberately
harmful behavior remains strong enough that most
hackers prefer to use the term " cracker"-i.e., a
person who deliberately cracks a computer security
system to steal or vandalize data-to describe the
subset of hackers who apply their computing skills maliciously.
This central taboo against maliciousness remains the
primary cultural link between the notion of hacking in
the early 21st century and hacking in the 1950s. It is
important to note that, as the idea of computer hacking
has evolved over the last four decades, the original
notion of hacking-i.e., performing pranks or exploring
underground tunnels-remains intact. In the fall of
2000, the MIT Museum paid tradition to the Institute's
age-old hacking tradition with a dedicated exhibit, the
Hall of Hacks. The exhibit includes a number of
photographs dating back to the 1920s, including one
involving a mock police cruiser. In 1993, students paid
homage to the original MIT notion of hacking by placing
the same police cruiser, lights flashing, atop the
Institute's main dome. The cruiser's vanity license
plate read IHTFP, a popular MIT acronym with many
meanings. The most noteworthy version, itself dating
back to the pressure-filled world of MIT student life
in the 1950s, is "I hate this fucking place." In 1990,
however, the Museum used the acronym as a basis for a
journal on the history of hacks. Titled, The Institute
for Hacks Tomfoolery and Pranks, the journal offers an
adept summary of the hacking.
"In the culture of hacking, an elegant, simple creation
is as highly valued as it is in pure science," writes
Boston Globe reporter Randolph Ryan in a 1993 article
attached to the police car exhibit. "A Hack differs
from the ordinary college prank in that the event
usually requires careful planning, engineering and
finesse, and has an underlying wit and inventiveness,"
Ryan writes. "The unwritten rule holds that a hack
should be good-natured, non-destructive and safe. In
fact, hackers sometimes assist in dismantling their own
handiwork."
The urge to confine the culture of computer hacking
within the same ethical boundaries is well-meaning but
impossible. Although most software hacks aspire to the
same spirit of elegance and simplicity, the software
medium offers less chance for reversibility.
Dismantling a police cruiser is easy compared with
dismantling an idea, especially an idea whose time has
come. Hence the growing distinction between "black hat"
and "white hat"-i.e., hackers who turn new ideas toward
destructive, malicious ends versus hackers who turn new
ideas toward positive or, at the very least,
informative ends.
Once a vague item of obscure student jargon, the word
"hacker" has become a linguistic billiard ball, subject
to political spin and ethical nuances. Perhaps this is
why so many hackers and journalists enjoy using it.
Where that ball bounces next, however, is anybody's guess.
Appendix C GNU Free Documentation License (GFDL)
GNU Free Documentation License Version 1.1, March 2000
Copyright (C) 2000 Free Software Foundation, Inc. 59
Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim
copies of this license document, but changing it is not
allowed. PREAMBLE The purpose of this License is to
make a manual, textbook, or other written document
"free" in the sense of freedom: to assure everyone the
effective freedom to copy and redistribute it, with or
without modifying it, either commercially or
noncommercially. Secondarily, this License preserves
for the author and publisher a way to get credit for
their work, while not being considered responsible for
modifications made by others.
This License is a kind of "copyleft," which means that
derivative works of the document must themselves be
free in the same sense. It complements the GNU General
Public License, which is a copyleft license designed
for free software.
We have designed this License in order to use it for
manuals for free software, because free software needs
free documentation: a free program should come with
manuals providing the same freedoms that the software
does. But this License is not limited to software
manuals; it can be used for any textual work,
regardless of subject matter or whether it is published
as a printed book. We recommend this License
principally for works whose purpose is instruction or
reference. APPLICABILITY AND DEFINITIONS This License
applies to any manual or other work that contains a
notice placed by the copyright holder saying it can be
distributed under the terms of this License. The
"Document", below, refers to any such manual or work.
Any member of the public is a licensee, and is
addressed as "you."
A "Modified Version" of the Document means any work
containing the Document or a portion of it, either
copied verbatim, or with modifications and/or
translated into another language.
A "Secondary Section" is a named appendix or a
front-matter section of the Document that deals
exclusively with the relationship of the publishers or
authors of the Document to the Document's overall
subject (or to related matters) and contains nothing
that could fall directly within that overall subject.
(For example, if the Document is in part a textbook of
mathematics, a Secondary Section may not explain any
mathematics.) The relationship could be a matter of
historical connection with the subject or with related
matters, or of legal, commercial, philosophical,
ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections
whose titles are designated, as being those of
Invariant Sections, in the notice that says that the
Document is released under this License.
The "Cover Texts" are certain short passages of text
that are listed, as Front-Cover Texts or Back-Cover
Texts, in the notice that says that the Document is
released under this License.
A "Transparent" copy of the Document means a
machine-readable copy, represented in a format whose
specification is available to the general public, whose
contents can be viewed and edited directly and
straightforwardly with generic text editors or (for
images composed of pixels) generic paint programs or
(for drawings) some widely available drawing editor,
and that is suitable for input to text formatters or
for automatic translation to a variety of formats
suitable for input to text formatters. A copy made in
an otherwise Transparent file format whose markup has
been designed to thwart or discourage subsequent
modification by readers is not Transparent. A copy that
is not "Transparent" is called "Opaque."
Examples of suitable formats for Transparent copies
include plain ASCII without markup, Texinfo input
format, LaTeX input format, SGML or XML using a
publicly available DTD, and standard-conforming simple
HTML designed for human modification. Opaque formats
include PostScript, PDF, proprietary formats that can
be read and edited only by proprietary word processors,
SGML or XML for which the DTD and/or processing tools
are not generally available, and the machine-generated
HTML produced by some word processors for output
purposes only.
The "Title Page" means, for a printed book, the title
page itself, plus such following pages as are needed to
hold, legibly, the material this License requires to
appear in the title page. For works in formats which do
not have any title page as such, "Title Page" means the
text near the most prominent appearance of the work's
title, preceding the beginning of the body of the text.
VERBATIM COPYING You may copy and distribute the
Document in any medium, either commercially or
noncommercially, provided that this License, the
copyright notices, and the license notice saying this
License applies to the Document are reproduced in all
copies, and that you add no other conditions whatsoever
to those of this License. You may not use technical
measures to obstruct or control the reading or further
copying of the copies you make or distribute. However,
you may accept compensation in exchange for copies. If
you distribute a large enough number of copies you must
also follow the conditions in section 3.
You may also lend copies, under the same conditions
stated above, and you may publicly display copies.
COPYING IN QUANTITY If you publish printed copies of
the Document numbering more than 100, and the
Document's license notice requires Cover Texts, you
must enclose the copies in covers that carry, clearly
and legibly, all these Cover Texts: Front-Cover Texts
on the front cover, and Back-Cover Texts on the back
cover. Both covers must also clearly and legibly
identify you as the publisher of these copies. The
front cover must present the full title with all words
of the title equally prominent and visible. You may add
other material on the covers in addition. Copying with
changes limited to the covers, as long as they preserve
the title of the Document and satisfy these conditions,
can be treated as verbatim copying in other respects.
If the required texts for either cover are too
voluminous to fit legibly, you should put the first
ones listed (as many as fit reasonably) on the actual
cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the
Document numbering more than 100, you must either
include a machine-readable Transparent copy along with
each Opaque copy, or state in or with each Opaque copy
a publicly-accessible computer-network location
containing a complete Transparent copy of the Document,
free of added material, which the general network-using
public has access to download anonymously at no charge
using public-standard network protocols. If you use the
latter option, you must take reasonably prudent steps,
when you begin distribution of Opaque copies in
quantity, to ensure that this Transparent copy will
remain thus accessible at the stated location until at
least one year after the last time you distribute an
Opaque copy (directly or through your agents or
retailers) of that edition to the public.
It is requested, but not required, that you contact the
authors of the Document well before redistributing any
large number of copies, to give them a chance to
provide you with an updated version of the Document.
MODIFICATIONS You may copy and distribute a Modified
Version of the Document under the conditions of
sections 2 and 3 above, provided that you release the
Modified Version under precisely this License, with the
Modified Version filling the role of the Document, thus
licensing distribution and modification of the Modified
Version to whoever possesses a copy of it. In addition,
you must do these things in the Modified Version:
1. Use in the Title Page (and on the covers, if any) a
title distinct from that of the Document, and from
those of previous versions (which should, if there were
any, be listed in the History section of the Document).
You may use the same title as a previous version if the
original publisher of that version gives permission.
2. List on the Title Page, as authors, one or more
persons or entities responsible for authorship of the
modifications in the Modified Version, together with at
least five of the principal authors of the Document
(all of its principal authors, if it has less than five).
3. State on the Title page the name of the publisher of
the Modified Version, as the publisher.
4. Preserve all the copyright notices of the Document.
5. Add an appropriate copyright notice for your
modifications adjacent to the other copyright notices.
6. Include, immediately after the copyright notices, a
license notice giving the public permission to use the
Modified Version under the terms of this License, in
the form shown in the Addendum below.
7. Preserve in that license notice the full lists of
Invariant Sections and required Cover Texts given in
the Document's license notice.
8. Include an unaltered copy of this License.
9. Preserve the section entitled "History," and its
title, and add to it an item stating at least the
title, year, new authors, and publisher of the Modified
Version as given on the Title Page. If there is no
section entitled "History" in the Document, create one
stating the title, year, authors, and publisher of the
Document as given on its Title Page, then add an item
describing the Modified Version as stated in the
previous sentence.
10. Preserve the network location, if any, given in the
Document for public access to a Transparent copy of the
Document, and likewise the network locations given in
the Document for previous versions it was based on.
These may be placed in the "History" section. You may
omit a network location for a work that was published
at least four years before the Document itself, or if
the original publisher of the version it refers to
gives permission.
11. In any section entitled "Acknowledgements" or
"Dedications," preserve the section's title, and
preserve in the section all the substance and tone of
each of the contributor acknowledgements and/or
dedications given therein.
12. Preserve all the Invariant Sections of the
Document, unaltered in their text and in their titles.
Section numbers or the equivalent are not considered
part of the section titles.
13. Delete any section entitled "Endorsements." Such a
section may not be included in the Modified Version.
14. Do not retitle any existing section as
"Endorsements" or to conflict in title with any
Invariant Section.
If the Modified Version includes new front-matter
sections or appendices that qualify as Secondary
Sections and contain no material copied from the
Document, you may at your option designate some or all
of these sections as invariant. To do this, add their
titles to the list of Invariant Sections in the
Modified Version's license notice. These titles must be
distinct from any other section titles.
You may add a section entitled "Endorsements," provided
it contains nothing but endorsements of your Modified
Version by various parties-for example, statements of
peer review or that the text has been approved by an
organization as the authoritative definition of a standard.
You may add a passage of up to five words as a
Front-Cover Text, and a passage of up to 25 words as a
Back-Cover Text, to the end of the list of Cover Texts
in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be
added by (or through arrangements made by) any one
entity. If the Document already includes a cover text
for the same cover, previously added by you or by
arrangement made by the same entity you are acting on
behalf of, you may not add another; but you may replace
the old one, on explicit permission from the previous
publisher that added the old one.
The author(s) and publisher(s) of the Document do not
by this License give permission to use their names for
publicity for or to assert or imply endorsement of any
Modified Version. COMBINING DOCUMENTS You may combine
the Document with other documents released under this
License, under the terms defined in section 4 above for
modified versions, provided that you include in the
combination all of the Invariant Sections of all of the
original documents, unmodified, and list them all as
Invariant Sections of your combined work in its license notice.
The combined work need only contain one copy of this
License, and multiple identical Invariant Sections may
be replaced with a single copy. If there are multiple
Invariant Sections with the same name but different
contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of
the original author or publisher of that section if
known, or else a unique number. Make the same
adjustment to the section titles in the list of
Invariant Sections in the license notice of the
combined work.
In the combination, you must combine any sections
entitled "History" in the various original documents,
forming one section entitled "History"; likewise
combine any sections entitled "Acknowledgements," and
any sections entitled "Dedications." You must delete
all sections entitled "Endorsements." COLLECTIONS OF
DOCUMENTS You may make a collection consisting of the
Document and other documents released under this
License, and replace the individual copies of this
License in the various documents with a single copy
that is included in the collection, provided that you
follow the rules of this License for verbatim copying
of each of the documents in all other respects.
You may extract a single document from such a
collection, and distribute it individually under this
License, provided you insert a copy of this License
into the extracted document, and follow this License in
all other respects regarding verbatim copying of that
document. AGGREGATION WITH INDEPENDENT WORKS A
compilation of the Document or its derivatives with
other separate and independent documents or works, in
or on a volume of a storage or distribution medium,
does not as a whole count as a Modified Version of the
Document, provided no compilation copyright is claimed
for the compilation. Such a compilation is called an
"aggregate," and this License does not apply to the
other self-contained works thus compiled with the
Document, on account of their being thus compiled, if
they are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is
applicable to these copies of the Document, then if the
Document is less than one quarter of the entire
aggregate, the Document's Cover Texts may be placed on
covers that surround only the Document within the
aggregate. Otherwise they must appear on covers around
the whole aggregate. TRANSLATION Translation is
considered a kind of modification, so you may
distribute translations of the Document under the terms
of section 4. Replacing Invariant Sections with
translations requires special permission from their
copyright holders, but you may include translations of
some or all Invariant Sections in addition to the
original versions of these Invariant Sections. You may
include a translation of this License provided that you
also include the original English version of this
License. In case of a disagreement between the
translation and the original English version of this
License, the original English version will prevail.
TERMINATION You may not copy, modify, sublicense, or
distribute the Document except as expressly provided
for under this License. Any other attempt to copy,
modify, sublicense or distribute the Document is void,
and will automatically terminate your rights under this
License. However, parties who have received copies, or
rights, from you under this License will not have their
licenses terminated so long as such parties remain in
full compliance. FUTURE REVISIONS OF THIS LICENSE The
Free Software Foundation may publish new, revised
versions of the GNU Free Documentation License from
time to time. Such new versions will be similar in
spirit to the present version, but may differ in detail
to address new problems or concerns. See
http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing
version number. If the Document specifies that a
particular numbered version of this License "or any
later version" applies to it, you have the option of
following the terms and conditions either of that
specified version or of any later version that has been
published (not as a draft) by the Free Software
Foundation. If the Document does not specify a version
number of this License, you may choose any version ever
published (not as a draft) by the Free Software
Foundation. ADDENDUM: How to Use This License for Your
Documents To use this License in a document you have
written, include a copy of the License in the document
and put the following copyright and license notices
just after the title page: Copyright (C) YEAR YOUR
NAME.Permission is granted to copy, distribute and/or
modify this document under the terms of the GNU Free
Documentation License, Version 1.1 or any later version
published by the Free Software Foundation; with the
Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover
Texts being LIST. A copy of the license is included in
the section entitled "GNU Free Documentation License".
If you have no Invariant Sections, write "with no
Invariant Sections" instead of saying which ones are
invariant. If you have no Front-Cover Texts, write "no
Front-Cover Texts" instead of "Front-Cover Texts being
LIST"; likewise for Back-Cover Texts.
If your document contains nontrivial examples of
program code, we recommend releasing these examples in
parallel under your choice of free software license,
such as the GNU General Public License, to permit their
use in free software.