A crucial assumption is built into all these examples. I’ve assumed that there are entities responsible for the code that individuals use, and that these entities can be effectively regulated. And as the open code software movement grows, it is important to ask whether this assumption is really true. The government can regulate the telephone companies (they are few in number, well known, and loaded with tangible assets), but how can it regulate code writers? In particular, how can the government regulate code writers who are committed to resisting precisely such regulation?

This is the topic of the last chapter in part 2—the effect of the open code movement on government’s power to regulate. But we can make a few points here.

In a world where the code writers were the sort of people who governed the Internet Engineering Task Force¹ of a few years ago, government’s power to regulate code would be slight. The underpaid heroes who built the Net have ideological reasons to resist government’s mandate. They are not likely to yield to its threats. And unlike some commercial interests, they do not have millions riding on a single architecture winning out in the end. Thus, they would provide an important check on the government’s power over the architectures of cyberspace.

But as code writing becomes commercial—as it becomes the product of a smaller number of large companies—the government’s ability to regulate it increases. The more money there is at stake, the less inclined businesses (and their backers) are to bear the costs of promoting an ideology.

The best example is the history of encryption. From the very start of the debate over the government’s control of encryption, techies have argued that such regulations are silly. Code can always be exported; bits know no borders. So the idea that a law of Congress would control the flow of code was, these people argued, absurd.

The fact is, however, that the regulations had a substantial effect. Not on the techies—who could easily get encryption technologies from any number of places on the Net—but on the businesses writing software that would incorporate such technology. Netscape or IBM was not about to build and sell software in violation of U.S. regulations. The United States has a fairly powerful threat against these two companies. As the techies predicted, regulation did not control the flow of bits. But it did quite substantially inhibit the development of software that would use these bits.²

The effect has been profound. Companies that were once bastions of unregulability are now becoming producers of technologies that facilitate regulation. For example, Network Associates, inheritor of the encryption program PGP, was originally a strong opponent of regulation of encryption; now it offers products that facilitate corporate control of encryption and recovery of keys.³ Key recovery facilitates a corporate back door, which in many contexts is far less restricted than a governmental back door.

Cisco is a second example.⁴ In 1998 Cisco announced a router product that would enable an ISP to encrypt Internet traffic at the link level—between gateways, that is.⁵ But this router would also have a switch that would disable the encryption of the router data and facilitate the collection of unencrypted Internet traffic. This switch could be flipped at the government’s command; in other words, the data would be encrypted only so long as the government allowed it to be.

The point in both cases is that the government is a player in the market for software. It affects the market both by creating rules and by purchasing product. Either way, it influences the supply of commercial software providers who exist to provide what the market demands.

Footnotes

¹ See the description in Scott Bradner, “The Internet Engineering Task Force,” in Open Sources: Voices from the Open Source Revolution, edited by Chris DiBona et al. (Sebastopol, Calif.: O’Reilly & Associates, 1999). Edit Delete

² Michael Froomkin makes a similar point: “Export control rules have had an effect on the domestic market for products with cryptographic capabilities such as e-mail, operating systems, and word processors. Largely because of the ban on export of strong cryptography, there is today no strong mass-market standard cryptographic product within the U.S. even though a considerable mathematical and programming base is fully capable of creating one”; “It Came from Planet Clipper,” 19. Edit Delete

³ See “Network Associates and Key Recovery,” available at http://web.archive.org/web/19981207010043/http://www.nai.com/products/security/key.asp Edit Delete

⁴

Cisco has developed products that incorporate the use of network-layer encryption through the IP Security (IPSec) protocol. For a brief discussion of IPSec, see Cisco Systems, Inc., “IP Security–IPSec Overview,” available at http://web.archive.org/web/19991012165050/http://cisco.com/warp/public/cc/cisco/mkt/ios/tech/security/prodlit/ipsec_ov.htm. For a more extensive discussion, see Cisco Systems, Inc., “Cisco IOS Software Feature: Network-Layer Encryption—White Paper,” available at http://www.cisco.com/warp/public/cc/so/neso/sqso/eqso/encrp_wp.htm; Cisco Systems, Inc. “IPSec—White Paper,” available at http://web.archive.org/web/20020202003100/http://www.cisco.com/warp/public/cc/techno/protocol/ipsecur/ipsec/tech/ipsec_wp.htm ; see also Dawn Bushaus, “Encryption Can Help ISPs Deliver Safe Services,” Tele.Com. March 1, 1997; Beth Davis and Monua Janah, “Cisco Goes End-to-End,” Information Week, February 24, 1997, 22.

⁵ See Internet Architectural Board statement on “private doorbell” encryption, available at http: //www.ietf.org/mail-archive/ietf-announce/msg01937.html (visited May 31, 1999). Edit Delete