Two Bits Part 6

EMACS, the Extensible, Customizable, Self-doc.u.menting, Real-time Display Editor.

EMACS is a text editor; it is also something like a religion. As one of the two most famous text editors, it is frequently lauded by its devoted users and attacked by detractors who prefer its compet.i.tor (Bill Joy's vi, also created in the late 1970s). EMACS is more than just a tool for writing text; for many programmers, it was (and still is) the princ.i.p.al interface to the operating system. For instance, it allows a programmer not only to write a program but also to debug it, to compile it, to run it, and to e-mail it to another user, all from within the same interface. What's more, it allows users to quickly and easily write extensions to EMACS itself, extensions that automate frequent tasks and in turn become core features of the software. It can do almost anything, but it can also frustrate almost anyone. The name itself is taken from its much admired extensibility: EMACS stands for "editing macros" because it allows programmers to quickly record a series of commands and bundle them into a macro that can be called with a simple key combination. In fact, it was one of the first editors (if not the first) to take advantage of keys like ctrl and meta, as in the now ubiquitous ctrl-S familiar to users of non-free word processors like Microsoft Word.

Appreciate the innovation represented by EMACS: before the UNIX-dominated minicomputer era, there were very few programs for directly manipulating text on a display. To conceive of source code as independent of a program running on a machine meant first conceiving of it as typed, printed, or hand-scrawled code which programmers would scrutinize in its more tangible, paper-based form. Editors that allowed programmers to display the code in front of them on a screen, to manipulate it directly, and to save changes to those files were an innovation of the mid- to late 1960s and were not widespread until the mid-1970s (and this only for bleeding-edge academics and computer corporations). Along with a few early editors, such as QED (originally created by Butler Lampson and Peter Deutsch, and rewritten for UNIX by Ken Thompson), one of the most famous of these was TECO (text editor and corrector), written by Dan Murphy for DEC's PDP-1 computer in 196263. Over the years, TECO was transformed (ported and extended) to a wide variety of machines, including machines at Berkeley and MIT, and to other DEC hardware and operating systems. By the early 1970s, there was a version of TECO running on the Incompatible Time-sharing System (ITS), the system in use at MIT's Artificial Intelligence (AI) Lab, and it formed the basis for EMACS. (Thus, EMACS was itself conceived of as a series of macros for a separate editor: Editing MACroS for TECO.) Like all projects on ITS at the AI Lab, many people contributed to the extension and maintenance of EMACS (including Guy Steele, Dave Moon, Richard Greenblatt, and Charles Frankston), but there is a clear recognition that Stallman made it what it was. The earliest AI Lab memo on EMACS, by Eugene Ciccarelli, says: "Finally, of all the people who have contributed to the development of EMACS, and the TECO behind it, special mention and appreciation go to Richard M. Stallman. He not only gave TECO the power and generality it has, but brought together the good ideas of many different Teco-function packages, added a tremendous amount of new ideas and environment, and created EMACS. Personally one of the joys of my avocational life has been writing Teco/EMACS functions; what makes this fun and not painful is the rich set of tools to work with, all but a few of which have an 'RMS' chiseled somewhere on them."10 At this point, in 1978, EMACS lived largely on ITS, but its reputation soon spread, and it was ported to DEC's TOPS-20 (Twenex) operating system and rewritten for Multics and the MIT's LISP machine, on which it was called EINE (Eine Is Not EMACS), and which was followed by ZWEI (Zwei Was Eine Initially).

The proliferation of EMACS was both pleasing and frustrating to Stallman, since it meant that the work fragmented into different projects, each of them EMACS-like, rather than building on one core project, and in a 1981 report he said, "The proliferation of such superficial facsimiles of EMACS has an unfortunate confusing effect: their users, not knowing that they are using an imitation of EMACS and never having seen EMACS itself, are led to believe they are enjoying all the advantages of EMACS. Since any real-time display editor is a tremendous improvement over what they probably had before, they believe this readily. To prevent such confusion, we urge everyone to refer to a nonextensible imitation of EMACS as an 'ersatz EMACS.' "11 Thus, while EMACS in its specific form on ITS was a creation of Stallman, the idea of EMACS or of any "real-time display editor" was proliferating in different forms and on different machines. The porting of EMACS, like the porting of UNIX, was facilitated by both its conceptual design integrity and its widespread availability.

The phrase "nonextensible imitation" captures the combination of design philosophy and moral philosophy that EMACS represented. Extensibility was not just a useful feature for the individual computer user; it was a way to make the improvements of each new user easily available equally to all by providing a standard way for users to add extensions and to learn how to use new extensions that were added (the "self-doc.u.menting" feature of the system). The program had a conceptual integrity that was compromised when it was copied imperfectly. EMACS has a modular, extensible design that by its very nature invites users to contribute to it, to extend it, and to make it perform all manner of tasks-to literally copy and modify it, instead of imitating it. For Stallman, this was not only a fantastic design for a text editor, but an expression of the way he had always done things in the small-scale setting of the AI Lab. The story of Stallman's moral commitments stresses his resistance to secrecy in software production, and EMACS is, both in its design and in Stallman's distribution of it an example of this resistance.

Not everyone shared Stallman's sense of communal order, however. In order to facilitate the extension of EMACS through sharing, Stallman started something he called the "EMACS commune." At the end of the 1981 report-"EMACS: The Extensible, Customizable Self-doc.u.menting Display Editor," dated 26 March-he explained the terms of distribution for EMACS: "It is distributed on a basis of communal sharing, which means that all improvements must be given back to me to be incorporated and distributed. Those who are interested should contact me. Further information about how EMACS works is available in the same way."12 In another report, intended as a user's manual for EMACS, Stallman gave more detailed and slightly more colorful instructions: EMACS does not cost anything; instead, you are joining the EMACS software-sharing commune. The conditions of membership are that you must send back any improvements you make to EMACS, including any libraries you write, and that you must not redistribute the system except exactly as you got it, complete. (You can also distribute your customizations, separately.) Please do not attempt to get a copy of EMACS, for yourself or anyone else, by dumping it off of your local system. It is almost certain to be incomplete or inconsistent. It is pathetic to hear from sites that received incomplete copies lacking the sources [source code], asking me years later whether sources are available. (All sources are distributed, and should be on line at every site so that users can read them and copy code from them). If you wish to give away a copy of EMACS, copy a distribution tape from MIT, or mail me a tape and get a new one.13 Because EMACS was so widely admired and respected, Stallman had a certain amount of power over this commune. If it had been an obscure, nonextensible tool, useful for a single purpose, no one would have heeded such demands, but because EMACS was by nature the kind of tool that was both useful for all kinds of tasks and customizable for specific ones, Stallman was not the only person who benefited from this communal arrangement. Two disparate sites may well have needed the same macro extension, and therefore many could easily see the social benefit in returning extensions for inclusion, as well as in becoming a kind of co-developer of such a powerful system. As a result, the demands of the EMACS commune, while unusual and autocratic, were of obvious value to the flock. In terms of the concept of recursive public, EMACS was itself the tool through which it was possible for users to extend EMACS, the medium of their affinity; users had a natural incentive to share their contributions so that all might receive the maximum benefit.

The terms of the EMACS distribution agreement were not quite legally binding; nothing compelled partic.i.p.ation except Stallman's reputation, his hectoring, or a user's desire to reciprocate. On the one hand, Stallman had not yet chosen to, or been forced to, understand the details of the legal system, and so the EMACS commune was the next best thing. On the other hand, the state of intellectual-property law was in great flux at the time, and it was not clear to anyone, whether corporate or academic, exactly what kind of legal arrangements would be legitimate (the 1976 changes to copyright law were some of the most drastic in seventy years, and a 1980 amendment made software copyrightable, but no court cases had yet tested these changes). Stallman's "agreement" was a set of informal rules that expressed the general sense of mutual aid that was a feature of both the design of the system and Stallman's own experience at the AI Lab. It was an expression of the way Stallman expected others to behave, and his attempts to punish or shame people amounted to informal enforcement of these expectations. The small scale of the community worked in Stallman's favor.

At its small scale, Stallman's commune was confronting many of the same issues that haunted the open-systems debates emerging at the same time, issues of interoperability, source-code sharing, standardization, portability, and forking. In particular, Stallman was acutely aware of the blind spot of open systems: the conflict of moral-technical orders represented by intellectual property. While UNIX vendors left intellectual-property rules unchallenged and simply a.s.sumed that they were the essential ground rules of debate, Stallman made them the substance of his experiment and, like Bentham, became something of a legal muckraker as a result.

Stallman's communal model could not completely prevent the porting and forking of software. Despite Stallman's request that imitators refer to their versions of EMACS as ersatz EMACS, few did. In the absence of legal threats over a trademarked term there was not much to stop people from calling their ports and forks EMACS, a problem of success not unlike that of Kleenex or Xerox. Few people took the core ideas of EMACS, implemented them in an imitation, and then called it something else (EINE and ZWEI were exceptions). In the case of UNIX the proliferation of forked versions of the software did not render them any less UNIX, even when AT&T insisted on ownership of the trademarked name. But as time went on, EMACS was ported, forked, rewritten, copied, or imitated on different operating systems and different computer architectures in universities and corporations around the world; within five or six years, many versions of EMACS were in wide use. It was this situation of successful adoption that would provide the context for the controversy that occurred between 1983 and 1985.

The Controversy.

In brief the controversy was this: in 1983 James Gosling decided to sell his version of EMACS-a version written in C for UNIX called GOSMACS-to a commercial software vendor called Unipress. GOSMACS, the second most famous implementation of EMACS (after Stallman's itself ), was written when Gosling was a graduate student at Carnegie Mellon University. For years, Gosling had distributed GOSMACS by himself and had run a mailing list on Usenet, on which he answered queries and discussed extensions. Gosling had explicitly asked people not to redistribute the program, but to come back to him (or send interested parties to him directly) for new versions, making GOSMACS more of a benevolent dictatorship than a commune. Gosling maintained his authority, but graciously accepted revisions and bug-fixes and extensions from users, incorporating them into new releases. Stallman's system, by contrast, allowed users to distribute their extensions themselves, as well as have them included in the "official" EMACS. By 1983, Gosling had decided he was unable to effectively maintain and support GOSMACS-a task he considered the proper role of a corporation.

For Stallman, Gosling's decision to sell GOSMACS to Unipress was "software sabotage." Even though Gosling had been substantially responsible for writing GOSMACS, Stallman felt somewhat proprietorial toward this ersatz version-or, at the very least, was irked that no noncommercial UNIX version of EMACS existed. So Stallman wrote one himself (as part of a project he announced around the same time, called GNU [GNU's Not UNIX], to create a complete non-AT&T version of UNIX). He called his version GNU EMACS and released it under the same EMACS commune terms. The crux of the debate hinged on the fact that Stallman used, albeit ostensibly with permission, a small piece of Gosling's code in his new version of EMACS, a fact that led numerous people, including the new commercial suppliers of EMACS, to cry foul. Recriminations and legal threats ensued and the controversy was eventually resolved when Stallman rewrote the offending code, thus creating an entirely "Gosling-free" version that went on to become the standard UNIX version of EMACS.

The story raises several questions with respect to the changing legal context. In particular, it raises questions about the difference between "law on the books" and "law in action," that is, the difference between the actions of hackers and commercial ent.i.ties, advised by lawyers and legally minded friends, and the text and interpretation of statutes as they are written by legislators and interpreted by courts and lawyers. The legal issues span trade secret, patent, and trademark, but copyright is especially significant. Three issues were undecided at the time: the copyrightability of software, the definition of what counts as software and what doesn't, and the meaning of copyright infringement. While the controversy did not resolve any of these issues (the first two would be resolved by Congress and the courts, the third remains somewhat murky), it did clarify the legal issues for Stallman sufficiently that he could leave behind the informal EMACS commune and create the first version of a Free Software license, the GNU General Public License, which first started appearing in 1985.

Gosling's decision to sell GOSMACS, announced in April of 1983, played into a growing EMACS debate being carried out on the GOSMACS mailing list, a Usenet group called net.emacs. Since net.emacs was forwarded to the Arpanet via a gateway maintained by John Gilmore at Sun Microsystems, a fairly large community of EMACS users were privy to Gosling's announcement. Prior to his declaration, there had been quite a bit of discussion regarding different versions of EMACS, including an already "commercial" version called CCA EMACS, written by Steve Zimmerman, of Computer Corporation of America (CCA).14 Some readers wanted comparisons between CCA EMACS and GOSMACS; others objected that it was improper to discuss a commercial version on the list: was such activity legitimate, or should it be carried out as part of the commercial company's support activities? Gosling's announcement was therefore a surprise, since it was already perceived to be the "noncommercial" version.

Date: Tue Apr 12 04:51:12 1983 Subject: EMACS goes commercial The version of EMACS that I wrote is now available commercially through a company called Unipress. . . . They will be doing development, maintenance and will be producing a real manual. EMACS will be available on many machines (it already runs on VAXen under Unix and VMS, SUNs, codatas, and Microsoft Xenix). Along with this, I regret to say that I will no longer be distributing it.

This is a hard step to take, but I feel that it is necessary. I can no longer look after it properly, there are too many demands on my time. EMACS has grown to be completely unmanageable. Its popularity has made it impossible to distribute free: just the task of writing tapes and stuffing them into envelopes is more than I can handle.

The alternative of abandoning it to the public domain is unacceptable. Too many other programs have been destroyed that way.

Please support these folks. The effort that they can afford to put into looking after EMACS is directly related to the support they get. Their prices are reasonable.

James.15.

The message is worth paying careful attention to: Gosling's work of distributing the tapes had become "unmanageable," and the work of maintenance, upkeep, and porting (making it available on multiple architectures) is something he clearly believes should be done by a commercial enterprise. Gosling, it is clear, did not understand his effort in creating and maintaining EMACS to have emerged from a communal sharing of bits of code-even if he had done a Sisyphean amount of work to incorporate all the changes and suggestions his users had made-but he did long have a commitment to distributing it for free, a commitment that resulted in many people contributing bits and pieces to GOSMACS.

"Free," however, did not mean "public domain," as is clear from his statement that "abandoning it" to the public domain would destroy the program. The distinction is an important one that was, and continues to be, lost on many sophisticated members of net.emacs. Here, free means without charge, but Gosling had no intention of letting that word suggest that he was not the author, owner, maintainer, distributor, and sole beneficiary of whatever value GOSMACS had. Public domain, by contrast, implied giving up all these rights.16 His decision to sell GOSMACS to Unipress was a decision to transfer these rights to a company that would then charge for all the labor he had previously provided for no charge (for "free"). Such a distinction was not clear to everyone; many people considered the fact that GOSMACS was free to imply that it was in the public domain.17 Not least of these was Richard Stallman, who referred to Gosling's act as "software sabotage" and urged people to avoid using the "semi-ersatz" Unipress version.18 To Stallman, the advancing commercialization of EMACS, both by CCA and by Unipress, was a frustrating state of affairs. The commercialization of CCA had been of little concern so long as GOSMACS remained free, but with Gosling's announcement, there was no longer a UNIX version of EMACS available. To Stallman, however, "free" meant something more than either "public domain" or "for no cost." The EMACS commune was designed to keep EMACS alive and growing as well as to provide it for free-it was an image of community stewardship, a community that had included Gosling until April 1983.

The disappearance of a UNIX version of EMACS, as well as the sudden commercial interest in making UNIX into a marketable operating system, fed into Stallman's nascent plan to create a completely new, noncommercial, non-AT&T UNIX operating system that he would give away free to anyone who could use it. He announced his intention on 27 September 1983:19 Free Unix!

Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU (for Gnu's Not Unix), and give it away free to everyone who can use it. Contributions of time, money, programs and equipment are greatly needed.

His justifications were simple.

Why I Must Write GNU I consider that the golden rule requires that if I like a program I must share it with other people who like it. I cannot in good conscience sign a nondisclosure agreement or a software license agreement.

So that I can continue to use computers without violating my principles, I have decided to put together a sufficient body of free software so that I will be able to get along without any software that is not free.20 At that point, it is clear, there was no "free software license." There was the word free, but not the term public domain. There was the "golden rule," and there was a resistance to nondisclosure and license arrangements in general, but certainly no articulated conception of copyleft of Free Software as a legally distinct ent.i.ty. And yet Stallman hardly intended to "abandon it" to the public domain, as Gosling suggested. Instead, Stallman likely intended to require the same EMACS commune rules to apply to Free Software, rules that he would be able to control largely by overseeing (in a nonlegal sense) who was sent or sold what and by demanding (in the form of messages attached to the software) that any modifications or improvements come in the form of donations. It was during the period 198385 that the EMACS commune morphed into the GPL, as Stallman began adding copyrights and appending messages that made explicit what people could do with the software.21 The GNU project initially received little attention, however; scattered messages to net.unix-wizards over the course of 198384 periodically ask about the status and how to contact them, often in the context of discussions of AT&T UNIX licensing practices that were unfolding as UNIX was divested and began to market its own version of UNIX.22 Stallman's original plan for GNU was to start with the core operating system, the kernel, but his extensive work on EMACS and the sudden need for a free EMACS for UNIX led him to start with a UNIX version of EMACS. In 1984 and into 1985, he and others began work on a UNIX version of GNU EMACS. The two commercial versions of UNIX EMACS (CCA EMACS and Unipress EMACS) continued to circulate and improve in parallel. DEC users meanwhile used the original free version created by Stallman. And, as often happens, life went on: Zimmerman left CCA in August 1984, and Gosling moved to Sun, neither of them remaining closely involved in the software they had created, but leaving the new owners to do so.

By March 1985, Stallman had a complete version (version 15) of GNU EMACS running on the BSD 4.2 version of UNIX (the version Bill Joy had helped create and had taken with him to form the core of Sun's version of UNIX), running on DEC's VAX computers. Stallman announced this software in a characteristically flamboyant manner, publishing in the computer programmers' monthly magazine Dr. Dobbs an article ent.i.tled "The GNU Manifesto."23 Stallman's announcement that a free version of UNIX EMACS was available caused some concern among commercial distributors. The main such concern was that GNU EMACS 15.34 contained code marked "Copyright (c) James Gosling," code used to make EMACS display on screen.24 The "discovery" (not so difficult, since Stallman always distributed the source code along with the binary) that this code had been reused by Stallman led to extensive discussion among EMACS users of issues such as the mechanics of copyright, the nature of infringement, the definition of software, the meaning of public domain, the difference between patent, copyright, and trade secret, and the mechanics of permission and its granting-in short, a discussion that would be repeatedly recapitulated in nearly every software and intellectual property controversy in the future.

The story of the controversy reveals the structure of rumor on the Usenet to be a bit like the child's game of Chinese Whispers, except that the translations are all archived. GNU EMACS 15.34 was released in March 1985. Between March and early June there was no mention of its legal status, but around June 3 messages on the subject began to proliferate. The earliest mention of the issue appeared not on net.emacs, but on fa.info-vax-a newsgroup devoted to discussions of VAX computer systems ("fa" stands for "from Arpanet")-and it included a dialogue, between Ron Natalie and Marty Sasaki, labeled "GNU EMACS: How Public Domain?": "FOO, don't expect that GNU EMACS is really in the public domain. UNIPRESS seems rather annoyed that there are large portions of it that are marked copyright James Gosling."25 This message was reprinted on 4 June 1985 on net.emacs, with the addendum: "RMS's work is based on a version of Gosling code that existed before Unipress got it. Gosling had put that code into the public domain. Any work taking off from the early Gosling code is therefore also public domain."26 The addendum was then followed by an extensive reply from Zimmerman, whose CCA EMACS had been based on Warren Montgomery's Bell Labs EMACS but rewritten to avoid reusing the code, which may account for why his understanding of the issue seems to have been both deep and troubling for him.

This is completely contrary to Gosling's public statements. Before he made his arrangements with Unipress, Gosling's policy was that he would send a free copy of his EMACS to anyone who asked, but he did not (publicly, at least) give anyone else permission to make copies. Once Unipress started selling Gosling's EMACS, Gosling stopped distributing free copies and still did not grant anyone else permission to make them; instead, he suggested that people buy EMACS from Unipress. All versions of Gosling's EMACS distributed by him carry his copyright notice, and therefore none of them are in the public domain. Removing copyright notices without the author's permission is, of course, illegal. Now, a quick check of my GNU EMACS sources shows that sure enough, a number of files have Gosling's copyright notice in them. What this all means is that unless RMS got written permission from Gosling to distribute his code, all copies of GNU EMACS const.i.tute violations of the copyright law. All those people making such copies, including those people who allow them to be copied off their machines, could each be liable for large sums of money. I think that RMS had better tell us if he has Gosling's written permission to make these copies. If so, why has he not stated this earlier (preferably in the distribution itself ) and thereby cleared up a potentially major point of confusion? If not, why has he gone ahead and made many, many people liable for criminal prosecution by recommending that they distribute this code without even warning them of their liability? (People who distribute this code would be liable even if they claim that they didn't see Gosling's notices; the fact that the notices are there is sufficient. "Ignorance of the law is no excuse.") Now, I have nothing against free software; it's a free country and people can do what they want. It's just that people who do distribute free software had better be sure that they have the legal right to do so, or be prepared to face the consequences. (Jun 9, 1985).27 Stallman replied the next day.

n.o.body has any reason to be afraid to use or distribute GNU EMACS. It is well known that I do not believe any software is anyone's property. However, for the GNU project, I decided it was necessary to obey the law. I have refused to look at code I did not have permission to distribute. About 5% of GNU EMACS is close to (though quite a bit changed from) an old version of Gosling EMACS. I am distributing it for Fen Labalme, who received permission from Gosling to distribute it. It is therefore legal for me to do so. To be scrupulously legal, I put statements at the front of the files concerned, describing this situation.

I don't see anything I should warn people about-except that Zimmerman is going to try to browbeat them.28 Stallman's original defense for using Gosling's code was that he had permission to do so. According to him, Fen Labalme had received written permission-whether to make use of or to redistribute is not clear-the display code that was included in GNU EMACS 15.34. According to Stallman, versions of Labalme's version of Gosling's version of EMACS were in use in various places (including at Labalme's employer, Megatest), and Stallman and Labalme considered this a legally defensible position.29 Over the next two weeks, a slew of messages attempted to pick apart and understand the issues of copyright, ownership, distribution, and authorship. Gosling wrote to clarify that GOSMACS had never been in the public domain, but that "unfortunately, two moves have left my records in a shambles," and he is therefore silent on the question of whether he granted permission.30 Gosling's claim could well be strategic: giving permission, had he done so, might have angered Unipress, which expected exclusive control over the version he had sold; by the same token, he may well have approved of Stallman's re-creation, but not have wanted to affirm this in any legally actionable way. Meanwhile, Zimmerman relayed an anonymous message suggesting that some lawyers somewhere found the "third hand redistribution" argument was legally "all wet."31 Stallman's biggest concern was not so much the legality of his own actions as the possibility that people would choose not to use the software because of legal threats (even if such threats were issued only as rumors by former employees of companies that distributed software they had written). Stallman wanted users not only to feel safe using his software but to adopt his view that software exists to be shared and improved and that anything that hinders this is a loss for everyone, which necessitates an EMACS commune.

Stallman's legal grounds for using Gosling's code may or may not have been sound. Zimmerman did his best throughout to explain in detail what kind of permission Stallman and Labalme would have needed, drawing on his own experience with the CCA lawyers and AT&T Bell Labs, all the while berating Stallman for not creating the display code himself. Meanwhile, Unipress posted an official message that said, "UniPress wants to inform the community that portions of the GNU EMACS program are most definitely not public domain, and that use and/or distribution of the GNU EMACS program is not necessarily proper."32 The admittedly vague tone of the message left most people wondering what that meant-and whether Unipress intended to sue anyone. Strategically speaking, the company may have wished to maintain good will among hackers and readers of net.emacs, an audience likely composed of many potential customers. Furthermore, if Gosling had given permission to Stallman, then Unipress would themselves have been on uncertain legal ground, unable to firmly and definitively threaten users of GNU EMACS with legal action. In either case, the question of whether or not permission was needed was not in question-only the question of whether it had been granted.33 However, a more complicated legal issue also arose as a result, one concerning the status of code contributed to Gosling by others. Fen Labalme wrote a message to net.emacs, which, although it did not clarify the legal status of Gosling's code (Labalme was also unable to find his "permission" from Gosling), did raise a related issue: the fact that he and others had made significant contributions to GOSMACS, which Gosling had incorporated into his version, then sold to Unipress without their permission: "As one of the 'others' who helped to bring EMACS [GOSMACS] up to speed, I was distressed when Jim sold the editor to UniPress. This seemed to be a direct violation of the trust that I and others had placed in Jim as we sent him our improvements, modifications, and bug fixes. I am especially bothered by the general mercenary att.i.tude surrounding EMACS which has taken over from the once proud 'hacker' ethic-EMACS is a tool that can make all of our lives better. Let's help it to grow!"34 Labalme's implication, though he may not even have realized this himself, is that Gosling may have infringed on the rights of others in selling the code to Unipress, as a separate message from Joaquim Martillo makes clear: "The differences between current version of Unipress EMACS and Gnu EMACS display.c (a 19 page module) is about 80%. For all the modules which Fen LeBalme [sic] gave RMS permission to use, the differences are similar. Unipress is not even using the disputed software anymore! Now, these modules contain code people like Chris Torek and others contributed when Gosling's emacs was in the public domain. I must wonder whether these people would have contributed had they known their freely-given code was going to become part of someone's product."35 Indeed, the general irony of this complicated situation was certainly not as evident as it might have been given the emotional tone of the debates: Stallman was using code from Gosling based on permission Gosling had given to Labalme, but Labalme had written code for Gosling which Gosling had commercialized without telling Labalme-conceivably, but not likely, the same code. Furthermore, all of them were creating software that had been originally conceived in large part by Stallman (but based on ideas and work on TECO, an editor written twenty years before EMACS), who was now busy rewriting the very software Gosling had rewritten for UNIX. The "once proud hacker ethic" that Labalme mentions would thus amount not so much to an explicit belief in sharing so much as a fast-and-loose practice of making contributions and fixes without doc.u.menting them, giving oral permission to use and reuse, and "losing" records that may or may not have existed-hardly a n.o.ble enterprise.

But by 27 June 1985, all of the legal discussion was rendered moot when Stallman announced that he would completely rewrite the display code in EMACS.

I have decided to replace the Gosling code in GNU EMACS, even though I still believe Fen and I have permission to distribute that code, in order to keep people's confidence in the GNU project.

I came to this decision when I found, this night, that I saw how to rewrite the parts that had seemed hard. I expect to have the job done by the weekend.36 On 5 July, Stallman sent out a message that said: Celebrate our independence from Unipress!

EMACS version 16, 100% Gosling-free, is now being tested at several places. It appears to work solidly on Vaxes, but some other machines have not been tested yet.37 The fact that it only took one week to create the code is a testament to Stallman's widely recognized skills in creating great software-it doesn't appear to have indicated any (legal) threat or urgency. Indeed, even though Unipress seems also to have been concerned about their own reputation, and despite the implication made by Stallman that they had forced this issue to happen, they took a month to respond. At that point, the Unipress employee Mike Gallaher wrote to insist, somewhat after the fact, that Unipress had no intention of suing anyone-as long as they were using the Gosling-free EMACS version 16 and higher.

UniPress has no quarrel with the Gnu project. It bothers me that people seem to think we are trying to hinder it. In fact, we hardly did or said much at all, except to point out that the Gnumacs code had James Gosling's copyright in it. We have not done anything to keep anyone from using Gnumacs, nor do we intend to now that it is "Gosling-free" (version 16.56).

You can consider this to be an official statement from UniPress: There is nothing in Gnumacs version 16.56 that could possibly cause UniPress to get upset. If you were afraid to use Gnumacs because you thought we would ha.s.sle you, don't be, on the basis of version 16.56.38 Both Stallman and Unipress received various attacks and defenses from observers of the controversy. Many people pointed out that Stallman should get credit for "inventing" EMACS and that the issue of him infringing on his own invention was therefore ironic. Others proclaimed the innocence and moral character of Unipress, which, it was claimed, was providing more of a service (support for EMACS) than the program itself.

Some readers interpreted the fact that Stallman had rewritten the display code, whether under pressure from Unipress or not, as confirmation of the ideas expressed in "The GNU Manifesto," namely, that commercial software stifles innovation. According to this logic, precisely because Stallman was forced to rewrite the code, rather than build on something that he himself a.s.sumed he had permission to do, there was no innovation, only fear-induced caution.39 On the other hand, latent within this discussion is a deep sense of propriety about what people had created; many people, not only Stallman and Gosling and Zimmerman, had contributed to making EMACS what it was, and most had done so under the a.s.sumption, legally correct or not, that it would not be taken away from them or, worse, that others might profit by it.

Gosling's sale of EMACS is thus of a different order from his partic.i.p.ation in the common stewardship of EMACS. The distinction between creating software and maintaining it is a commercial fiction driven in large part by the structure of intellectual property. It mirrors the experience of open systems. Maintaining software can mean improving it, and improving it can mean incorporating the original work and ideas of others. To do so by the rules of a changing intellectual-property structure forces different choices than to do so according to an informal hacker ethic or an experimental "commune." One programmer's minor improvement is another programmer's original contribution.

The Context of Copyright.

The EMACS controversy occurred in a period just after some of the largest changes to U.S. intellectual-property law in seventy years. Two aspects of this context are worth emphasizing: (1) practices and knowledge about the law change slowly and do not immediately reflect the change in either the law or the strategies of actors; (2) U.S. law creates a structural form of uncertainty in which the interplay between legislation and case law is never entirely certain. In the former aspect, programmers who grew up in the 1970s saw a commercial practice entirely dominated by trade secret and patent protection, and very rarely by copyright; thus, the shift to widespread use of copyright law (facilitated by the 1976 and 1980 changes to the law) to protect software was a shift in thinking that only slowly dawned on many partic.i.p.ants, even the most legally astute, since it was a general shift in strategy as well as a statutory change. In the latter aspect, the 1976 and 1980 changes to the copyright law contained a number of uncertainties that would take over a decade to be worked out in case law, issues such as the copyrightability of software, the definition of software, and the meaning of infringement in software copyright, to say nothing of the impact of the codification of fair use and the removal of the requirement to register (issues that arguably went unnoticed until the turn of the millennium). Both aspects set the stage for the EMACS controversy and Stallman's creation of the GPL.

Legally speaking, the EMACS controversy was about copyright, permission, and the meanings of a public domain and the reuse of software (and, though never explicitly mentioned, fair use). Software patenting and trade-secret law are not directly concerned, but they nonetheless form a background to the controversy. Many of the partic.i.p.ants expressed a legal and conventional orthodoxy that software was not patentable, that is, that algorithms, ideas, or fundamental equations fell outside the scope of patent, even though the 1981 case Diamond v. Diehr is generally seen as the first strong support by the courts for forcing the United States Patent and Trademark Office to grant patents on software.40 Software, this orthodoxy went, was better protected by trade-secret law (a state-by-state law, not a federal statute), which provided protection for any intellectual property that an owner reasonably tried to maintain as a secret. The trade-secret status of UNIX, for example, meant that all the educational licensees who were given the source code of UNIX had agreed to keep it secret, even though it was manifestly circulating the world over; one could therefore run afoul of trade-secret rules if one looked at the source code (e.g., signed a nondisclosure license or was shown the code by an employee) and then implemented something similar.

By contrast, copyright law was rarely deployed in matters of software production. The first copyright registration of software occurred in 1964, but the desirability of relying on copyright over trade secret was uncertain well into the 1970s.41 Some corporations, like IBM, routinely marked all source code with a copyright symbol. Others a.s.serted it only on the binaries they distributed or in the license agreements. The case of software on the UNIX operating system and its derivatives is particularly haphazard, and the existence of copyright notices by the authors varies widely. An informal survey by Barry Gold singled out only James Gosling, Walter Tichy (author of rcs), and the RAND Corporation as having adequately labeled source code with copyright notices.42 Gosling was also the first to register EMACS as copyrighted software in 1983, while Stallman registered GNU EMACS just after version 15.34 was released in May 1985.43 The uncertainty of the change from reliance on trade secret to reliance on copyright is clear in some of the statements made by Stallman around the reuse of Gosling's code. Since neither Stallman nor Gosling sought to keep the program secret in any form-either by licensing it or by requiring users to keep it secret-there could be no claims of trade-secret status on either program. Nonetheless, there was frequent concern about whether one had seen any code (especially code from a UNIX operating system, which is covered by trade secret) and whether code that someone else had seen, rewritten, or distributed publicly was therefore "in the public domain."44 But, at the same time, Stallman was concerned that rewriting Gosling's display code would be too difficult: "Any display code would have a considerable resemblance to that display code, just by virtue of doing the same job. Without any clear idea of exactly how much difference there would have to be to rea.s.sure you users, I cannot tell whether the rewrite would accomplish that. The law is not any guidance here. . . . Writing display code that is significantly different is not easy."45 Stallman's strategy for rewriting software, including his plan for the GNU operating system, also involved "not looking at" anyone else's code, so as to ensure that no trade-secret violations would occur. Although it was clear that Gosling's code was not a trade secret, it was also not obvious that it was "in the public domain," an a.s.sumption that might be made about other kinds of software protected by trade secret. Under trade-secret rules, Gosling's public distribution of GOSMACS appears to give the green light for its reuse, but under copyright law, a law of strict liability, any unauthorized use is a violation, regardless of how public the software may have been.46 The fact of trade-secret protection was nonetheless an important aspect of the EMACS controversy: the version of EMACS that Warren Montgomery had created at Bell Labs (and on which Zimmerman's CCA version would be based) was the subject of trade-secret protection by AT&T, by virtue of being distributed with UNIX and under a nondisclosure agreement. AT&T was at the time still a year away from divest.i.ture and thus unable to engage in commercial exploitation of the software. When CCA sought to commercialize the version of UNIX Zimmerman had based on Montgomery's, it was necessary to remove any AT&T code in order to avoid violating their trade-secret status. CCA in turn distributed their EMACS as either binary or as source (the former costing about $1,000, the latter as much as $7,000) and relied on copyright rather than trade-secret protection to prevent unauthorized uses of their software.47 The uncertainty over copyright was thus in part a reflection of a changing strategy in the computer-software industry, a kind of uneven development in which copyright slowly and haphazardly came to replace trade secret as the main form of intellectual-property protection. This switch had consequences for how noncommercial programmers, researchers, and amateurs might interpret their own work, as well as for the companies whose lawyers were struggling with the same issues. Of course, copyright and trade-secret protection are not mutually exclusive, but they structure the need for secrecy in different ways, and they make different claims on issues like similarity, reuse, and modification.

The 1976 changes to copyright law were therefore extremely significant in setting out a new set of boundaries and possibilities for intellectual-property arguments, arguments that created a different kind of uncertainty from that of a changing commercial strategy: a structural uncertainty created by the need for a case law to develop around the statutory changes implemented by Congress.

The Copyright Act of 1976 introduced a number of changes that had been some ten years in the making, largely organized around new technologies like photocopier machines, home audiotaping, and the new videoca.s.sette recorders. It codified fair-use rights, it removed the requirement to register, and it expanded the scope of copyrightable materials considerably. It did not, however, explicitly address software, an oversight that frustrated many in the computer industry, in particular the young software industry. Pursuant to this oversight, the National Commission on New Technological Uses of Copyright (CONTU) was charged with making suggestions for changes to the law with respect to software. It was therefore only in 1980 that Congress implemented these changes, adding software to t.i.tle 17 of the U.S. copyright statute as something that could be considered copyrightable by law.48 The 1980 amendment to the copyright law answered one of three lingering questions about the copyrightability of software: the simple question of whether it was copyrightable material at all. Congress answered yes. It did not, however, designate what const.i.tuted "software." During the 1980s, a series of court cases helped specify what counted as software, including source code, object code (binaries), screen display and output, look and feel, and microcode and firmware.49 The final question, which the courts are still faced with adjudicating, concerns how much similarity const.i.tutes an infringement in each of these cases. The implications of the codification of fair use and the requirement to register continue to unfold even into the present.

The EMACS controversy confronts all three of these questions. Stallman's initial creation of EMACS was accomplished under conditions in which it was unclear whether copyright would apply (i.e., before 1980). Stallman, of course, did not attempt to copyright the earliest versions of EMACS, but the 1976 amendments removed the requirement to register, thus rendering everything written after 1978 automatically copyrighted. Registration represented only an additional effort to a.s.sert ownership in cases of suspected infringement.

Throughout this period, the question of whether software was copyrightable-or copyrighted-was being answered differently in different cases: AT&T was relying on trade-secret status; Gosling, Unipress, and CCA negotiated over copyrighted material; and Stallman was experimenting with his "commune." Although the uncertainty was answered statutorily by the 1980 amendment, not everyone instantly grasped this new fact or changed practices based on it. There is ample evidence throughout the Usenet archive that the 1976 changes were poorly understood, especially by comparison with the legal sophistication of hackers in the 1990s and 2000s. Although the law changed in 1980, practices changed more slowly, and justifications crystallized in the context of experiments like that of GNU EMACS.

Further, a tension emerged between the meaning of source code and the meaning of software. On the one hand was the question of whether the source code or the binary code was copyrightable, and on the other was the question of defining the boundaries of software in a context wherein all software relies on other software in order to run at all. For instance, EMACS was originally built on top of TECO, which was referred to both as an editor and as a programming language; even seemingly obvious distinctions (e.g., application vs. programming language) were not necessarily always clear. If EMACS was an application written in TECO qua programming language, then it would seem that EMACS should have its own copyright, distinct from any other program written in TECO. But if EMACS was an extension or modification of TECO qua editor, then it would seem that EMACS was a derivative work and would require the explicit permission of the copyright holder.

Further, each version of EMACS, in order to be EMACS, needed a LISP interpreter in order to make the extensible interface similar across all versions. But not all versions used the same LISP interpreter. Gosling's used an interpreter called MOCKLISP (mlisp in the trademarked Unipress version), for instance. The question of whether the LISP interpreter was a core component of the software or an "environment" needed in order to extend the application was thus also uncertain and unspecified in the law. While both might be treated as software suitable for copyright protection, both might also be understood as necessary components out of which copyrightable software would be built.50 What's more, both the 1976 and 1980 amendments are silent on the copyright status of source code vs. binary code. While all the versions of EMACS were distributed in binary, Stallman and Gosling both included the source to allow users to modify it and extend it, but they differed on the proper form of redistribution. The threshold between modifying software for oneself and copyright infringement was not yet clear, and it hung on the meaning of redistribution. Changing the software for use on a single computer might be necessary to get it to run, but by the early days of the Arpanet, innocently placing that code in a public directory on one computer could look like ma.s.s distribution.51 Finally, the question of what const.i.tutes infringement was at the heart of this controversy and was not resolved by law or by legal adjudication, but simply by rewriting the code to avoid the question. Stallman's use of Gosling's code, his claim of third-hand permission, the presence or absence of written permission, the sale of GOSMACS to Unipress when it most likely contained code not written by Gosling but copyrighted in his name-all of these issues complicated the question of infringement to the point where Stallman's only feasible option for continuing to create software was to avoid using anyone else's code at all. Indeed, Stallman's decision to use Gosling's code (which he claims to have changed in significant portions) might have come to nothing if he had unethically and illegally chosen not to include the copyright notice at all (under the theory that the code was original to Stallman, or an imitation, rather than a portion of Gosling's work). Indeed, Chris Torek received Gosling's permission to remove Gosling's name and copyright from the version of display.c he had heavily modified, but he chose not to omit them: "The only reason I didn't do so is that I feel that he should certainly be credited as the inspiration (at the very least) for the code."52 Likewise, Stallman was most likely concerned to obey the law and to give credit where credit was due, and therefore left the copyright notice attached-a clear case of blurred meanings of authorship and ownership.

In short, the interplay between new statutes and their settlement in court or in practice was a structural uncertainty that set novel constraints on the meaning of copyright, and especially on the norms and forms of permission and reuse. GNU EMACS 15.34 was the safest option-a completely new version that performed the same tasks, but in a different manner, using different algorithms and code.

Even as it resolved the controversy, however, GNU EMACS posed new problems for Stallman: how would the EMACS commune survive if it wasn't clear whether one could legally use another person's code, even if freely contributed? Was Gosling's action in selling work by others to Unipress legitimate? Would Stallman be able to enforce its opposite, namely, prevent people from commercializing EMACS code they contributed to him? How would Stallman avoid the future possibility of his own volunteers and contributors later a.s.serting that he had infringed on their copyright?

By 1986, Stallman was sending out a letter that recorded the formal transfer of copyright to the Free Software Foundation (which he had founded in late 1985), with equal rights to nonexclusive use of the software.53 While such a demand for the expropriation of copyright might seem contrary to the aims of the GNU project, in the context of the unfolding copyright law and the GOSMACS controversy it made perfect sense. Having been accused himself of not having proper permission to use someone else's copyrighted material in his free version of GNU EMACS, Stallman took steps to forestall such an event in the future.

The interplay between technical and legal issues and "ethical" concerns was reflected in the practical issues of fear, intimidation, and common-sense (mis)understandings of intellectual-property law. Zimmerman's veiled threats of legal liability were directed not only at Stallman but at anyone who was using the program Stallman had written; breaking the law was, for Zimmerman, an ethical lapse, not a problem of uncertainty and change. Whether or not such an interpretation of the law was correct, it did reveal the mechanisms whereby a low level of detailed knowledge about the law-and a law in flux, at that (not to mention the litigious reputation of the U.S. legal system worldwide)-often seemed to justify a sense that buying software was simply a less risky option than acquiring it for free. Businesses, not customers, it was a.s.sumed, would be liable for such infringements. By the same token, the sudden concern of software programmers (rather than lawyers) with the detailed mechanics of copyright law meant that a very large number of people found themselves a.s.serting common-sense notions, only to be involved in a flame war over what the copyright law "actually says."

Such discussion has continued and grown exponentially over the last twenty years, to the point that Free Software hackers are now nearly as deeply educated about intellectual property law as they are about software code.54 Far from representing the triumph of the hacker ethic, the GNU General Public License represents the concrete, tangible outcome of a relatively wide-ranging cultural conversation hemmed in by changing laws, court decisions, practices both commercial and academic, and experiments with the limits and forms of new media and new technology.

Conclusion.

The rest of the story is quickly told: Stallman resigned from the AI Lab at MIT and started the Free Software Foundation in 1985; he created a raft of new tools, but ultimately no full UNIX operating system, and issued General Public License 1.0 in 1989. In 1990 he was awarded a MacArthur "genius grant." During the 1990s, he was involved in various high-profile battles among a new generation of hackers; those controversies included the debate around Linus Torvalds's creation of Linux (which Stallman insisted be referred to as GNU/Linux), the forking of EMACS into Xemacs, and Stallman's own partic.i.p.ation in-and exclusion from-conferences and events devoted to Free Software.

Between 1986 and 1990, the Free Software Foundation and its software became extremely well known among geeks. Much of this had to do with the wealth of software that they produced and distributed via Usenet and Arpanet. And as the software circulated and was refined, so were the new legal constraints and the process of teaching users to understand what they could and could not do with the software-and why it was not in the public domain.

Each time a new piece of software was released, it was accompanied by one or more text files which explained what its legal status was. At first, there was a file called DISTRIB, which contained an explanation of the rights the new owner had to modify and redistribute the software.55 DISTRIB referenced a file called COPYING, which contained the "GNU EMACS copying permission notice," also known as the GNU EMACS GPL. The first of these licenses listed the copyright holder as Richard Stallman (in 1985), but by 1986 all licenses referred to the Free Software Foundation as the copyright holder.

As the Free Software Foundation released other pieces of software, the license was renamed-GNU CC GPL, a GNU Bison GPL, a GNU GDB GPL, and so on, all of which were essentially the same terms-in a file called COPYING, which was meant to be distributed along with the software. In 1988, after the software and the licenses had become considerably more widely available, Stallman made a few changes to the license that relaxed some of the terms and specified others.56 This new version would become the GNU GPL 1.0. By the time Free Software emerged into the public consciousness in the late 1990s, the GPL had reached version 2.0, and the Free Software Foundation had its own legal staff.

The creation of the GPL and the Free Software Foundation are often understood as expressions of the hacker ethic, or of Stallman's ideological commitment to freedom. But the story of EMACS and the complex technical and legal details that structure it ill.u.s.trate how the GPL is more than just a hack: it was a novel, privately ordered legal "commune." It was a s.p.a.ce thoroughly independent of, but insinuated into the existing bedrock of rules and practices of the world of corporate and university software, and carved out of the slippery, changing substance of intellectual-property statutes. At a time when the giants of the software industry were fighting to create a different kind of openness-one that preserved and would even strengthen existing relations of intellectual property-this hack was a radical alternative that emphasized the sovereignty not of a national or corporate status quo, but of self-fashioning individuals who sought to opt out of that national-corporate unity. The creation of the GNU GPL was not a return to a golden age of small-scale communities freed from the dominating structures of bureaucratic modernity, but the creation of something new out of those structures. It relied on and emphasized, not their destruction, but their stability-at least until they are no longer necessary.

The significance of the GPL is due to its embedding within and emergence from the legal and technical infrastructure. Such a practice of situated reworking is what gives Free Software-and perhaps all forms of engineering and creative practice-its warp and weft. Stallman's decision to resign from the AI Lab and start the Free Software Foundation is a good example; it allowed Stallman no only to devote energy to Free Software but also to formally differentiate the organizations, to forestall at least the potential threat that MIT (which still provided him with office s.p.a.ce, equipment, and network connection) might decide to claim ownership over his work. One might think that the hacker ethic and the image of self-determining free individuals would demand the total absence of organizations, but it requires instead their proliferation and modulation. Stallman himself was never so purely free: he relied on the largesse of MIT's AI Lab, without which he would have had no office, no computer, no connection to the network, and indeed, for a while, no home.

The Free Software Foundation represents a recognition on his part that individual and communal independence would come at the price of a legally and bureaucratically recognizable ent.i.ty, set apart from MIT and responsible only to itself. The Free Software Foundation took a cla.s.sic form: a nonprofit organization with a hierarchy. But by the early 1990s, a new set of experiments would begin that questioned the look of such an ent.i.ty. The stories of Linux and Apache reveal how these ventures both depended on the work of the Free Software Foundation and departed from the hierarchical tradition it represented, in order to innovate new similarly embedded sociotechnical forms of coordination.

The EMACS text editor is still widely used, in version 22.1 as of 2007, and ported to just about every conceivable operating system. The controversy with Unipress has faded into the distance, as newer and more intense controversies have faced Stallman and Free Software, but the GPL has become the most widely used and most finely scrutinized of the legal licenses. More important, the EMACS controversy was by no means the only one to have erupted in the lives of software programmers; indeed, it has become virtually a rite of pa.s.sage for young geeks to be involved in such debates, because it is the only way in which the technical details and the legal details that confront geeks can be explored in the requisite detail. Not all such arguments end in the complete rewriting of source code, and today many of them concern the attempt to convince or evangelize for the release of source code under a Free Software license. The EMACS controversy was in some ways a primal scene-a traumatic one, for sure-that determined the outcome of many subsequent fights by giving form to the Free Software license and its uses.

7. Coordinating Collaborations.

The final component of Free Software is coordination. For many partic.i.p.ants and observers, this is the central innovation and essential significance of Open Source: the possibility of enticing potentially huge numbers of volunteers to work freely on a software project, leveraging the law of large numbers, "peer production," "gift economies," and "self-organizing social economies."1 Coordination in Free Software is of a distinct kind that emerged in the 1990s, directly out of the issues of sharing source code, conceiving open systems, and writing copyright licenses-all necessary precursors to the practices of coordination. The stories surrounding these issues find continuation in those of the Linux operating-system kernel, of the Apache Web server, and of Source Code Management tools (SCMs); together these stories reveal how coordination worked and what it looked like in the 1990s.

Coordination is important because it collapses and resolves the distinction between technical and social forms into a meaningful whole for partic.i.p.ants. On the one hand, there is the coordination and management of people; on the other, there is the coordination of source code, patches, fixes, bug reports, versions, and distributions-but together there is a meaningful technosocial practice of managing, decision-making, and accounting that leads to the collaborative production of complex software and networks. Such coordination would be unexceptional, essentially mimicking long-familiar corporate practices of engineering, except for one key fact: it has no goals. Coordination in Free Software privileges adaptability over planning. This involves more than simply allowing any kind of modification; the structure of Free Software coordination actually gives precedence to a generalized openness to change, rather than to the following of shared plans, goals, or ideals dictated or controlled by a hierarchy of individuals.2 Adaptability does not mean randomness or anarchy, however; it is a very specific way of resolving the tension between the individual curiosity and virtuosity of hackers, and the collective coordination necessary to create and use complex software and networks. No man is an island, but no archipelago is a nation, so to speak. Adaptability preserves the "joy" and "fun" of programming without sacrificing the careful engineering of a stable product. Linux and Apache should be understood as the results of this kind of coordination: experiments with adaptability that have worked, to the surprise of many who h