While in California, Raymond also managed to squeeze in

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.

Free as in Freedom: Richard Stallman's Crusade for Free Software · 第 20 / 20 章