Free as in Freedom: Richard Stallman's Crusade for Free Software Part 1

Free as in Freedom: Richard Stallman's Crusade for Free Software.

by Sam Williams.

Preface

The work of Richard M. Stallman literally speaks for itself. From the doc.u.mented source code to the published papers to the recorded speeches, few people have expressed as much willingness to lay their thoughts and their work on the line.

Such openness-if one can pardon a momentary un-Stallman adjective-is refres.h.i.+ng. After all, we live in a society that treats information, especially personal information, as a valuable commodity. The question quickly arises. Why would anybody want to part with so much information and yet appear to demand nothing in return?

As we shall see in later chapters, Stallman does not part with his words or his work altruistically. Every program, speech, and on-the-record bon mot comes with a price, albeit not the kind of price most people are used to paying.

I bring this up not as a warning, but as an admission.

As a person who has spent the last year digging up facts on Stallman's personal history, it's more than a little intimidating going up against the Stallman oeuvre. "Never pick a fight with a man who buys his ink by the barrel," goes the old Mark Twain adage. In the case of Stallman, never attempt the definitive biography of a man who trusts his every thought to the public record.

For the readers who have decided to trust a few hours of their time to exploring this book, I can confidently state that there are facts and quotes in here that one won't find in any Slashdot story or Google search.

Gaining access to these facts involves paying a price, however. In the case of the book version, you can pay for these facts the traditional manner, i.e., by purchasing the book. In the case of the electronic versions, you can pay for these facts in the free software manner. Thanks to the folks at O'Reilly & a.s.sociates, this book is being distributed under the GNU Free Doc.u.mentation License, meaning you can help to improve the work or create a personalized version and release that version under the same license.

If you are reading an electronic version and prefer to accept the latter payment option, that is, if you want to improve or expand this book for future readers, I welcome your input. Starting in June, 2002, I will be publis.h.i.+ng a bare bones HTML version of the book on the web site, http://www.faifzilla.org. My aim is to update it regularly and expand the Free as in Freedom story as events warrant. If you choose to take the latter course, please review Appendix C of this book. It provides a copy of your rights under the GNU Free Doc.u.mentation License.

For those who just plan to sit back and read, online or elsewhere, I consider your attention an equally valuable form of payment. Don't be surprised, though, if you, too, find yourself looking for other ways to reward the good will that made this work possible.

One final note: this is a work of journalism, but it is also a work of technical doc.u.mentation. In the process of writing and editing this book, the editors and I have weighed the comments and factual input of various partic.i.p.ants in the story, including Richard Stallman himself. We realize there are many technical details in this story that may benefit from additional or refined information. As this book is released under the GFDL, we are accepting patches just like we would with any free software program. Accepted changes will be posted electronically and will eventually be incorporated into future printed versions of this work. If you would like to contribute to the further improvement of this book, you can reach me at [email protected] Comments and Questions Please address comments and questions concerning this book to the publisher: O'Reilly & a.s.sociates, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 (800) 998-9938 (in the United States or Canada) (707) 829-0515 (international/local) (707) 829-0104 (fax) There is a web page for this book, which lists errata, examples, or any additional information. The site also includes a link to a forum where you can discuss the book with the author and other readers. You can access this site at: http://www.oreilly.com/catalog/freedom/ To comment or ask technical questions about this book, send email to: [email protected] For more information about books, conferences, Resource Centers, and the O'Reilly Network, see the O'Reilly web site at: http://www.oreilly.com Acknowledgments Special thanks to Henning Gutmann for sticking by this book. Special thanks to Aaron Oas for suggesting the idea to Tracy in the first place. Thanks to Laurie Petrycki, Jeffrey Holcomb, and all the others at O'Reilly & a.s.sociates.

Thanks to Tim O'Reilly for backing this book. Thanks to all the first-draft reviewers: Bruce Perens, Eric Raymond, Eric Allman, Jon Orwant, Julie and Gerald Jay Sussman, Hal Abelson, and Guy Steele. I hope you enjoy this typo-free version. Thanks to Alice Lippman for the interviews, cookies, and photographs. Thanks to my family, Steve, Jane, Tish, and Dave. And finally, last but not least: thanks to Richard Stallman for having the guts and endurance to "show us the code."

Sam Williams

For Want of a Printer

I fear the Greeks. Even when they bring gifts.

---Virgil The Aeneid

The new printer was jammed, again.

Richard M. Stallman, a staff software programmer at the Ma.s.sachusetts Inst.i.tute of Technology's Artificial Intelligence Laboratory (AI Lab), discovered the malfunction the hard way. An hour after sending off a 50-page file to the office laser printer, Stallman, 27, broke off a productive work session to retrieve his doc.u.ments. Upon arrival, he found only four pages in the printer's tray. To make matters even more frustrating, the four pages belonged to another user, meaning that Stallman's print job and the unfinished portion of somebody else's print job were still trapped somewhere within the electrical plumbing of the lab's computer network.

Waiting for machines is an occupational hazard when you're a software programmer, so Stallman took his frustration with a grain of salt. Still, the difference between waiting for a machine and waiting on a machine is a sizable one. It wasn't the first time he'd been forced to stand over the printer, watching pages print out one by one. As a person who spent the bulk of his days and nights improving the efficiency of machines and the software programs that controlled them, Stallman felt a natural urge to open up the machine, look at the guts, and seek out the root of the problem.

Unfortunately, Stallman's skills as a computer programmer did not extend to the mechanical-engineering realm. As freshly printed doc.u.ments poured out of the machine, Stallman had a chance to reflect on other ways to circ.u.mvent the printing jam problem.

How long ago had it been that the staff members at the AI Lab had welcomed the new printer with open arms?

Stallman wondered. The machine had been a donation from the Xerox Corporation. A cutting edge prototype, it was a modified version of the popular Xerox photocopier.

Only instead of making copies, it relied on software data piped in over a computer network to turn that data into professional-looking doc.u.ments. Created by engineers at the world-famous Xerox Palo Alto Research Facility, it was, quite simply, an early taste of the desktop-printing revolution that would seize the rest of the computing industry by the end of the decade.

Driven by an instinctual urge to play with the best new equipment, programmers at the AI Lab promptly integrated the new machine into the lab's sophisticated computing infrastructure. The results had been immediately pleasing. Unlike the lab's old laser printer, the new Xerox machine was fast. Pages came flying out at a rate of one per second, turning a 20-minute print job into a 2-minute print job. The new machine was also more precise. Circles came out looking like circles, not ovals. Straight lines came out looking like straight lines, not low-amplitude sine waves.

It was, for all intents and purposes, a gift too good to refuse.

It wasn't until a few weeks after its arrival that the machine's flaws began to surface. Chief among the drawbacks was the machine's inherent susceptibility to paper jams. Engineering-minded programmers quickly understood the reason behind the flaw. As a photocopier, the machine generally required the direct oversight of a human operator. Figuring that these human operators would always be on hand to fix a paper jam, if it occurred, Xerox engineers had devoted their time and energies to eliminating other pesky problems.

In engineering terms, user diligence was built into the system.

In modifying the machine for printer use, Xerox engineers had changed the user-machine relations.h.i.+p in a subtle but profound way. Instead of making the machine subservient to an individual human operator, they made it subservient to an entire networked population of human operators. Instead of standing directly over the machine, a human user on one end of the network sent his print command through an extended bucket-brigade of machines, expecting the desired content to arrive at the targeted destination and in proper form. It wasn't until he finally went to check up on the final output that he realized how little of the desired content had made it through.

Stallman himself had been of the first to identify the problem and the first to suggest a remedy. Years before, when the lab was still using its old printer, Stallman had solved a similar problem by opening up the software program that regulated the printer on the lab's PDP-11 machine. Stallman couldn't eliminate paper jams, but he could insert a software command that ordered the PDP-11 to check the printer periodically and report back to the PDP-10, the lab's central computer. To ensure that one user's negligence didn't bog down an entire line of print jobs, Stallman also inserted a software command that instructed the PDP-10 to notify every user with a waiting print job that the printer was jammed. The notice was simple, something along the lines of "The printer is jammed, please fix it," and because it went out to the people with the most pressing need to fix the problem, chances were higher that the problem got fixed in due time.

As fixes go, Stallman's was oblique but elegant. It didn't fix the mechanical side of the problem, but it did the next best thing by closing the information loop between user and machine. Thanks to a few additional lines of software code, AI Lab employees could eliminate the 10 or 15 minutes wasted each week in running back and forth to check on the printer. In programming terms, Stallman's fix took advantage of the amplified intelligence of the overall network.

"If you got that message, you couldn't a.s.sume somebody else would fix it," says Stallman, recalling the logic.

"You had to go to the printer. A minute or two after the printer got in trouble, the two or three people who got messages arrive to fix the machine. Of those two or three people, one of them, at least, would usually know how to fix the problem."

Such clever fixes were a trademark of the AI Lab and its indigenous population of programmers. Indeed, the best programmers at the AI Lab disdained the term programmer, preferring the more slangy occupational t.i.tle of hacker instead. The job t.i.tle covered a host of activities-everything from creative mirth making to the improvement of existing software and computer systems. Implicit within the t.i.tle, however, was the old-fas.h.i.+oned notion of Yankee ingenuity. To be a hacker, one had to accept the philosophy that writing a software program was only the beginning. Improving a program was the true test of a hacker's skills.For more on the term "hacker,"

see Appendix B.

Such a philosophy was a major reason why companies like Xerox made it a policy to donate their machines and software programs to places where hackers typically congregated. If hackers improved the software, companies could borrow back the improvements, incorporating them into update versions for the commercial marketplace. In corporate terms, hackers were a leveragable community a.s.set, an auxiliary research-and-development division available at minimal cost.

It was because of this give-and-take philosophy that when Stallman spotted the print-jam defect in the Xerox laser printer, he didn't panic. He simply looked for a way to update the old fix or " hack" for the new system. In the course of looking up the Xerox laser-printer software, however, Stallman made a troubling discovery. The printer didn't have any software, at least nothing Stallman or a fellow programmer could read. Until then, most companies had made it a form of courtesy to publish source-code files-readable text files that doc.u.mented the individual software commands that told a machine what to do. Xerox, in this instance, had provided software files in precompiled, or binary, form. Programmers were free to open the files up if they wanted to, but unless they were an expert in deciphering an endless stream of ones and zeroes, the resulting text was pure gibberish.

Although Stallman knew plenty about computers, he was not an expert in translating binary files. As a hacker, however, he had other resources at his disposal. The notion of information sharing was so central to the hacker culture that Stallman knew it was only a matter of time before some hacker in some university lab or corporate computer room proffered a version of the laser-printer source code with the desired source-code files.

After the first few printer jams, Stallman comforted himself with the memory of a similar situation years before. The lab had needed a cross-network program to help the PDP-11 work more efficiently with the PDP-10.

The lab's hackers were more than up to the task, but Stallman, a Harvard alumnus, recalled a similar program written by programmers at the Harvard computer-science department. The Harvard computer lab used the same model computer, the PDP-10, albeit with a different operating system. The Harvard computer lab also had a policy requiring that all programs installed on the PDP-10 had to come with published source-code files.

Taking advantage of his access to the Harvard computer lab, Stallman dropped in, made a copy of the cross-network source code, and brought it back to the AI Lab. He then rewrote the source code to make it more suitable for the AI Lab's operating system. With no muss and little fuss, the AI Lab sh.o.r.ed up a major gap in its software infrastructure. Stallman even added a few features not found in the original Harvard program, making the program even more useful. "We wound up using it for several years," Stallman says.

From the perspective of a 1970s-era programmer, the transaction was the software equivalent of a neighbor stopping by to borrow a power tool or a cup of sugar from a neighbor. The only difference was that in borrowing a copy of the software for the AI Lab, Stallman had done nothing to deprive Harvard hackers the use of their original program. If anything, Harvard hackers gained in the process, because Stallman had introduced his own additional features to the program, features that hackers at Harvard were perfectly free to borrow in return. Although n.o.body at Harvard ever came over to borrow the program back, Stallman does recall a programmer at the private engineering firm, Bolt, Beranek & Newman, borrowing the program and adding a few additional features, which Stallman eventually reintegrated into the AI Lab's own source-code archive.

"A program would develop the way a city develops," says Stallman, recalling the software infrastructure of the AI Lab. "Parts would get replaced and rebuilt. New things would get added on. But you could always look at a certain part and say, 'Hmm, by the style, I see this part was written back in the early 60s and this part was written in the mid-1970s.'"

Through this simple system of intellectual accretion, hackers at the AI Lab and other places built up robust creations. On the west coast, computer scientists at UC Berkeley, working in cooperation with a few low-level engineers at AT&T, had built up an entire operating system using this system. Dubbed Unix, a play on an older, more academically respectable operating system called Multics, the software system was available to any programmer willing to pay for the cost of copying the program onto a new magnetic tape and s.h.i.+pping it.

Not every programmer partic.i.p.ating in this culture described himself as a hacker, but most shared the sentiments of Richard M. Stallman. If a program or software fix was good enough to solve your problems, it was good enough to solve somebody else's problems. Why not share it out of a simple desire for good karma?

The fact that Xerox had been unwilling to share its source-code files seemed a minor annoyance at first. In tracking down a copy of the source-code files, Stallman says he didn't even bother contacting Xerox. "They had already given us the laser printer," Stallman says.

"Why should I bug them for more?"

When the desired files failed to surface, however, Stallman began to grow suspicious. The year before, Stallman had experienced a blow up with a doctoral student at Carnegie Mellon University. The student, Brian Reid, was the author of a useful text-formatting program dubbed Scribe. One of the first programs that gave a user the power to define fonts and type styles when sending a doc.u.ment over a computer network, the program was an early harbinger of HTML, the lingua franca of the World Wide Web. In 1979, Reid made the decision to sell Scribe to a Pittsburgh-area software company called Unilogic. His graduate-student career ending, Reid says he simply was looking for a way to unload the program on a set of developers that would take pains to keep it from slipping into the public domain. To sweeten the deal, Reid also agreed to insert a set of time-dependent functions- "time bombs" in software-programmer parlance-that deactivated freely copied versions of the program after a 90-day expiration date. To avoid deactivation, users paid the software company, which then issued a code that defused the internal time-bomb feature.

For Reid, the deal was a win-win. Scribe didn't fall into the public domain, and Unilogic recouped on its investment. For Stallman, it was a betrayal of the programmer ethos, pure and simple. Instead of honoring the notion of share-and-share alike, Reid had inserted a way for companies to compel programmers to pay for information access.

As the weeks pa.s.sed and his attempts to track down Xerox laser-printer source code hit a brick wall, Stallman began to sense a similar money-for-code scenario at work. Before Stallman could do or say anything about it, however, good news finally trickled in via the programmer grapevine. Word had it that a scientist at the computer-science department at Carnegie Mellon University had just departed a job at the Xerox Palo Alto Research Center. Not only had the scientist worked on the laser printer in question, but according to rumor, he was still working on it as part of his research duties at Carnegie Mellon.

Casting aside his initial suspicion, Stallman made a firm resolution to seek out the person in question during his next visit to the Carnegie Mellon campus.

He didn't have to wait long. Carnegie Mellon also had a lab specializing in artificial-intelligence research, and within a few months, Stallman had a business-related reason to visit the Carnegie Mellon campus. During that visit, he made sure to stop by the computer-science department. Department employees directed him to the office of the faculty member leading the Xerox project. When Stallman reached the office, he found the professor working there.

In true engineer-to-engineer fas.h.i.+on, the conversation was cordial but blunt. After briefly introducing himself as a visitor from MIT, Stallman requested a copy of the laser-printer source code so that he could port it to the PDP-11. To his surprise, the professor refused to grant his request.

"He told me that he had promised not to give me a copy," Stallman says.

Memory is a funny thing. Twenty years after the fact, Stallman's mental history tape is notoriously blank in places. Not only does he not remember the motivating reason for the trip or even the time of year during which he took it, he also has no recollection of the professor or doctoral student on the other end of the conversation. According to Reid, the person most likely to have fielded Stallman's request is Robert Sproull, a former Xerox PARC researcher and current director of Sun Laboratories, a research division of the computer-technology conglomerate Sun Microsystems.