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.