Coding Freedom: The Ethics and Aesthetics of Hacking

developers who express an overt distaste for discussions of legal policy and actively distance themselves from this domain of polluting politics. But even though the superiority of technical over legal language, even technical over legal labor, is acknowledged among hackers—some hackers will even claim that it is a waste of time (or as stated a bit more cynically yet humorously by one developer: “Writing an algorithm in legalese should be punished with death [ … ] a horrible one, by preference”)—it is critical to recognize that geeks are in fact nimble legal thinkers. One reason for this facility, I suggest, is that the skills, mental dispositions, and forms of reasoning necessary to read and analyze a formal, rule-based system like the law parallel the operations necessary to code software. Both, for example, are logic oriented, internally consistent textual practices that require great attention to detail. Small mistakes in both law and software—a missing comma in a contract or a missing semicolon in code—can jeopardize the system’s integrity and compromise the author’s intention. Both lawyers and programmers develop mental habits for making, reading, and parsing what are primarily utilitarian texts. As noted by two lawyers who work on software and law, “coders are people who write in subtle, rule-oriented, specialized, and remarkably complicated dialects”—something, they argue, that also pertains to how lawyers make and interpret the law (Cohn and Grimmelmann 2003). 2
    This helps us understand why it has been relatively easy for developers to integrate the law into everyday technical practice and advocacy work, and avoid some of the frustration that afflicts lay advocates trying to acquire legal fluency to make larger political claims. For example, in describing the activists who worked on behalf of the victims of the Bhopal disaster, Kim Fortun (2001, 25–54) perceptively shows how acquiring legal fluency (or failing to adequately do so) and developing the correct legal strategy is frustrating, and can lead to cynicism. Many hackers are similarly openly cynical about the law because it is seen as easily subject to political manipulation; others would prefer not to engage with the law as it takes time away from what they would rather be doing—hacking. Despite this cynicism, I never encountered any expression of frustration about the actual process of learning the law. A number of developers I worked with at the Electronic Frontier Foundation or those in the Debian project clearly enjoyed learning as well as arguing about a pragmatic subset of the law (such as a particular legaldoctrinal framework), just as they did with respect to technology. Many developers apply the same skills required for hacking to the law, and as we will see, technology and the law at times seamlessly blend into each other.
    To offer a taste of this informal legal scholarship—the relationship between technical expertise and legal understanding, and how legal questions are often tied to moral issues—in one free software project, I will describe some of Debian’s legal micropractices: its routine legal training, advocacy, and exegesis. In order to deepen this picture of how developers live in and through the law, I proceed to a broader struggle—one where similar legal processes are under way, but also are more visible because of the way they have circulated beyond the boundaries of projects proper.
    “Living Out Legal Meaning”
    Just over a thousand volunteers are participating in the Debian project at this time, writing and distributing a Linux-based OS composed over twenty-five thousand individual software applications. In its nascency, Debian was run entirely informally; it had fewer than two dozen volunteers, who communicated primarily through a single email list. To accommodate growth, however, significant changes in policy, procedures, and structure took place between 1997 and 1999. The growth of Debian, as discussed in the last chapter, necessitated the creation of more formal institutional policies and procedures. Central to these procedures is the NMP, which not only screens candidates for technical skills but also serves as a form of legal education.
    Several questions in the NMP application cover what is now one of the most famous philosophical and legal distinctions in the world of free software: free beer versus free speech. Common among developers today, this distinction arose only recently,