To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. - Preamble to the GNU General Public License
The use of novel, unconventional copyright licenses is, without a doubt, the most widely recognized and exquisitely refined component of Free Software. The GNU General Public License (GPL), written initially by Richard Stallman, is often referred to as a beautiful, clever, powerful “hack” of intellectual-property law—when it isn’t being denounced as a viral, infectious object threatening the very fabric of economy and society. The very fact that something so boring, so arcane, and so legalistic as a copyright license can become an object of both devotional reverence and bilious scorn means there is much more than fine print at stake. [pg 180]
By the beginning of the twenty-first century, there were hundreds of different Free Software licenses, each with subtle legal and technical differences, and an enormous legal literature to explain their details, motivation, and impact.
But how did it come to be this way? As with the example of sharing UNIX source code, Free Software licenses are often explained as a reaction to expanding intellectual-property laws and resistance to rapacious corporations. The text of the GPL itself begins deep in such assumptions: “The licenses for most software are designed to take away your freedom to share and change it.”
In this chapter I tell the story of the creation of the GPL, the first Free Software license, during a controversy over EMACS, a very widely used and respected piece of software; the controversy concerned the reuse of bits of copyrighted source code in a version of EMACS ported to UNIX. There are two reasons to retell this story carefully. The first is simply to articulate the details of the origin of the Free Software license itself, as a central component of Free Software, details that should be understood in the context of changing copyright law and the UNIX and open-systems struggles of the 1980s. Second, although the story of the GPL is also an oft-told story of the “hacker ethic,” the GPL is not an “expression” of this [pg 181] ethic, as if the ethic were genotype to a legal phenotype. Opposite the familiar story of ethics, I explain how the GPL was “figured out” in the controversy over EMACS, how it was formed in response to a complicated state of affairs, both legal and technical, and in a medium new to all the participants: the online mailing lists and discussion lists of Usenet and Arpanet.
The story of the creation of the GNU General Public License ultimately affirms the hacker ethic, not as a story of the ethical hacker genius, but as a historically specific event with a duration and a context, as something that emerges in response to the reorientation of knowledge and power, and through the active modulation of existing practices among both human and nonhuman actors. While hackers themselves might understand the hacker ethic as an unchanging set of moral norms, their practices belie this belief and demonstrate how ethics and norms can emerge suddenly and sharply, undergo repeated transformations, and bifurcate into ideologically distinct camps (Free Software vs. Open Source), even as the practices remain stable relative to them. The hacker ethic does not descend from the heights of philosophy like the categorical imperative—hackers have no Kant, nor do they want one. Rather, as Manuel Delanda has suggested, the philosophy of Free Software is the fact of Free Software itself, its practices and its things. If there is a hacker ethic, it is Free Software itself, it is the recursive public itself, which is much more than a list of norms.
In lecturing on liberalism in 1935, John Dewey said the following of Jeremy Bentham: “He was, we might say, the first great muck-raker in the field of law . . . but he was more than that, whenever he saw a defect, he proposed a remedy. He was an inventor in law and administration, as much so as any contemporary in mechanical production.”
A similar story might be told of Richard Stallman, hacker hero and founder of the Free Software Foundation, creator of (among many other things) the GNU C Compiler and GNU EMACS, two of the most widely used and tested Free Software tools in the world. Stallman is routinely abused for holding what many perceive to be “dogmatic” or “intractable” ideological positions about freedom and the right of individuals to do what they please with software. While it is no doubt quite true that his speeches and writings clearly betray a certain fervor and fanaticism, it would be a mistake to assume that his speeches, ideas, or belligerent demands concerning word choice constitute the real substance of his reform. In fact, it is the software he has created and the licenses he has written and rewritten which are the key to his Bentham-like inventiveness. Unlike Bentham, however, Stallman is not a creator of law and administrative structure, but a hacker.
Stallman’s GNU General Public License “hacks” the federal copyright law, as is often pointed out. It does this by taking advantage of the very strong rights granted by federal law to actually loosen the restrictions normally associated with ownership. Because the statutes grant owners strong powers to create restrictions, Stallman’s GPL contains the restriction that anybody can use the licensed material, for any purpose, so long as they subsequently offer the same restriction. Hacks (after which hackers are named) are clever solutions to problems or shortcomings in technology. Hacks are work-arounds, clever, shortest-path solutions that take advantage of characteristics of the system that may or may not have been obvious to the people who designed it. Hacks range from purely utilitarian to mischievously pointless, but they always depend on an existing system or tool through which they achieve their point. To call Free Software a hack is to point out that it would be nothing without the existence of intellectual-property law: it relies on the structure of U.S. copyright law (USC§17) in order to subvert it. Free Software licenses are, in a sense, immanent to copyright laws—there is nothing illegal or even legally arcane about what they accomplish—but there is nonetheless a kind of lingering sense [pg 183] that this particular use of copyright was not how the law was intended to function.
Like all software since the 1980 copyright amendments, Free Software is copyrightable—and what’s more, automatically copyrighted as it is written (there is no longer any requirement to register). Copyright law grants the author (or the employer of the author) a number of strong rights over the dispensation of what has been written: rights to copy, distribute, and change the work.
This is a convenient ex post facto description, however. Neither Stallman nor anyone else started out with the intention of hacking copyright law. The hack of the Free Software licenses was a response to a complicated controversy over a very important invention, a tool that in turn enabled an invention called EMACS. The story of the controversy is well-known among hackers and geeks, but not often told, and not in any rich detail, outside of these small circles.
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 competitor (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 principal 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, [pg 184] 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 1962-63. 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, [pg 185] 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.”
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.’ ”
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-documenting” feature of the system). The program had a conceptual integrity that was compromised when it was copied imperfectly. EMACS has a modular, extensible design [pg 186] 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-documenting 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.”
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.
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 [pg 187] 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 participation 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 assumed 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.
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 entities, 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 [pg 190] 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).
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.
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 [pg 191] 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.
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:
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.
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 entity. 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 1983-85 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.
The GNU project initially received little attention, however; scattered messages to net.unix-wizards over the course of 1983-84 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.
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 entitled “The GNU Manifesto.”
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.
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.”
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 constitute 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).
Stallman replied the next day. [pg 195]
Nobody 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.
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.
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.
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 [pg 196] 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.”
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 attitude 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!”
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.”
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 documenting them, giving oral permission to use and reuse, and “losing” records that may or may not have existed—hardly a noble 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.
On 5 July, Stallman sent out a message that said: [pg 198]
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.
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 hassle you, don’t be, on the basis of version 16.56.
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 assumed he had permission [pg 199] to do, there was no innovation, only fear-induced caution.
Gosling’s sale of EMACS is thus of a different order from his participation 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 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 participants, 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 [pg 200] 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 participants 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.
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.
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.”
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 assumption 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.
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 divestiture and thus unable to engage in commercial exploitation of the software. When CCA sought to commercialize [pg 202] 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.
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 videocassette 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 title 17 of the U.S. copyright statute as something that could be considered copyrightable by law.
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 [pg 203] answered yes. It did not, however, designate what constituted “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.
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 assert 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. [pg 204] 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.
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 mass distribution.
Finally, the question of what constitutes 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 [pg 205] 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.”
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 asserting 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.
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 [pg 206] 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 assumed, 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 asserting 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.
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 participation in—and exclusion from—conferences and events devoted to Free Software. [pg 207]
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.
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.
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 illustrate how the GPL is more than just a hack: it was a novel, privately ordered legal “commune.” It was a space 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 [pg 208] 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 space, 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 entity, set apart from MIT and responsible only to itself. The Free Software Foundation took a classic 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 entity. 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, [pg 209] 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 passage 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.
/* This software is copyright (c) Mathematical Centre, Amsterdam,
* 1983.
* Permission is granted to use and copy this software, but not for * profit,
* and provided that these same conditions are imposed on any person
* receiving or using the software.
*/
Copyright: 2008 Duke University Press
Printed in the United States of America on acid-free paper ∞
Designed by C. H. Westmoreland
Typeset in Charis (an Open Source font) by Achorn International
Library of Congress Cataloging-in-Publication data and republication acknowledgments appear on the last printed pages of this book.
License: Licensed under the Creative Commons Attribution-NonCommercial-Share Alike License, available at http://creativecommons.org/licenses/by-nc-sa/3.0/ or by mail from Creative Commons, 559 Nathan Abbott Way, Stanford, Calif. 94305, U.S.A. "NonCommercial" as defined in this license specifically excludes any sale of this work or any portion thereof for money, even if sale does not result in a profit by the seller or if the sale is by a 501(c)(3) nonprofit or NGO.
Duke University Press gratefully acknowledges the support of HASTAC (Humanities, Arts, Science, and Technology Advanced Collaboratory), which provided funds to help support the electronic interface of this book.
Two Bits is accessible on the Web at twobits.net.
≅ SiSU Spine ፨ (object numbering & object search)
(web 1993, object numbering 1997, object search 2002 ...) 2024