Source Code and Open Government
TSA security checkpoints require indentification before searches in order to enter an airport terminal. Frustrated that he had to show identification on a domestic flight, civil rights activist John Gilmore sued the TSA for what he believed was an unconstitutional law.
Unfortunately, his case stood no chance: the law was secret. The TSA argued that disclosing the law in question would compromise national security; a lower court accepted and Gilmore appealed strictly the secret law argument. The Supreme Court declined to hear his appeal, upholding the Ninth Circuit’s opinion that “that the government did not have to make public its rules about requiring airlines to ask passengers for identification.” Suprisingly, once the judge reviewed the law, he disclosed that in fact passengers are not required to show identification at the checkpoint, but may opt for a screening instead.
Here, a secret law prevented the public from reviewing its enforcement, and ultimately we discovered that its enforcement was plainly wrong. In general, it seems absurd that the judiciary would hide laws that affect everyday airline passengers from public scrutiny. Unfortunately, secret laws are increasing in complexity, changing forms, and becoming more widespread as our government moves further into the 21st century.
Software, not TSA officials, is becoming the primary enforcer of law and policy. Considering its precision it comes as no surprise that we are becoming increasingly dependent on software, rather than people, to enforce laws. DRM is a well-understood form of software law-enforcement; the IRS is accused of to stealing commercial tax return software in order to more efficiently enforce its own audits; every major business uses a software design element called policy objects to automatically enforce business policies between data and data consumers (such as the algorithm that determines which passengers are bumped off an oversold United flight, or which Bank of America customers receive courtesy fee waivers). Software performs so many tasks that today’s generation intuitively replaces people with software, recognizing that they perform one and the same task.
Conflicts arise when the specific activities of the software–its source code–is secret. Software which enforces laws is particularly troublesome. Though the laws most software enforces are public, the specific way it enforces those laws is not. This seems as absurd as a secret law for TSA checkpoints, yet courts have ruled differently. In a Florida DUI case, a judge has ruled that breathalyzer manufacturer CMI must release its devices’ source code to the defense. Since companies rarely release their copyrighted and secretive source code, the defense likely requested the code as its primary strategy to win dismissal. Yet their argument consequently enabled freely-available source code in law enforcement. And statewide, the defense attorney opines that “that outside corporations cannot sell equipment to the state of Florida and expect to hide the workings of their machine by saying they are trade secret.” In other words, this case generated a revolutionary attitude towards source code in government: it its an implementation of policy, it, like the policy, must be free to inspect.
There has been little indication that the incoming administration acknowledges the complexity of ‘policy objects’. So much of what we do today is a set of rules implemented in software; we have always accepted the specification in lieu of the software code itself. A DUI case is an awful place to demand an open source government: We mustn’t allow software to be a loophole under which secret policies can hide. The TSA may liberally misapply secret laws; that’s dangerous, and an open government means eliminating secret laws in the first place. We must demand that source code be freely available and open to public scrutiny, just as we demand for the rest of government.

