Courts have traditionally allowed software companies to avoid handing over their source code in litigation — under the legal doctrine that the software source code contains trade secrets — trade secrets which would be disclosed, and therefore legally jeopardized, by discovery to third parties. This has been particularly true within the ‘breathalyzer’ industry which — like the electronic voting machine industry — has fought attorneys’ third-party subpoenas (SDTs) for years. By refusing to turn over source code, software developers are refusing to provide criminal defendants with a means to challenge the accuracy of the machines in court and therefore, to challenge the test results which lead to an arrest, a legal presumption of guilt, and a possible felony conviction.

Breathalyzer software source code: not ready for prime time
Courts in Minnesota, Florida, and now New Jersey have begun ordering manufacturers to turn over their source code for evaluation by experts under nondisclosure. Here are some of the excerpts from an expert witness analysis on the accuracy and reliability of the Alcotest breathalyzer source code, as reported in DUI Blog:

1. The Alcotest Software Would Not Pass US Industry Standards for Software Development and Testing: The program presented shows ample evidence of incomplete design, incomplete verification of design, and incomplete white box and black box testing . . . Several sections are marked as “temporary, for now” . . . It is clear that, as submitted, the Alcotest software would not pass development standards and testing for the US Government or Military. It would fail software standards for the Federal Aviation Administration (FAA) and Food and Drug Administration (FDA), as well as commercial standards used in devices for public safety . . . If the FAA imposed mandatory alcohol testing for all commercial pilots, the Alcotest would be rejected based upon the FAA safety and software standards . . .

4. Catastrophic Error Detection Is Disabled: An interrupt that detects that the microprocessor is trying to execute an illegal instruction is disabled, meaning that the Alcotest software could appear to run correctly while executing wild branches of invalid code for a period of time. Other interrupts ignored are the Computer Operating Property (a watchdog timer), and the Software Interrupt. [emphasis mine]

6. Diagnostics Adjust/Substitute Data Readings: The diagnostic routines for the Analog to Digital (A/D) Converters will substitute arbitrary, favorable readings for the measured device if the measurement is out of range, either too high or too low. The values will be forced to a high or low limit, respectively. This error condition is suppressed unless it occurs frequently enough . . . [emphasis mine]

7. Flow Measurements Adjusted/Substituted: The software takes an airflow measurement at power-up, and presumes this value is the “zero line” or baseline measurement for subsequent calculations. No quality check or reasonableness test is done on this measurement . . .

10. Error Detection Logic: The software design detects measurement errors, but ignores these errors unless they occur a consecutive total number of times. For example, in the airflow measuring logic, if a flow measurement is above the prescribed maximum value, it is called an error, but this error must occur 32 consecutive times for the error to be handled and displayed. This means that the error could occur 31 times, then appear within range once, then appear 31 times, etc., and never be reported.

Commented open source software expert Curtis Poe, on O’Reillynet.com: “No wonder this company didn’t want anyone to see their source code.”

Quis custodiet ipsos custodes
Let me repeat that — it’s fairly amazing: substituting “arbitrary favorable readings for the measured device.” In other words — this software is using made-up data instead of actual readings, to present a facade of reliability and cover up machine and/or code errors. The law is not looking kindly these days on ‘fudge factors’ and data fabrication: in several recent cases, scientists who randomly generated data in test results were prosecuted for fraud. This is commercial software, and it is a big market: breathalyzers are purchased by most of the estimated 10,000+ US municipal, state, and county-level law enforcement agencies. (As Boing-Boing wryly noted: “Who’s Blowing the Blowers?”)

Drunk driving is a serious criminal offense that deserves an aggressive — but accurate — law enforcement effort. I’m sure that one of the unarticulated rationales behind this trend in source code disclosure, is the increasingly high stakes of a drunk driving criminal conviction: loss of a license and possibly a job, the constitutional right to confront your accuser and have a fair trial, and a citizen’s permanent arrest record (and more and more frequently, his or her credit record) — which are subject to the internal workings of a breathalyzer machine.

Bad software has consequences.
Watch for this source code disclosure trend to expand quickly into civil law. I’m predicting that judges will finally start giving litigants the right to examine source code to determine — for example — whether contractual performance criteria are being met, or whether a software developer is in breach of contract or breach of warranty.

Will a good nondisclosure agreement keep your source code out of court?
Unfortunately for many software developers, the answer is “usually not.” The majority of professionally-drafted nondisclosure agreements contain a section (usually called “Disclaimers”) which limits the scope of the nondisclosure covenant and makes it clear that non-secret materials and materials already in the possession of the party making the covenant, can’t be restricted. It’s also a common feature of these agreements to allow for disclosure to be made in spite of the covenant not to disclose, when the disclosure is compelled by a court order, as it is in the breathalyzer cases. However — even where a nondisclosure agreement doesn’t have these exceptions, it’s possible that a court will hold that a contract provision which does not allow disclosure under court proceedings is “void against public policy” and therefore, legally unenforceable.

The trend: allowing complete source code to be turned over to parties in litigation, regardless of trade secret claims. The moral of the story: the software development industry is maturing and needs to practice risk management. While there’s no “computer malpractice” now, it’s coming. The recommendation: software architecture and coding need to be professionally risk-managed, with project management and implementation paying particular attention to the growing legal development that source code is no longer an untouchable ‘black box’ and that third parties in litigation — and contract partners — may be able to go to court and receive a copy.