Regulation by Software

Citation: James Grimmelmann (2005) Regulation by Software. The Yale Law Journal (RSS)
Internet Archive Scholar (search for fulltext): Regulation by Software
Download: http://www.yalelawjournal.org/pdf/114-7/Grimmelmann.pdf
Tagged:

Summary

Author writes Lessig stipulated categories of law, social norms, markets, and physical architecture, and that software is a subspecies of physical architecture.

But software is automated, immediate, and plastic. In the first two, like physical architecture, in the third, like law. Interplay gives software distinct consequences.

4 patterns present in regulation by software:

• Rule, not standard (ruleishness)
• Can lack transparency (opacity)
• Cannot be ignored (ubiquity)
• Relatively fragile (including hackability)

By reviewing particular software regulation against these patterns, can predict consequences and evaluate normatively. Quote:

If discretion is unnecessary, the need for transparency low, the potential additional transaction costs small, and the risk of software failure untroubling, then regulation by software is a good fit to the task at hand. If, on the other hand, one or more of these conditions do not apply, the shape of the inquiry shifts. The question then becomes whether one can take steps to mitigate the undesirable consequences of choosing software—with the costs and consequences of those steps factored into one’s overall normative evaluation of whether software is the best choice among modalities.

Online auctions and DRM evaluated as case studies; former well suited, latter not.