Code Is Law, Or Is It?:
One of the buzzphrases often heard in cyberlaw circles is that "code is law," an idea popularized by Lawrence Lessig. The basic idea is that computer code can shape the experience and options available to Internet users. Because law is also a means of attempting to shape human experience and options, code and law are in essence trying to do the same sort of thing. They are both ways of regulating environments.

  I confess that I have never been particularly enamored of the "code is law" formulation. It seems to me that "code is law" only to the extent that lots and lots of things are law. If the test for law is what regulates human behavior and experience, then it seems that physics is law, chemistry is law, fear is law, greed is law, human eyesight is law, etc. At such an abstract level, saying that something is "law" doesn't seem to have a great deal of meaning. Indeed, in my experience "code is law" has become a shorthand used among cyberlaw types to remind ourselves that code is important. Law professors naturally look for legal answers to human problems, and "code is law" reminds us that techie solutions may work just as well as or better than legal ones.

  So if code is not law, what is it? If you're interested in that question, I recommend that you check out Yale Law student James Grimmelmann's just-published law review note, Regulation by Software (.pdf). Grimmelmann has a somewhat similar skepticism about the "code is law" formulation, and he offers an interesting and quite useful discussion of the differences between regulation by law and regulation by software. Here is the abstract:
This Note builds on Larry Lessig's famous formulation that "code is law" to argue that Lessig was wrong to equate computer software with physical architecture. Although software resembles both law and architecture in its power to constrain behavior, it has features that distinguish it from both. The Note identifies four relevant attributes of software: It is ruleish, potentially nontransparent, impossible to ignore, and vulnerable to sudden failure. By assessing the impact of these characteristics in a given context, one can decide whether software is a good or a bad choice to solve a regulatory problem.
  While I'm at it, kudos to the editors of the Yale Law Journal for their smart and helpful way of publicizing their latest issue. I knew that the Grimmelmann note was published and online because I signed up for the YLJ's online mailing list. The list sends out an e-mail whenever a new Journal issue is published; the e-mail contains abstracts of each piece in the issue together with links to .pdf copies posted on the Journal's website. It provides a very easy and convenient way for readers to follow, read, and even blog about new scholarship. I hope other law reviews follow the YLJ's lead.
The problem here in querying how useful "code is law" may be is how abstractly you choose to think about it. Lessig's formulation in particular seems to highlight how both code and law are artificially authored, rather than, say, natural guidance. It's true that we often refer to natural, unauthored manifestations as "laws" (the law of gravity, the law of diminishing returns), but Lessig's observation is not predicated merely on broad attributes common to all these things.

In other words, I don't think Lessig's "test" for what constitutes law is merely what regulates human behavior and experience. I think the formulation focuses crucially, albiet perhaps not primarily, on the requirement of measured human content. This aspect of both code and law is what differentiates it in a non-trivial manner from the "laws" of physics, fear, and eyesight; this aspect is also of deeper import than the observation that techie solutions may be as compelling as legal ones.
6.18.2005 12:28am
Dan Simon (www):
For those interested, Ed Felten's Freedom to Tinker blog is hosting a "book club" on Lessig's Code.

I think the "code is law" analogy is even worse than the above criticisms suggest. Lessig obviously meant to suggest that "code is law" in the same sense that "chemistry is law", or "human eyesight is law"--that is, it's an existing set of constraints on human behavior, that people have to accept and deal with. But in fact, code is something written by people, deployed by people, run by people, changed by people, and deleted by people, all of whom have their reasons for doing what they do with particular bits of code. It's much more like roads, fences, cars, or telephones--a collection of useful objects created for a purpose and employed by its users for a (possibly different) purpose. True, the innate properties and limitations of any one of these classes of tool imposes constraints on the way people use it. But even so, would a catchphrase like "cars are law" ever catch on? What would it mean? And how would it help our thinking in any way about law or public policy?
6.18.2005 12:34am
Stephen Lindholm (www):
I was not impressed with the note. It seems the author does not have much of a background in computer engineering, or at least does not understand the social issues at a deep level.

For example, his claim that the law is not "rulish" and does not reach very deep is simply not true, as any grandmother who was sued by the RIAA/MPAA for enormous (statutory) damages and was forced to settle, pragmatically, for $10,000, can attest to. (Even if the files the granddaughter was trading were over-the-air recorded TV shows, in which case the actual damages, in the absence of legislation, would be $0.) There are many laws which are rulish in their application, and enforceable. Tax laws are another area where there is no wiggle room. My uncle used to work at the IRS, and he would tell people that it doesn't matter whether they bring an accountant or a tax lawyer to the audit, because the end result would be the same either way (modulo huge legal fees).

On the other hand, there are laws which employ standards, either in their definition (fraud laws) or application (speed limits), but that hardly supports a a distinction. There's really nothing profound in that part of the note. I could go on to other things he says, but why bother.

Some of the freshman-level CS concepts he threw in (like the Church-Turing hypothesis) irked me, because they add nothing and seem like the sort of thing that would only serve to confuse and impress people without an engineering background.

The interesting application of "law = code" is in something the author only briefly alluded to: Who writes the law? If, say, a publisher wants to extend copyright through law, he has to lobby hundreds of congressmen openly. But if he writes the code himself (Adobe eBooks), or controls access to the code (DVD Forum), or has economic power over the company that writes the code (record labels against Apple), he can essentially write whatever restrictions maximize his objective, regardless of what anybody else wants or even what's in the constitution. (Copyright may only be 120+ years, but an encrypted song will remain that way forever, unless someone breaks the encryption.)

To say "code = law" just means "code = important" seems to miss the point. How does "code = important" encapsulate what I just said? Family is important, too, just like food and clean water, but that's a bit of a non sequitur here.

And saying that code regulates behavior in the same way as a "car," also makes no sense. If a company wants to restrain the behavior of others to increase its profits, how is "car" the answer? Or "chemistry"? There's no chemical reaction that would prevent a teenager from loaning a book to a friend, but it's really easy to write a computer program to prevent loaning eBooks.
6.18.2005 2:09am
Jeff Licquia (mail) (www):
I suspect that the power of Lessig's analogy comes more from the software tech side of things than the legal side, because "code as law" captures something about the structure of our work that resonates with us.

I suppose the difference from "cars as law" (even as that phrase might be interpreted by mechanics) is that we don't expect to be able to plug something into the cigarette lighter and gain the ability to fly, or change the laws of physics to accomodate traffic laws when they become inconvenient. In the online world, both of these kinds of things have happened, and continue to happen.

That said, I've made it through a good bit of Grimmelmann's paper, and he seems to capture that same something very well. I recommend it for the first part by itself, which does an excellent job of analyzing how code is like and not like law and architecture.
6.18.2005 3:05am
Dan Simon (www):
And saying that code regulates behavior in the same way as a "car," also makes no sense. If a company wants to restrain the behavior of others to increase its profits, how is "car" the answer?

Actually, it's a perfectly reasonable answer. Automakers can choose, if they like--and they sometimes do--to make some or all of their replacement parts or maintenance services proprietary, thus requiring their customers to purchase replacement parts and service at certified dealers, who are in turn bound to abide by certain agreements with the manufacturer. This arrangement can make good business sense--allowing the automakers, for instance, to reduce the MSRP on their cars, while reassuring their dealers that they can recoup their reduced profits through higher maintenance charges. (It can also make bad business sense, of course--for example, if consumers learn to evaluate car prices based on long-term ownership costs, and start avoiding cars that require proprietary replacement parts and maintenance.)

As far as I can see, this technique, which is really just part of the standard bag of engineering/manufacturing/business tricks, is indistinguishable from what an e-book retailer does with its code. Indeed, one of the forms of maintenance that automakers can make difficult or impossible for competitors is administration of the "code" that runs on the car's onboard computer. How is that any different from giving a replaceable part a (proprietary, patented) funny shape, to protect the manufacturer's replacement-parts revenue from parts cloners? And how is either materially different from an e-book company restricting the way its books can get copied or displayed?
6.18.2005 3:23am
Dan Simon (www):
I suppose the difference from "cars as law" (even as that phrase might be interpreted by mechanics) is that we don't expect to be able to plug something into the cigarette lighter and gain the ability to fly, or change the laws of physics to accomodate traffic laws when they become inconvenient.

No, but to auto mechanics enthusiasts ("hackers"?), the possibilities inherent in a new car are roughly as exciting, and the limitations automakers sometimes place on them similarly frustrating.

And I think that's what "code is law" is all about--not how code sometimes restrains behavior (as I pointed out, that's about as interesting as the way cars restrain behavior), but rather code's extraordinary potential to remove constraints on behavior. This potential excites and energizes code enthusiasts to view the everyday constraints imposed by code for business or engineering reasons as a kind of affront--much the way old-school auto mechanics enthusiasts despise automatic transmissions and onboard computers.

The problem with this view is that most people don't see code (or cars) as a liberating salvation, but rather as a useful tool for getting things done and deriving a little entertainment. For those of us with a utilitarian, rather than romantic, view of code, the constraints it imposes on our behavior are like the constraints any other tool, such as a car, imposes: a tradeoff to be evaluated matter-of-factly against the alternatives. Does it stop me from doing what I want to do with it? Make me pay more? Do its drawbacks ultimately outweigh its benefits? Is there an alternative available that strikes a better balance? If the answer to these questions is "no", then we are inclined to think of our use of it as a sensible decision, rather than as some kind of capitulation to the surreptitious evil influence of all-powerful "code".
6.18.2005 3:54am
Stephen Lindholm (www):
When Prof. Lessig explained the architecture analogy when I was in the audience, he used the example of some town in the civil rights era where the leaders wanted to keep the beaches segregated -- because the law wouldn't permit the city to discriminate, they made the bridges over the roads to the beach low. Black people, using public transit, could not get to the beach because the buses couldn't fit under the bridges.

I think that's a pretty good example of architecture being used to fill in where law would not be available. There (thankfully) aren't many like it, so it would be a stretch to say that architecture equals law. There are many more relating to digital media and the law, so it's fair enough to say that "law = code," although I hadn't heard that expression until today and I'm a fairly regular reader of boingboing and slashdot, so I'm not sure how many CS people actually use it.

I'm not sure about the car example. The essence seems to be that trade secret can be used as a substitute for patent, is that it? If you want to keep people from installing replacement parts, and you can't patent the replacement parts, then you can keep the designs or diagnostic procedures secret and that works well enough to keep an exclusive market (here on after-sales service). That's a fair enough example of substituting X for law, but it's a rather tenuous relationship to "car = law." It seems the "car = law" example was supposed to be a nonsensical label for a strawman.

All that aside, I'm just disappointed that Yale chose to run that note. I've read a lot of notes which gave me something new to think about, even from the journals of schools not ranked nearly as high. But I wasn't even convinced of this note's rigor, and I didn't see anything there I hadn't heard before. (I guess that's why there are committees to vote, rather than just one guy. In law school I was on the losing side of an article vote at least once.)
6.18.2005 4:20am
Joseph Liu (mail) (www):
I think it's important to distinguish between how the phrase "code is law" is understood more broadly, and how the phrase is used by Lessig in his book. I think Orin's criticism is more fairly directed at the former rather than the latter.

Lessig himself is pretty careful about laying out what he means by the phrase "code is law." Code regulates behavior, but it differs from the law of gravity in that it is designed by humans. It is thus more akin to the built environment (e.g. speed bumps for regulating driving speeds).

On the one hand, this is a pretty straightforward observation. But he then goes on draw out what are, I think, some nice points, e.g. how code is more malleable (and therefore may have greater power to regulate behavior); how code, law, and norms can interact and affect each other, (e.g. DMCA) etc.

One risk that authors take when they coin a catchy phrase like "code is law" is that others will take the term to mean different things, but I think Lessig himself is a bit more precise about this.
6.18.2005 11:56am

I'd be interested in hearing more about how Lessig is more precise; I've read his book many times, and it's entirely possible that I am just missing something. But for now let's stick with your example, built environments. Are built environments considered "law" in a useful sense? It is obvious that built environments can be used to achieve the same ends as law. If I want to keep people from burglarizing my house, my first instinct will be to buy a good lock and strong doors. I gather that in Lessig's formulation this is a "code" solution. Burglary laws are also ways of trying to stop people from burglarizing houses, and so in some sense you could say that law and code are different tools for trying to achieve the same goals, namely stopping burglaries. But what does that explain?

If the purpose is to point out that the decisions that shape our built environments can have legal or constitutional implications, that is true but seems somewhat unremarkable. For example, if a town council votes that bridges must be built in a way that keeps the buses out because they want to exclude African-Americans from going to the beach (Lessig's example as recounted by Lindholm above), that decision to require that bridges must be built in a particular way is a legal decision. Maybe I am missing something, but it seems to me that it can be challenged on legal grounds just like any other legal decision by a town council.
6.18.2005 1:01pm
Paul Gowder (mail):
It seems to me that "code is law" only to the extent that lots and lots of things are law. If the test for law is what regulates human behavior and experience, then it seems that physics is law, chemistry is law, fear is law, greed is law, human eyesight is law, etc.

Let me submit that physics, chemistry, fear, greed, and human eyesight are law to the extent that we can control them.

The simplified way to answer that argument as I understand it is that architecture/code is law to the extent that, like law, it represents a constraint on human behavior that is the function of conscious or unconscious choices by humans. If I build a street in front of the state capitol building with sidewalks so narrow and roads so wide and speed limits so high that it's impracticable for demonstrators to safely get in front of the building, it's just as much a regulation of free speech as if I have guys with sticks and guns and badges imposing the same functional effect.
6.18.2005 3:51pm
Joseph Liu (mail) (www):

It may be that I am missing something, or that at the very least, I'm interpreting Lessig through my own idiosyncratic lens.

I think we are in agreement about Lessig's basic claim, that code regulates behavior in much the same way that the built environment regulates behavior. (So, to be clear, we're not talking about the law of gravity).

As I said, that's a pretty straightforward point. But I, at least, found persuasive the argument that code has the potential for playing a greater regulatory role in a digital, networked environment, due to code's ubiquity and malleabilty.

Lessig also makes the point that law can affect code in ways that make behavior more regulable. For example, a law that requires web sites to label their own content may affect the "built environment" in a way that makes future regulation easier.

It's true that one can find analogs in the non-digital world. A law requiring everyone to carry around a national i.d. card may enable all sorts of additional regulation (whether by law, norms, markets, or code).

But I didn't read Lessig as making the strong exceptionalist claim that this is completely new. (Indeed, I believe he cites a lot of these real-world examples.) If anything, it seemed to me that his book was an attempt to respond to the exceptionalist claim that the internet could not be regulated - by pointing out that the code itself regulates and can be regulated.

Again, though, this may simply be my own idiosyncratic gloss on the book.

6.18.2005 5:22pm
James Grimmelmann (mail) (www):
Thanks, Orin, for the kind words and for turning your interesting musings on the phrase "code is law" into an even more interesting public discussion. "Code is law" is a slippery phrase, because there are a lot of interesting ideas wrapped up in there. I helped the EFF's Cindy Cohn come up with eight possible meanings of the phrase for a speech she delivered at the 2003 Ars Electronica Festival:

1) In the dictionary, a "code" is a collection of laws.

2) Code is law, transplanted to the electronic realm.

3) Law is a kind of code in that lawyers use laws to "program" the legal system and society.

4) Good code helps enable the kind of society in which good laws are possible.

5) Code is increasingly the subject of law, law that controls how code is made and used.

6) Code doesn't equal law, because law includes the people who make laws and the meanings they assign to those laws, not just the text of the laws themselves.

7) In spaces controlled by code, the code fills the role usually associated with law.

8) As code takes on the powers of law, it must also take on the responsibilities of law.

Cindy herself prefers the alternative phrasing "architecture is policy," which focuses one's attention on the last two meanings. But "code is law" picks up on the pun between the two meanings of "code." Lessig explicitly points out how felicitious the pun is; I think this connection is part of the reason why the phrase is so catchy. This multiplicity of meanings makes it easy for people to use "code is law" as shorthand for a deep idea without having to agree on the precise contours of that deep idea.

The problem is that it's used as a shorthand for several deep ideas, all of which are important but at least one of which isn't literally true. That's why I opened "Regulation by Software" with the two Lessig quotations I chose — in the first, he says that code is law, and in the second, he says it's architecture. My argument in the Note is that it's neither, but to explain why, I first have to explain why Lessig can say that it's both without contradicting himself. As I see it, it's the "modalities of regulation" analysis that does the work. To Lessig, code "is" law in the sense that architecture "is" law or a market "is" law: All of these different modalities regulate conduct. To Lessig, Code "is" architecture in the sense that it then regulates conduct in the same way that architecture does — it's this latter claim that I think needs to be modified.

Though I'm critiquing "code is law" as a slogan, I still think Code is a great book. It inspired me, in part, to leave my job as a programmer and to apply to law school instead of a PhD program in computer science; it did so by convincing me that truly good lawyers understood technology on a deep level. "Regulation by Software" is an attempt to return a bit of the favor, to say, hey, I'm a technologist and I think these ideas are both neat and important.

Something else I'd like to point out, while we're praising the Yale Law Journal's open-access policies, is the Creative Commons license in the first footnote. I was very happy that the Journal was willing to let me include it. Though it doesn't kick in until next year (as a way of protecting the Journal's first-publication privilege) it's still right there on the first page and their standard author contract was generous enough to enable a generous CC license.
6.19.2005 12:08am

You may be right; fair point. To be honest, one of the difficulties I had with "Code" is that I found it difficult to tell exactly what claim Lessig was advancing at various stages of his argument. "Code" features lots of intervwoven themes and possible directions, and at times the I wasn't able to tell which theme or direction Lessig was pursuing. Perhaps that's just the difficulty of writing a book for a generalist audience.
6.19.2005 12:17am
John Rice (mail):
I think that Grimmelmann's argument passes over the important question of what exactly software is. In my experience that term is often ambiguous. Software, code, and program are all words that are frequently used interchangeably but that are not equivalents. Indeed, at least outside of the discipline there seems to be a lot that is conceptually fuzzy. Here I am reminded of the perennial debate over what is properly considered part of an operating system versus software that is merely running on the operating system. When Grimmelmann asserts that a "you can hack a computer program into destroying itself", he is unwittingly glossing over a host of issues that need clarification. To me, this statement suggests a certain level of systemic complexity that at least deserves discussion. Besides answering the question of what a program is (for instance, Microsoft Word could be said to be a composition of many programs), there is the question of what is meant by the idea of a program destroying itself.

More important, I have not read Lessig's book but I would suggest that a weakness of Grimmelmann's argument is that to its detriment it conflates the terms "code" and "program". Code expresses a program but on its own it doesn't do anything. For that it requires an interpreter to enact what it expresses. Therefore, while a program may be unlike a highway, code rather is; it just lays there. Therefore too, the maxim "code is law" is not equivalent to one that asserts "programs are law".
6.19.2005 12:20pm
Richard Bennett (www):
Lessig's "code is law" formulation doesn't make any sense outside its goal, which is to immunize the Internet from government regulation and modification by commercial interests. He's come under the spell of some eccentric network engineers who believe the Internet was born into a state of perfection in 1981 and that it can only suffer from any modification that takes it from its golden age.

His argument, which is so clever that it's cute, like all Lessig arguments, is that the architecture of the Internet is to its evolution as the Constitution is to the American system of law and government. Strict constructionists and textualists speak with reverence about the Framers and their pure founding vision, and Lessig wants us to do likewise with the Designers of the Internet, never straying from their perfect and semi-divine inspiration.

It as nonsensical as the position that any other product of engineering should be immune from regulation, like the Ford Explorer or something. The Internet, at the end of the day, is a machine that has to do whatever we want it to do.

I've personally been engaged in the business of network engineering and standards-writing for several year, and also have done enough legislative lobbying to have had a hand in crafting actual law. In neither arena have I ever encountered people who speak of Lessig with respect, nor have I encountered anyone sane who believed that networks or other engineering artifacts are or should be beyond government regulation.
6.20.2005 6:53am
Paul Gowder (mail):
Richard: you're just wrong.

Take a look at Code and Other Laws of Cyberspace. Lessig never said in Code that the code shouldn't be changed. He took a position on certain changes (i.e. PICS = bad -- a fairly uncontroversial position by now), but the main thrust of the book as I've always read it has been "hey, people, we need to make these code decisions consciously, not by default!"

In his words from the book (I don't have a page ref handy, I'm working off [as-yet unchanged text from] the wiki version):

It is against this background that we should think about the problems raised in part 3. In each case, my argument was that we will need to choose the values we want cyberspace to embrace. These questions are not addressed by any clear constitutional text or tradition. In the main, they are questions affecting the codifying part of our tradition, but they are also cases of latent ambiguity. There is no "answer" to them in the sense of a judgment that seems to have been made and that a court can simply report. An answer must be fixed upon, not found; made, not discovered; chosen, not reported.

Not only that, but you implicitly report Lessig's position as "that networks or other engineering artifacts are or should be beyond government regulation." In fact, in Code, he explicitly opposes this vision of the role of government in the internet. He defines himself in opposition to the radical libertarianism and non-net-interventionism of the likes of Declan McCullagh (cf. Code ch. 17).

I don't know where you get this idea that Larry Lessig is some kind of "the government shouldn't be allowed to regulate the internet ever" cyber-anarchist. Maybe he secretly is, but I've read much of his writing, and I've never seen it.
6.20.2005 3:13pm
Richard Bennett (www):
You raise another interesting point, Paul, one that's more interesting than my (possibly flawed) interpretation of Lessig's project. The statement: "In each case, my argument was that we will need to choose the values we want cyberspace to embrace" suggests that Lessig wants engineering decisions to be subordinated to the requirements of (somebody's vision of) public policy. Hence, when we engineers design a network architecture would shouldn't just think about efficiency, reliability, and the richness of our service set, we should allow our technical visions to be directed by the (allegedly benign) forces of public policy do-goodism, endeavoring to produce architectures that promote recycling, ethnic and gender diversity, free speech, free music downloads, and democracy in the Third World.

This essentially recapitulates the old argument that art must serve the social need for moral education rather than simply existing for its own sake, and casts Lessig in the role of the stern preacher of the Apocalypse that many have seen in his books.

I like that twist on Lessig much more than my original one, so thanks for suggesting it.
6.20.2005 5:18pm
Paul Gowder (mail):
Richard: good, I like that twist on Lessig better than your original one too. Is it all that controversial to suggest that our uses of technology should be shaped by our public policy choices and our values? I hope not.
6.20.2005 5:49pm
Richard Bennett (www):
If we're talking about unrelated public policy choices that we hope to influence indirectly through regulations on private enterprise, yes that is controversial, and it requires regulators to have nearly divine intelligence.
6.20.2005 6:36pm
Richard Bennett (www):
BTW, I haven't read "Code". I read and critiqued "The Future of Ideas" but it was so full of crap I lost the ability to deal with Lessig's prose afterwards. It was easy to debunk because there were a lot of factual assertions that were easy to prove wrong, such as his theories about how the Ethernet and the Internet work.

Doesn't he make the same arguments in code, that technical artifacts have important third- and fourth-order effects that have to be anticipated and shaped by mystical entities? He seems like a guy with only one idea.
6.20.2005 6:40pm
Paul Gowder (mail):
"We can't regulate business because it's just too hard?" That's a new one.
6.20.2005 7:18pm
Richard Bennett (www):
Nobody ever thought to regulate unforseeable consequences while still unforseen before Lessig. This is a rich new field of research.
6.20.2005 7:28pm
Paul Gowder (mail):
Richard: first you attacked Lessig because he was an anti-regulation anarchist, then, when I pointed out that he's not against all regulations, you attack him as a totalitarian unforeseen-consequence-chaser. What's your agenda here? Lets see...

1. You're against anti-regulation: so obviously, you believe someone needs to regulate the internet and your fellow technologists;
2. You're against government regulation.

Who is left?

Oooh, I know who is left! Our upstanding citizens in the Business Community! It's nice to know that you prefer your governors to be unelected.
6.21.2005 10:29am
Richard Bennett (www):
Alas, Paul, I have no ax to grind on regulation; I'm happy with the American system of law where the government regulates those of our activities that affect others and their instrumentalities as well. It seems that the effort to regulate the unknowable isn't very productive. But this discussion isn't about me, so unfortunately your dichotomy in extremis doesn't really have any zing.

If your reading of Lessig's "Code" is correct, the Professor has shifted his ground since "Future", most likely in response to his critics. I hadn't wanted to read any more of his books, but thanks to this discussion I will because it sounds like a good laugh.

In many ways, Lessig is the Terri Schiavo of American intellectual life; while his admirers insist that his brain is robust, that he communicates with his audience and responds to important events in the world, others see the brain of Lessig as a seriously damaged organ. Perhaps we need an autopsy to know for sure.
6.21.2005 3:31pm
Paul Gowder (mail):
Richard: I'll tell you what. You finish getting your savage revenge on those evil evil strawmen who want to "regulate the unknowable," and then when they're roundly beaten into bales of horse-food, we can talk about Lessig.
6.21.2005 3:38pm
Luis Villa (mail) (www):
I think Joe and Paul get the closest to the gist Lessig originally intended. (I've not finished Grimmelman, so I'm not sure where he stands on this, though my early sense is that he doesn't really understand Lessig's original claims either.) Lessig's emphasis when he coined 'code is law' *was* on the malleability and importance of code, and the implications thereof.

'Code' was written partially as a response to Declan McCullough and other early 'net utopians who felt that the 'net and things that took place on the net were inherently unregulable. Part of their position was that the laws of the 'net were like the law of gravity and other physical qualities- the net just was, and nothing government or people could do could change that fundamental nature. In contrast, Lessig was very explicit that code (like legal law, as opposed to laws of physics) is written by humans (or groups of them), and is hence suspect to all the influences that impact traditional forms of law- economic, political, etc. Hence the emphasis on open source for infrastructure, as opposed to putting it in the hands of corporations. In retrospect, Lessig was so clearly right about this and Declan so clearly wrong that it is easy to forget that this was part of his message.

Lessig's second important (misunderstood) intent, IMHO, in discussing code-as-law, was to highlight the *importance* of code. Our tendency when making policy of all sorts is to focus on East Coast legal code, and ignore laws like gravity, or the physical layout of our buildings, because, well, those things are the way they are, and always have been. So why worry about them? Particularly when Code was written, but still, I think, frequently today, we take the regulations created by code as physical, permanent givens (like gravity) when in fact they are malleable (like legal code.) When discussing the law of the sea, the fact that boats sink is taken for granted. In 'net law, up until Lessig, the nature of the 'net was often also taken for granted- 'of course the software is open- why wouldn't it be?' I believe Lessig's formulation was intended to emphasize that the function of the code couldn't be taken for granted- since the code could change at any time (unlike physical architecture or so-called laws of nature), it had to be analyzed and understand as part and parcel of any analysis of law on the 'net. Again, this is more obvious now than it was when Lessig wrote Code- the changing nature of the code (like deCSS, and the p2p wars) have given us frequent reminders that code can change the entire landscape of regulation, and quickly.

So... I haven't finished Grimmelman, but so far it seems to me that he is strongly implying that Lessig's view of code is a static one, and that seems to me to be a bad misreading of the historical context- when Lessig said code was law, he was clearly emphasizing that code was more fungible, more important, and more changing than early 'net folks had assumed.
6.22.2005 1:02am
Richard Bennett (www):
No Luis, the infrastructure of the Internet is not Open Source, and has never been. Sure, there have been open implementations of the end-point code since the early 80s, but that stuff isn't the infrastructure, it's only the outer edge. The Cisco routers that make the whole thing work are anything but Open Source, and they actually have a lot of special features and quirks that aren't specified by the open documents (RFCs) that allegedly define the net. The infrastructure routes packets and updates routing tables, and it's never been as static as the rules for FTP and TCP.

Declan is right in the practical sense that no one government can regulate the net, because there are too many ways to get around whatever arbitrary rules they may want to impose. Look at what's happening in China with the regime's speech regulations and the "adopt a blogger" movement to circumvent them. On the larger point of whether they should he's wrong, of course.

It's also the case that law regulates the architecture of buildings, or have you not heard of Building Codes?

I honestly don't know who's more clueless, the law processors who opine about net regulation without understanding networks, or the engineers who opine about changing the world without understanding the political process.
6.22.2005 10:21pm