Friday, September 7, 2007

Comprehensive List of Source Code Litigation in DUI cases

William C. Head has provided California drunk driving lawyers an array of legal weapons to use in order to attack and obtain the Source Code of California DUI Breath Test Machines. Thank you, General!

An Analysis of ‘Source Code’ Litigation in the United States: What Challenges Have Been Asserted, and Where is this Litigation Heading?

Presented at:

The International Council on

Alcohol, Drugs and Traffic Safety

August 30th, 2007 – Seattle, Washington

Presented by: William C. Head1 and Thomas E. Workman Jr.,2


The objective of this paper is to provide a primer on the breath test software which controls every evidentiary breath test machine, and to provide a summary of the challenges which have been asserted in litigation in the United States with respect to the production and analysis of breath test source code.

Every modern instrument designed to test for alcohol in the breath of a human subject is controlled by a computer, and every computer operates under the control of software. Software is represented by the source code, the set of instructions and procedures, designed to be interpreted by the computer inside the breath test machine, that implement the science as set forth in the specifications. Source code is translated into machine code using specialized computer programs called compilers, assemblers and loaders, to produce machine code that is typically delivered in a specialized memory device referred to as an EPROM.

All non-trivial software has defects. When the computer executes those portions of the software that are defective, the machine that is controlled by the software often malfunctions. Those malfunctions, or “faults”, sometimes produce failures. In breath testing machines, those failures can cause unexpected results: high BAC readings, unexplained readings, sample volume irregularities, and false reports that the defendant refused, because they failed to provide an adequate sample of their breath.

Unlike hardware components that ultimately wear out and fail, a software defect is always present, in every machine that contains the faulty software. Software failures are distinguished from hardware failures in that every machine that contains the faulty software is defective per se. Since a basic premise is that the machines are properly designed, a presumption exists that if two machines produce the same results, the results must be correct, when in fact a software defect may produce identical, but wrong, results in every machine that is used.

In the United States, criminal prosecutions under DUI law are dominated by the various states, so it is not surprising that the challenges and litigation concerning the source code for evidentiary breath test machines have varied from state to state. The greatest litigation activity seeking production of the source codes in various forensic breath instruments has occurred in Florida, New Jersey, and Arizona. Minnesota recently unveiled a very favorable ruling (for the criminal defense bar) and several Georgia cases are winding their way up to the appellate courts in that state. Brief reports about the status of litigation in the three major states are included in this paper. The authors thank Tom Hudson of Florida, Evan Levow of New Jersey, and Cliff Girard of Arizona for assisting with a summary of the litigation in their respective states for this paper.

Source Code Terminology

There exist fundamental concepts and terminology when source code is discussed in the context of evidentiary breath testing machines. The vocabulary we will use includes:

Breath Testing Machine. An electro-mechanical device, usually with a model number and a serial number, to include all of the physical items required to operate the machine (e.g. disposable mouthpiece).

Breath Testing Environment. The environmental parameters relate to the location of and the place of administration of the Breath Test. These environmental parameters include the temperature, humidity, electronic interference, electrical power abnormalities, and atmospheric characteristics of the physical space where a Breath Test is administered.

Breath Testing Process. The process is defined by the training and regulations that define how the subject is instructed and monitored, how the Breath Testing Machine is operated and verified, and how the Breath Testing Environment is monitored and verified.

All Breath Testing Machines share significant common mechanisms. They are all:

Electro-mechanical. They operate with electricity, and they have moving parts to accommodate the detection of a breath sample delivered under pressure.
Sensor dependent. They depend either on an electrical detection of a chemical reaction between a human breath and chemicals in the machine, or they employ a semiconductor device that measures the intensity of light that has passed through a breath sample.
Results only reporting. They report a minimum amount of information so that the legal issue of intoxication may be inferred, but do not log all of the intermediate calculations that would be necessary to detect a malfunction with the device.
Self calibrating. They employ a limited calibration function that will detect some component failures, for a very limited stimulus that does not remotely resemble a human breath sample.
Controlled by Software. The measurement of alcohol levels is implemented through a computer program, as is the administration of testing steps, calibration, and the generation of results reports.
The electronic control portion of a Breath Testing Machine consists of several categories:

Hardware. The power supply, display and printer circuitry, memory, electrical circuits to include the computer chip.
Firmware. Software routines stored in read-only memory (such as a ROM3, an EPROM4 or an EEPROM5).6
Software. Computer programs; instructions that make hardware work. Two main types of software are systems software (operating systems), which controls the workings of the computer, and applications. Two additional categories are network software, which enables groups of computers to communicate, and language software, which provides programmers with the tools they need to write programs.7
A closer examination of the different categories of software is necessary to focus our attention on the software that is most relevant to the task of determining whether the Breath Test Machine employed for your client produced accurate and correct results.

These categories are:

1. Systems Software. Every computer has some software that manages how the computer chip is operated, how peripheral devices like printers are operated, and which provide common and basic functionality so that applications do not have to “reinvent the wheel”. Systems software is usually purchased for a given processor design, and is usually more robust in terms of reliability as contrasted to application software.

2. Language Software. Programmers depend upon application programs to edit their software, to convert it from a human-readable language to machine language, to bind together all of the individual pieces of software into one block of code that makes up all of the software that controls the on-board computer, to manage the known problems that exist in each version, and to test the various parts of the software. These support applications tend to be reliable and well tested, but do contain defects. Knowing what particular compilers, and the versions of the compilers, were used to translate the program source into machine language is important to obtain if the breath test manufacturer is less than forthcoming (so that your expert can insure that he has all of the source code, by recreating a “build” of the machine code from all of the software source disclosed).

3. Network Software. If the model is equipped with communication hardware, such as a modem or network interface card, then the machine has the ability to interface with a computer that is operated by either your state’s laboratory, or with the manufacturer’s computers (for the purpose of updating, or possibly disabling, your application software).

4. Application Software. Customized programs provide the personality for the specific machine, and usually are written so that they only operate on a particular manufacturer’s machine, often only on a particular model of a machine. Because most states have statutes or regulations that are different, the software in a Texas machine is not identical to the software in a Florida machine, even if the brand and model numbers are the same.

The Application Software is what is most relevant to examine in order to verify the correct operation of breath testing machines. This Application Software is most likely to contain the significant defects that would cause failures of the Breath Testing Device.

When requesting the source code, one must request the source code for a specific model of the manufacturer’s machine, as it is deployed in a specific state, at a specific date in time. The source code is different depending on the serial number, and certainly it will vary as a function of time (the software is changed from time to time, usually during a maintenance cycle).

Application Software Basics

One needs to understand enough about how software operates and is constructed, and in particular the application software for their jurisdiction’s breath test machine, so that they can appreciate and communicate how a given machine operates.

Source Code Ambiguities. When Source Code is converted to Machine Code, any ambiguities are either resolved (sometimes with “Warnings”) or the Compiler that performs this translation documents “Fatal Errors” and refuses to produce the Machine Code. Unlike natural languages, like English, computer languages operate on rigid syntax rules, and unlike spoken languages, they do not permit an interpretation based on the context of a communication. With software, each program step is rigidly interpreted, according to a strict set of syntactical rules, which sometimes create unintended results.
Specialization and multiple handoffs. The programmer who writes the source code is usually not the scientist upon whose science the machine is based, and is rarely the person who designed the hardware. Rarely does one person have all of the skillsets required to design, build, and program a machine. The programmer works from a written specification, and often a “Systems Analyst” is employed to work with the author of the specification (the scientists and hardware designers) to write a detailed specification that is similar in concept to a blueprint for a building. With each handoff, opportunity for misunderstanding and mistakes in the final product, the source code, increases thereby degrading the quality of the product.
Size of the Team. As programs become larger, they tend to be managed by multiple programmers, and just as a legal pleading that is constructed by multiple attorneys has a different degree of difficulty to manage, so to does larger software have its own peculiar problems. The more people involved, the greater the opportunity for miscommunication, increased complexity, and mistakes.
Revision Management. Each unique combination of software that is released to a customer in a manufactured or upgraded machine is a “software release”. There exist accepted procedures to define what is incorporated in a release, how it is tested, and how it is managed with respect to installation in the field.
Common Errors and Code Reviews. Just as proofreaders have developed lists of common errors in written works, so too have software quality engineers compiled lists of common errors that programmers often make while writing source code. A computer scientist, preferably with a background in verifying software quality, can frequently find defects in software by “reading” the source code. In addition, source code may be reviewed automatically8 through automated review of the source code. Whether automated or performed by a team of people who read the source code listings, this process is referred to as a “code review. When a DUI-DWI defense attorney requests the source code for a Breath Testing Machine, it is with an aim to conduct a “code review” to look for defects.
Good Programmers always leave hints, or comments, in their source code. Programmers have to come back to their work months or years later, and if they are experienced, they add documentation in their source code, referred to as “comments”. These comments are ignored by the compilers that convert the source code to machine code. They provide context and logic as to why and how the source code is written. Comments often pose suspicions about problems that have been elusive and have not been specified and may not have been corrected. They may also contradict the instructions to the computer, as represented in the source code, meaning that either the comments are wrong, or the software is not correctly written.
Programmers often record information that will be helpful in resolving ongoing errors and defects. An examination of the source code will usually reveal extra steps that are not necessary to the computation of the results, but which will record information that relates to actual or potential error conditions. The mere existence of this kind of activity suggests that the programmers are trying to collect additional information in order to resolve problems they have seen, but have been unable to isolate and fix. Another alternative is that the programmers have observed suspicious performance of the equipment during quality testing.
A Defective Breath-Testing Environment means all bets are off. The computer processor in the Breath Testing Machine will not operate correctly, and the software will produce unexpected results, if the environment is not controlled within the specifications. The “environment” includes temperature, humidity, contaminants in the air, radio frequency interference, electro magnetic interference, and “dirty” electrical power supply sources. Some deviations in the environmental specifications may damage the hardware so that it can no longer properly execute the instructions set forth in the source code, thereby creating permanent malfunctions which are not corrected when the environment is restored. Lightning strikes are one example of a phenomenon that delivers an unexpected electrical power surge that damages the internal electrical circuits, and probably causes a malfunction of the software that is operating at the time of the power surge caused by the lightning strike.
How Breath-Test Software Fails

Software is written by humans, and humans are not perfect. All software, of any significance, has some density of “defects”. A defect is a condition that will result in a fault, if the state of the machine during a breath test presents conditions that cause the defect to cause an incorrect result.

Sometimes a defect will lie silent for years, waiting for some event to occur that causes the defect to cause faults. The Arizona Intoxilyzer failed on January 1, 2006 because of a defect in this category.9 Also, many machines failed to change their time by an hour when daylight savings time arrived in March of 2007, resulting in printed evidence reports that were “off” by an hour.10

Other defects may present themselves when an interferent is present, when the breath test machine’s pressure sensor detects parameters that are out of limits, or when some calculated result is deemed to be outside of accepted limits. When the state of the machine is such that a mistake in the source code is encountered, and acted on, it is referred to as a “bug” in the software, and an unexpected result, or a “fault” occurs.

Faults may create results that are incorrect, perhaps logged or communicated to the operator, or they may be “handled” by exception routines in the software that are designed to “deal with” the faults, by taking some predetermined action to block the fault11. Fault-tolerant equipment is often designed to produce correct results in spite of faults, by making alternative calculations or by ignoring unreasonable data. If the computer is aware that a fault has occurred, it is common to log that fault so that a technician can later diagnose and fix the problem.12

While some faults may create insignificant mistakes in the results that are reported, when the results are deemed to be “incorrect”, a failure has occurred. For the breath test machine, notable categories of errors are:

Whether a test was attempted. The proper design of the source code should make it impossible to “cancel” a test once it is initiated, and like citation booklets, each test should produce, record, and log a unique serial number that would facilitate the detection of tampering by those who are responsible for maintaining the integrity of the breath test process. Law enforcement should not be able to claim that no test was performed, just because they do not like the answer. In many jurisdictions, the claim by law enforcement that the subject refused to provide a sample carries the significant penalty of loss of an operator’s license, and in some jurisdictions a refusal is itself a crime that is punishable by a full year in prison13. The software should ensure that every test that is initiated is recorded and reported, the failure to do this correctly is a failure of the machine. An examination of the source code may be the only way to determine under what conditions a test can be aborted and not reported.
Whether an adequate breath sample was provided. A cooperating subject may provide a full breath sample, and the machine may improperly label it an “insufficient sample”, or the machine may provide a reading when no sample or an insufficient sample is provided.
Whether the correct portion of a breath was analyzed. The source code reveals exactly how the machine attempts to exclude portions of the breath sample which do not represent alveolar air. Failures to correctly determine which part of the breath sample should be tested, and which part should be excluded, go directly to the integrity of the measurement.
Whether interferents are correctly excluded. A human breath may contain complex hydrocarbons other than alcohol, and the manner in which the machine, and the software that may perform the calculations, excludes these compounds from the reported results is crucial. The science of accounting for many interferents requires that logical readings be subtracted in order to eliminate over-reporting. In the event that these functions are implemented in source code, and are not being properly implemented, the incorrect calculations may inadvertently add the presence of these chemicals to the calculated numerical results, producing incorrect and unintended results.
Whether results are under-reported. The software may encounter errors which cause the machine to under-report results. This would cause the breath test machine to report results that are less than the correct results for a given breath sample. These results are sometimes not disclosed to the DUI-DWI defense attorney, or when they are disclosed, traditional impaired driving charges are often brought based upon the observations of the officer and based on field sobriety tests.
Whether results are over-reported. The software may encounter situations that cause the machine to report results that inflate the results. When the inflated results exceed legal per se thresholds, the error may result in a criminal prosecution where none should be brought.
Whether the reported results are accurate enough to be legally significant. Most manufacturers report that their machines have an accuracy rating of .002 or smaller during non-human simulator testing. Yet it is common for state regulations to routinely accept two results within .02 of each other (+/-) as being acceptable to indicate an “accurate” result. The manner of calculations, how the variables that make up the calculations are captured and stored, and the techniques employed by the programmers in writing the source code may explain the inaccuracies.
Whether the wet bath or dry gas simulation cycle fairly exercises the machine so that it presents a meaningful result. Many of the software features and the hardware sensors deal with the intricacies of processing a human breath, and are not exercised by a sample of air (not carbon dioxide) that contains a uniform portion of alcohol (or a gas from a cylinder) at a known concentration. An examination of the source code would reveal what portion of the software is never validated by the current simulation scheme for calibration and diagnostics.
Why Don’t We Test for All Failures, and Fix Everything?

The short answer is that this is not possible. As can be seen below, the mathematics of the “possibilities” are almost endless.

As to testing everything, to accomplish this, one must exercise every path in the software, where a path is a sequence of instructions that are used to instruct the processor.

By way of a simple example, suppose that a 1,000 line program contains an instruction which can alter the flow of what is next (a control statement, in the computer science language) as every 20th instruction. This would result in 50 control instructions14, which in their simplest form would permit two options for each control statement.

For every control statement added, we double the number of paths possible. We express the number of paths as two raised to the nth power. For a program with 50 independent control points, the number of combinations is 250, which creates 1,125,899,906,842,620 unique paths. If we assume that we require one minute to initiate each unique combination and to check the results of each unique path through the software, then we need over 2 billion years15 for one person to complete the testing, or if we could enlist every person in the United States to work on this task, we could complete it in a little over seven years of continuous work, 24 hours a day, seven days a week.

In the software industry, it is not possible for a programmer to perform perfectly when correcting a defect. The rate at which new problems are introduced is referred to as the error re-insertion ratio or rate, and is typically between 15% and 50%. That is, if you correct a problem, the probability of introducing at least one new problem is between 15 and 50 percent16. Adding changes associated with changes in scope, or “enhancements”, often insert defects at a higher rate.17

If the source code is poorly written, or does not contain adequate comments so that a person modifying the source code has good documentation of how the program functions, or good written specifications do not exist, in sufficient detail to communicate the details of what the software must do, then the insertion rate for new problems is higher. A finite risk of making things worse exists every time the software engineers correct the software or make changes, and for any significant program, there comes a time when the program cannot be improved with maintenance, because new problems are introduced faster than they can be corrected.

Defects in the Breath Testing Process

Every Breath Testing Machine in widespread use is designed so that the biological sample is discarded after processing18, and so that all intermediate data concerning the measurements made by the machine, are also discarded. It is possible that intermediate calculations are saved by the software, for some period of time, but this capability would likely only be discovered through an examination of the source code.

The decision to discard the breath sample is a “design choice” made by the various state agencies that define how the equipment is to be deployed (some breath test machines have a discharge connection which could be used to capture the breath sample, but few states have decided to “utilize” this feature19). This design decision to discard what could be exculpatory evidence was implemented by the manufacturers of the breath testing machines, who respond to their customers. Customers of breath testing machines are “law enforcement”, and these “customers” have shown little or no interest in deploying the containers necessary collect and to preserve the breath samples.

Urine testing and blood testing result in the collection of a sample, and that sample is either retained, in whole (as in urine enzyme screens) or in part (as in retaining a portion of the drawn blood for later testing). Every form of forensic science has as a cornerstone the ability to repeat the test, given a sufficient supply of the sample (often the test requires a portion of the collected sample, and is destructive by its very nature). Breath testing stands alone in the forensic sciences, as the only forensic testing method that prohibits verification and validation by virtue of the design of the process.

Most breath testing equipment is equipped with design features that interpret the various stages of a human breath (from the air in the mouth, to shallow lung air, to deep lung air). These different treatments are implemented through the software in the various machines. Not coincidently, the wet bath simulators that “verify” the correct operation of the machines supply a stream of air with alcohol and any contaminants in a constant concentration, unlike the human breath. The use of these traditional simulators fails to exercise the critical logic employed by most machines in order to detect the different phases of the human breath. The only time that the sensors, and the use of the data recorded by the sensors, are used is during the test of a human subject’s breath.

When law enforcement observes a test which they suspect is defective, state regulations, and company policies of the manufacturers of breath testing machines, provide no mechanism for recording or reporting the error to the manufacturer. Since no data is captured which would facilitate the detection of, and the correction of, error conditions, errors in the field will continue unless and until that same error is coincidently observed by the manufacturer.

Breath Testing Machines

Fail to Provide a Reporting Mechanism for Failures

Keep in mind that the manufacturers of these machines view law enforcement as their customers, and their customers do NOT want to provide any ammunition for diligent defense attorneys to use in establishing the innocence of their clients. If the machine produces a “number” over the per se limit, then most law enforcement officials are convinced that their suspicions concerning the sobriety of a citizen must be correct, and that the citizen is guilty.

It should not be surprising that many states elect not to log anything about the breath tests.20 Those that do log, log only the final results, and not all of the intermediate values that go into computing each discrete sample of breath. The software, as represented by the source code, selects which samples are to be used in computing the reported contents of alcohol. Select the wrong “samples” and you may not have an accurate result. Make adjustments to the alcohol value in an improper way, and the results will be wrong.

The law enforcement community has agreed on some standardization concerning what information should be captured and reported. Software programs are available that collect the parameters of defined data fields from the machines within a particular state. These programs load the data to a centralized machine21. Not all states have implemented this kind of logging.

Estimating Defect Density in a Computer’s Source Code

Even without the source code, it is possible to make some statements about the density of defects in software. The defect density is a measure of the number of defective statements in a number of lines of source code. Usually the measure is stated as “Defects per Thousand Lines of Source Code”, sometimes abbreviated KLOC for thousand (“K”) Lines Of Code. Studies of defect density have confirmed that the defect density has improved as better languages and better techniques have been developed to author and examine software. On average, 25 software defects exist for every 1,000 lines of code.22

If the number of lines of code in the source code can be ascertained, the industry averages can be applied to estimate the number of defects. The estimated number of defects is calculated by multiplying the number of lines of code by 25, and dividing that product by 1,000.

The number of lines in the source code has been disclosed in testimony for the Draeger 7110 device, which has 53,774 lines of code that print out on 896 pages.23 Applying the formula that utilizes the industry average, it is reasonable to expect 1,344 defects in the software for the Draeger 7110, if it conforms to the industry norms and is “average”.

The Draeger machine is likely the most complex, and likely has the largest number of lines of source code; and the Intoxilyzer 5000 likely has the smallest number of lines of source code, based on the age of the machine and the size and number of chips dedicated to storing the programs that operate the machine.

Introduction to Source Code Litigation in the United States

Source code litigation is not a recent phenomenon. Criminal defense attorney Marjorie Tedrick of Auburn, Washington made discovery inquiries about the BAC Datamaster software in the late 1980s. The breath testing technology of that era and the accessible software and codes of the device were fairly primitive compared to the current generation of devices in use across America today. Dr. A.W. Jones, of Link√∂ping, Sweden calls today’s machines, the “seventh generation” of forensic breath testing devices.

Challenges to breath testing and calibration activities of the Arizona breath test program began in earnest in the late 1990s. Elimination (by State employees) of “adverse” machine readings on an Intoxilyzer 5000 were “covered up” in order to make the device seem to work flawlessly. The fact that important computer data was being erased with the punching of a few computer keys triggered the wave of discovery motions and production orders that lead to the State of Arizona becoming the “Paul Revere” of criminal defense attorneys specializing in challenges to computerized forensic breath analyzers.

Florida followed closely behind Arizona with many crusaders seeking to prove that “conviction by computer” was un-American. The favorable court rulings and admissions by the State of flawed computer software in the Intoxilyzer 8000 series continued until the Florida legislature passed a new law that basically purported to make the Intoxilyzer 5000 “perfect” by the stroke of Governor Bush’s pen. The audacity of lawmakers in many states (such as Florida) to try to control not merely SCIENCE, but the Constitution of the United States and of their OWN STATES is almost laughable. We say “almost” because innocent people face conviction while these states are protected unjustly from proving that their forensic tests ACTUALLY produce reliable and accurate readings.

Source Code Litigation in Arizona

Arizona currently uses the Intoxilyzer 8000 for evidential breath alcohol testing. The regulatory agency is the Arizona Department of Public Safety [DPS], having taken over by statute from the Arizona Department of Health Services [ADHS]. A close, on-going relationship exists between CMI and DPS. To begin, the only evidentiary breath alcohol testing devices approved for use in the state of Arizona are manufactured and distributed by CMI. Hence, the company has a monopoly. The Phoenix Police Crime Lab has also approved the use of the Intoxilyzer 8000, although a few Intoxilyzer 5000s are still in use by the municipality. The epicenter of our state’s source code cases has been in Phoenix.

Phoenix purchased the Intoxilyzer devices by invoice and purchase agreement with no contract provisions reserving exclusive access of the source code to CMI. Phoenix purchased the software with the instrument, and the software changes. Phoenix specified what it wanted in its software program and requested that those be developed and provided by CMI.

The first software version was 8105.40, which is the version tested by DPS and its predecessor ADHS. That version was approved for use, and then Arizona specified what it wanted in its program so that the first Intoxilyzer 8000 instruments ordered in 2003, and used in Arizona had version 8105.44, which is different from what would be used in another state. In 2004, the software was for the Intoxilyzer 8000 was changed to version 8105.45. After that, more changes were made, resulting in the issuance of version 8105.46. That is the current version of the Intoxilyzer 8000 machine “chip” commonly used in Arizona. However, there are known flaws in this programming.

Phoenix converted to version 8105.46. However, about half way through the implementation of changes via phone modem, DPS stopped the conversion. As a result, only about 50% of its Intoxilyzer 8000s are version 8105.46, the rest remain version 8105.45. Its announced reason for not completing the conversion with all of the instruments was that there were no dedicated phone lines available to connect to the modem, which is obviously not correct.

This 8105.46 version has been found to abort as “out of tolerance” if there is a calibration reading of a .110. It will also given a screen report to “proceed with another subject test” during duplicate testing if the two readings are exactly .02 apart. Such an error and default is contrary to statute and the rules and regulations of ADHS/DPS.

Testing was done on Intoxilyzer 8000 serial no. 80-001022 and it was found to produce unexpected readings during calibration, with differing results in the COBRA data bank than what was shown on the digital display. The instrument may abort intermittently at the 0.106 to 0.109 range. The software is supposed to be version 8105.46.

CMI added “beta” version of software to an Intoxilyzer 8000, device no 80-001023, that was dubbed “8105.46.01” that was so bad, the software had to be completely changed, with new software now called “8105.46.08”. The Phoenix Crime Lab had sent Intoxilyzer 8000, serial no. 1023 back to CMI to correct the .110 calibration problem. CMI kept the instrument one year, yet did not correct the problem. The factory did change the software, which added new software problems. The factory did not test it before sending it back to Phoenix and did not notify them of the new problems. That device is currently being tested by the Phoenix Crime Lab.

The length of the breath sample retention was changed in the 8105.45 version from the 8105.44 version with no state re-approval. This change did affect breath alcohol test results. This may have impacted or been impacted by the slope detector, an algorithm which is a part of the software. Basically one of the problems is that when there is a software change, the labs are dependent on CMI to tell them, and let them know if there needs to be re-certification. Otherwise, no one would know because no one really knows what is in the software change. They are dependent on CMI telling them of any problems with the software. The company has not been particularly reliable in making timely disclosure of these issues with the end users in Arizona.

Currently, one source code challenge with an Order of Suppression for non-production of the source code is pending in a lower court appeal brought by the State in State v. Mason, a Phoenix City Court case. That is scheduled to be argued September 13, 2007.

Another order for production of the source code in a Superior Court, Aggravated DUI case, State v. Krahn, which is awaiting jury trial in October. When CMI did not produce the source code the Court decided to give a Willet’s Instruction because of a recently passed State statute which says that failure to obtain the software cannot preclude introduction of the breath alcohol reading. We have challenged that statute as being unconstitutional, as a violation of separation of powers, and also as a violation of due process. The trial Court passed on that, so if convicted that issue will go up.

In a case called State v. Goodman out of Phoenix City Court, the judge suppressed 9 different readings due to CMI’s refusal to allow its technicians to be interviewed regarding RFI (radio frequency interference) problems as part of the source code litigation. That suppression order is also on appeal by the State with no court date scheduled.

State contributor Cliff Girard has recently filed the grant as submitted motion with offers of proof in State v. Kwak in Superior Court where he is waiting for CMI’s or the state attorney’s next move. It is his anticipation that if the trial court denies relief, he will file a “petition special action” to the Arizona Court of Appeals since he will have the only evidence on the record.

Finally, the defense (in Phoenix City Court on August 14, 2007) in a jury trial entitled State v. Smith, challenged the State’s/CMI’s refusal to produce the source code on an “extreme DUI” case [enhanced penalties for a high BAC reading], with two exhalations of 0.182/0.183. With no other noticeable instrument problem on the Intoxilyzer 8000 instrument, our expert [Lonnie Dworkin], an electrical/software engineer, testified about the importance of access to the source code and the impossibility of verifying the accuracy of the device in the absence of disclosure of the source code.

Mark Stoltman, a forensic scientist trained by CMI when he joined the State forensics lab, testified about the Intoxilyzer 8000 and its software configuration He stated that the jury issued three “not guilty” verdicts—on the extreme DUI, the .08 [per se DUI], and the garden-variety driving while impaired charge. This was a clean sweep!

Curtis Rau, an attorney closely associated with the undersigned state contributor in making these source code challenges, handled the technical end for the criminal defense attorney who was lead counsel in a similar successful challenge, Rob Jarvis. The State has been reeling from the inability to introduce test results in trials, resulting in acquittals. CMI’s refusal to submit to discovery in these criminal prosecutions has angered trial judges who are left with no constitutional alternative except to exclude the key evidence in the cases.

Cliff Girard, Attorney at Law

335 East Palm Lane

Phoenix, Arizona 85004

(602) 252-7160


The Status of Source Code Litigation in Florida

It is difficult to give an up-to-date summary of the status of source code litigation in Florida, for several reasons. The subject is complicated by contrary judicial rulings among Florida’s different judicial circuits. The situation is also extremely fluid. Cases are being decided every month which continuously change the legal landscape. Early cases in Florida yielded some success in obtaining orders for the production of the code. However, recent developments have been less positive.

In addition to the litigation going on in Florida courts, the courts of Kentucky have also been involved through actions filed by CMI’s attorneys seeking to quash and court order for production from another state’s tribunals. The Kentucky trial-level courts have been extremely protective of their home-state corporation, CMI, Inc., in refusing to enforce subpoenas duces tecum issued by Florida courts pursuant to the Uniform Act to Secure Witnesses. See, for example, Robbins v. CMI, Inc., unpublished opinion of the Ky. Ct. of App. 2006 WL 3524467 (December 8, 2006) where a Florida attorney’s attempt to procure the Intoxilyzer’s “source code” was fought by the manufacturer. [Unpublished opinions shall never be cited or used as authority in any other case in any court of this state. See KY ST RCP Rule 76.28(4).] From the opinion:

Accordingly, we hold that CMI’s motion to set aside and declare void the January 28, 2005, order of the Daviess District Court was improperly filed in the Daviess Circuit Court. As a motion seeking to set aside a judgment must be filed in the court that rendered the judgment, the proper procedure was to file a CR 60.02 motion in the Daviess District Court. As such, we are of the opinion that the Daviess Circuit Court committed reversible error by setting aside and declaring void the January 28, 2005, order and subpoena/subpoena duces tecum of the Daviess District Court.FN7 However, we further hold that the Florida court has no jurisdiction to directly enforce the order or subpoena/subpoena duces tecum issued by the Daviess District Court directed against Gilbert, a Kentucky resident, under the Uniform Act to Secure Witness. Such enforcement, including sanctions, may only be made through the Daviess District Court.

Florida’s implied consent statute specifies that defendants are entitled to “full information” regarding the breath or blood tests used in their prosecution. Many of the early cases granting access to the source code were based upon that “full information” clause.

In reaction to these challenges, Florida’s State Attorneys’ offices called upon conservative representatives in the state legislature to pass a law REMOVING a breath testing device’s “source code” from investigation and analysis. Effective in October, 2006, the Florida legislature amended the statute specifically to exclude manuals, schematics and software code from the “full information” requirement. (Section 316.1932(1)(a)4, Florida Statutes). Swaying pro-prosecution legislators to amend the discovery laws cannot, however, overcome or bypass the requirements of due process of law under the United States and the Florida Constitutions.

The Florida defense bar initially had mixed success in obtaining orders to produce the source code in the face of CMI, Inc.’s claims of trade secrecy. In 2005 and 2006, courts in Broward, Palm Beach and Dade Counties denied motions to compel production of the source code.

However, courts in Seminole, Manatee and Sarasota County ruled that due process required that the defense have access to the code. The Seminole County cases were reversed in June of 2006 by a Circuit Court Panel sitting as a Court of Appeals. In State v. Becvar (18th Cir. Ct, Appellate Division, Case No. 05-83 AP, decided June 28, 2006), the County Court’s order suppressing breath tests was reversed in five cases consolidated for appeal and those cases were remanded for trial. For various reasons, those cases were not appealed. The Sarasota and Manatee County rulings are on currently on appeal with little prospect of a near-term resolution.

One Court of Appeals case has been decided in Florida on the issue. Moe v. State, 944 So. 2d 1096 (Fla. 5th DCA 2006) denied access to the source code. Moe is notorious in the defense bar for its result, but also among trial judges for its utter lack of legal thought. In a page and a half opinion, the District Court of Appeals ignored the due process issues and held narrowly that the State need not provide to the defense information which it does not possess. This has left many trial court judges scratching their heads about the unanswered constitutional issues raised in that case.

The failure of the Moe court to address the due process implications of the source code controversy has had a positive impact, however. It left courts in Sarasota and Manatee Counties free to proceed in defiance of the Moe decision on due process grounds. In March, 2007, the Sarasota court (in a number of combined cases) issued a subpoenas duces tecum to CMI, Inc., ordering it to produce the source code. At present, it is unclear how the courts will sanction CMI for ignoring the order. The Sarasota Court sidestepped the issues of interstate service of the subpoena by finding that, as a foreign corporation registered to conduct business in Florida, CMI was subject to direct subpoena through its statutory agent.

CMI has moved in Kentucky to quash the Florida subpoena, but it is questionable whether the courts of Kentucky have jurisdiction to quash a Florida subpoena. In any event, the production dates for the CMI subpoenas have come and gone, and motions for sanctions against CMI are pending.

In the meantime, there are two cases, State v. Irish from Sarasota County, and State v. Almaraz from Manatee County, which are currently pending review in the Second District Court of Appeals of Florida. In these cases (which actually are consolidated cases involving approximately 60 individual defendants) the County Courts of Sarasota and Manatee Counties have ordered the state to produce the source code, and the state has taken an appeal. These cases differ from the Moe case in the following respects:

They were expressly decided on due process grounds, an issue not addressed in Moe. The Moe case also lacked evidence from several key fact and expert witnesses, including information on whether the State ever had the source code and whether CMI actually is legally entitled to claim “copyright protection” when their patent is expired and that copyrighted materials are routinely reviewed by courts under protective order.
There was testimony in the Irish and Almaraz hearings that the State of Florida had actually once possessed the source code involved, even if it no longer did now. (Moe was decided on the premise that the State did not have and had never had the code.)
The Irish and Almaraz cases also involved a lawfully served subpoena (in each case) which were both ignored by CMI, Inc.
A software bug has been significant in the Florida dispute. CMI has repeatedly claimed that so-called “black box testing” was good enough for the criminal courts. The company’s position was undercut when a software flaw was discovered which had not been turned up in the “black box testing” process. In October, 2006, CMI was forced to acknowledge that, due to faulty instructions in the source code, certain samples were being accepted by the Intoxilyzer for analysis and issuing reported breath “values” even though the computer’s minimum volume requirements were not met. This admitted error occurred only when the subject was blowing at precisely the three-minute mark after the first breath, and so might have been undiscovered for years under conventional “black box testing.” Approximately 175 cases statewide were affected by this error.

In its letter notifying State Attorneys of this bug, the Florida Department of Law Enforcement assured prosecutors:

The analytical functions of the instrument are not affected by this issue and the instrument continues to correctly analyze all breath samples. It is only with this unique and specific scenario that the breath sample has not been determined to be reliable; therefore the instrument should not report a result.

On the contrary, the scenario was obviously not unique, but affected 175 cases in the machine’s first six months of operation. However, prosecutors were assured by CMI that the instrument correctly analyzes all breath samples except for those 175 cases it did not.

The software bug was specifically mentioned by Judge Kimberly Bonner in her order in State v. Fabian, [Case No. 2006-CT-009733-NC] upholding the materiality of the source code and authorizing a subpoena duces tecum against CMI in March of 2007. On July 10, 2007, Judge Bonner issued a civil contempt order against CMI for non-production of the source code pursuant to the subpoena issued under her court order. The judge’s order cites some of the facts:

Judge Bonner held CMI in contempt August 10, 2007 and has assessed a DAILY penalty of $3200.00! That penalty begins at the end of August, 2007.

There is irony in the fact that Sarasota County is in the vanguard of source code litigation. A parallel conflict between constitutional rights and intellectual property has recently arisen in the arena of computer voting machines. Diebolt, among other manufacturers, has cited trade secrecy in fighting attempts to obtain the source code for its touch screen voting. That issue is clearly weighing on the litigation in Florida, where a disputed Congressional election recently sent Rep. Vern Buchanan to Congress despite significant questions regarding the computer voting process. That election occurred in Sarasota County.

Between the cases pending in the Second District Court of Appeals and the subpoenas duces tecum which were ignored in Sarasota County, it would appear that the next big news in Florida source code litigation will occur in Sarasota and Manatee Counties, and will occur relatively soon.

Tom Hudson

The Hudson Law Office

7780 Westmoreland Drive 422 Fleming Street

Sarasota, FL 34243 Key West, FL 33040

(941) 957-0500 (305) 292-8384


Source Code Litigation in New Jersey

After more than two years of multi-party litigation, the defense team (consisting of several DWI defense specialists and numerous clients) in State v. Chun, 191 N.J. 308, 923 A.2d 226 (2007) finally received court directive for production of the source code for the Draeger Alcotest 7110 MK III-C. The code has been partially analyzed by a software house, Base One Technologies, chosen by the defense team. A report as to the reliability of the source code is to be issued on August 28, 2007 to the Special Master advising the New Jersey Supreme Court. Defense attorneys are encouraged from the ongoing analysis that this report will demonstrate that the source code for the Alcotest is archaic, unreliable, and unscientific.

Beginning in September 2006 and running through January 2007, the Chun case was tried before the Hon. Michael Patrick King, Special Master, appointed by the New Jersey Supreme Court. The hearing lasted over 4 months, 41 trial days, 13 expert witnesses, more than 8,500 pages of transcripts, and over 240 trial exhibits. Judge King issued a 268 page report in February, and the matter was argued before the New Jersey Supreme Court in April.

Initially, Draeger declined to participate in the Chun litigation as a direct party. After Judge King issued his report, however, Draeger moved to intervene for the Supreme Court oral arguments.

During the course of the litigation, despite persistent requests by the defense for the source code, Draeger repeatedly refuse to provide the code, even after Judge King ordered Draeger to produce it. Following the oral arguments before the New Jersey Supreme Court, Draeger finally had become a direct party to the litigation. The Court compelled Draeger to actually produce the source code.

The order to provide the code to the defendants stated that the code was to be sent directly to Base One Technologies. A protective order was entered, restricting review of the actual code to Base One Technologies only. The Base One Technologies analyst was permitted to provide general information about the code to the defense team. However, he was not permitted to reveal the actual code instructions or sequences.

In the final report, if code instructions or software sequences must be revealed for illustration purposes, the language must be presented to Judge King under seal, for his review only.

Even after Draeger produced the code to Base One Technologies, Draeger resisted efforts by Base One to obtain information on how to access the code. Executable files were misnamed, causing significant delay in conducting the analytical process.

Draeger is reviewing the code separately through its chosen software house, SysTech. This company will also send their report to Judge King.

After the both reports of the litigants’ experts are submitted on August 28, 2007, the hearings will resume September 18, 2007. The defense team, the State’s attorneys, and representatives of Draeger will challenge the findings of the other parties. The hearing is expected to last at least three weeks. Judge King will then issue further findings to the New Jersey Supreme Court. The Supreme Court has the option of allowing further arguments before it issues a final opinion, or merely to decide the issue based upon what data it has received to that point.

Based on the preliminary reports, the defense team is strongly encouraged that the source code for the Alcotest MK III-C machine should be held to be unreliable. Such a ruling could mean the end of Draeger’s monopoly on state-approved breath testing devices, based on testimony that was revealed at the marathon hearing that led to this decision.

Evan M. Levow, Esq.

Practice Limited to DWI Defense

1415 Rt. 70 East, Suite 200
Cherry Hill, NJ 08034

856-428-5055 office

856-429-7726 fax


Source Code Litigation in Georgia

Presently, Georgia has no reported opinions concerning the requirement that the source code be turned over for its approved breath machines, the Intoxilyzer 5000 and 5000EN. Based on the experience of Florida and Arizona, we expect full resistance by CMI (the manufacturer) to reveal or turn over the source code.

Three state courts are currently involved in litigation that may lead to a reported appeal in the next 12 months. In the State Court of Glynn County, the issue is whether the trial judge MUST conduct an evidentiary hearing on the issue of discoverability of the source code.

An interlocutory (discretionary) appeal has been signed by the trial judge relating to this single issue. {State v. Brown}.

In the State Court of Cobb County, the trial judge has ruled that the Cobb County court cannot compel the attendance of CMI’s engineers to bring the source code to Georgia. That case will be resolved in the next 30 days, and will go up on direct appeal afterward (assuming the defendant is convicted). {State v. Abney}.

In the State Court of Gwinnett County, the trial judge conducted a hearing August 7, 2007 and verbally indicated that she was inclined to grant the defense motion for production of the source code on the Intoxilyzer 5000. A written order to that effect awaits her signature. {State v. Phillips}.

These cases are the only known appeals that are close to being decided at any appellate court in Georgia. Author William C. Head is lead counsel on all three cases. In all cases, the defense has offered to pay all the costs of the computer analysis of the software.


Source Code Litigation in Minnesota

The most recent and significant reported appeal in America when this paper was submitted is Underdahl v. Commissioner of Public Safety, ___ N.W.2d ___ (2007 WL 2127888; decided by the highest tribunal of the state [Minnesota Supreme Court] on July 26, 2007. This case dealt with Mr. Underdahl’s administrative license suspension hearing that was being litigated prior to the DWI criminal case. Because this case is so new and significant in upholding a citizen’s right to discovery of exculpatory or potentially exculpatory information, it is reproduced below in its entirety. This is the SECOND state supreme court (after the Chun decision in New Jersey) to make such a holding:

Supreme Court of Minnesota.

Dale Lee Underdahl, Respondent,
Commissioner of Public Safety, Appellant.

No. A06-1000.

July 26, 2007.

Background: Defendant, who was charge with driving while intoxicated, filed discovery motion, seeking complete computer source code for breath-testing machine currently in use in State. The District Court, Dakota County, Richard G. Spicer, J., granted motion. Commissioner of Public Safety filed petition for a writ of prohibition to prevent district court from enforcing discovery order. The Court of Appeals denied petition, and Commissioner appealed.

Holding: The Supreme Court, Page, J., held that none of circumstances justifying the issuance of writ of prohibition was present.


Syllabus by the Court

*1 The court of appeals did not err when it declined to issue a writ of prohibition to appellant.

Heard, considered, and decided by the court en banc.


PAGE, Justice.
Respondent Dale Lee Underdahl was arrested for driving while intoxicated and submitted to a breath test using the Minnesota model of the Intoxilyzer 5000EN (hereinafter, Intoxilyzer 5000EN). At his implied consent hearing, Underdahl made a discovery motion that included, among the items sought, the “complete computer source code for the [Intoxilyzer 5000EN] currently in use in the State of Minnesota.” In granting the motion, the district court ordered that appellant, the Commissioner of Public Safety, provide Underdahl with an operational Intoxilyzer 5000EN instrument and “the complete computer source code for the operation of the [Intoxilyzer 5000EN].”

In response to the district court's order, the commissioner petitioned the court of appeals for a writ of prohibition to prevent the district court from enforcing the order on the grounds that the district court “exceeded its jurisdictional authority and ordered the production of information clearly not discoverable.” The court of appeals concluded that the district court had jurisdiction over the discovery dispute and that the commissioner failed to establish that the district court improperly issued the discovery order. In re Comm'r of Pub. Safety, Underdahl v. Comm'r of Pub. Safety, --- N.W.2d ----, No. A06-1000, order at 2-3 (Minn.App. July 18, 2006) (denying writ of prohibition). For the reasons discussed below, we affirm.

Between 1983 and 1997, law enforcement officials in the State of Minnesota used the Intoxilyzer 5000 series 64 and 66 to conduct breath tests of drivers suspected of driving under the influence of alcohol. Jasper v. Comm'r of Pub. Safety, 642 N.W.2d 435, 437 (Minn.2002). In 1996, the state decided to replace the Intoxilyzer 5000 series 64 and 66 models with a new testing device and issued a request for proposal (RFP) for new breath-testing instruments. In a letter accompanying the RFP, the state explained that the RFP detailed the “relationship to be established between the State and a vendor which provides Evidentiary Breath Alcohol Test Instruments” and specifically indicated that “[t]he RFP also specifie[d] contractual conditions.” In the RFP, the state included a provision titled “ownership of copyright.” According to the parties, that provision is relevant in this case to determine whether the source code for the Intoxilyzer 5000EN is discoverable from the state. The provision reads:

All right, title, and interest in all copyrightable material which Contractor shall conceive or originate, either individually or jointly with others, and which arises out of the performance of this Contract, will be the property of the State and are by this Contract assigned to the State along with ownership of any and all copyrights in the copyrightable material[.] Contractor also agrees, upon the request of the State to execute all papers and perform all other acts necessary to assist the State to obtain and register copyrights on such materials. Where applicable, works of authorship created by Contractor for the State in performance of the Contract shall be considered “works for hire” as defined in the U.S. Copyright Act.

*2 The RFP also requires the winning contractor to agree to provide

information * * * including statement of all non-disclosure/non-reproduction agreements required to obtain information, fees and deposits required, to be used by attorneys representing individuals charged with crimes in which a test with the proposed instrument is part of the evidence. This part of the contract to be activated with an order from the court with jurisdiction of the case and include a reduced fee schedule for defendants found by the court to be entitled to a publicly funded defense.

CMI Incorporated (CMI) submitted the winning proposal. The parties do not dispute that the commissioner subsequently approved the Intoxilyzer 5000EN model developed by CMI for statewide use. See Minn. R. 7502.0420, subp. 3 (2005).

On February 18, 2006, respondent Dale Lee Underdahl was arrested for driving while intoxicated. Underdahl submitted to a breath test using the Intoxilyzer 5000EN. In an implied consent hearing in Dakota County District Court, Underdahl made a motion seeking additional discovery, including the “complete computer source code” for the Intoxilyzer 5000EN. In its May 2, 2006, order, the district court ordered the commissioner to provide Underdahl with an operational Intoxilyzer 5000EN instrument, “together with all necessary peripherals, including, but not limited to, a supply of simulator solution, the simulator apparatus, internal modem, printer, and supply of mouth pieces.” The court also ordered that the commissioner “obtain and provide to [Underdahl's] counsel the complete computer source code for the operation of the Minnesota model of the Intoxilyzer 5000 currently in use in the State of Minnesota.” The order was based on the district court's conclusion that the state owned the source code for the Intoxilyzer 5000EN model created exclusively for the state. In support of that conclusion, the court cited the “ownership of copyright” provision in the RFP. In reaching that conclusion, the court also stated that it could see no reason “why drivers tested using that instrument should not have full access to all of the information employed by that instrument.”

The commissioner subsequently petitioned the court of appeals for a writ of prohibition to prevent the district court from enforcing its discovery order. The commissioner essentially argued that the court of appeals should issue the writ of prohibition because Minn.Stat. § 634.16 (2006), which sets forth a presumption of reliability whereby the results of an infrared breath test are “admissible in evidence without antecedent expert testimony,” divests the district court of jurisdiction to order the additional discovery. In the alternative, the commissioner argued that if the court had jurisdiction, it abused its discretion by ordering discovery of source code that the commissioner claimed was not in its possession, custody, or control and was, therefore, nondiscoverable. The commissioner also argued that due process did not require discovery of the source code because the code was proprietary to CMI and thus unavailable to the state. Underdahl argued that the district court had jurisdiction over his challenge to the reliability of his test results and that the court did not abuse its discretion in ordering the additional discovery.

*3 The court of appeals denied the commissioner's petition, concluding first that the district court had jurisdiction to respond to Underdahl's challenge to the reliability of his test result. In re Comm'r of Pub. Safety, Underdahl v. Comm'r of Pub. Safety, No. A06-1000, at 3. In reaching this conclusion, the court explained that “respondent is raising challenges to his particular test results, which he may do pursuant to Minn.Stat. § 169A.53, subd. 3(b) (2004). These challenges are to be raised in the district court pursuant to Minn.Stat. § 169A.53, subd. 2 (2004).” Id. at 2. Based on the district court's finding that the source code was not proprietary, the court of appeals went on to conclude that the district court did not err in ordering discovery of the source code created specifically for the Minnesota model of the Intoxilyzer. Id. at 3. In support of this conclusion, the court noted that the commissioner acknowledged that the state owned some portion of the source code. Id.

[1] [2] A writ of prohibition is an extraordinary remedy and is only used in extraordinary cases. Thermorama, Inc. v. Shiller, 271 Minn. 79, 83-84, 135 N.W.2d 43, 46 (1965). We will issue a writ of prohibition only when one of the following four circumstances applies:

it appears that the court is about to exceed its jurisdiction or where it appears the action of the court relates to a matter that is decisive of the case; where the court has ordered the production of information clearly not discoverable and there is no adequate remedy at law; or in rare instances where it will settle a rule of practice affecting all litigants.

Id. at 84; 135 N.W.2d at 46. The writ sought by the commissioner does not meet this test.

[3] First, we consider whether “it appears that the court is about to exceed its jurisdiction.” Id. “Jurisdiction is a question of law that we review de novo.” Kellar v. Von Holtum, 605 N.W.2d 696, 700 (Minn.2000), superseded on other grounds by Minn. R. Civ. P. 11.03. The commissioner argues, as he did in the court of appeals, that because section 634.16 establishes that an approved breath-testing instrument is presumed reliable, the only way to challenge the reliability of the instrument is to challenge the administrative rule that approved the instrument for statewide use. The commissioner then asserts that, because Minn.Stat. § 14.44 (2006) gives the court of appeals exclusive subject matter jurisdiction over challenges to administrative rules, the district court lacked jurisdiction to order discovery of the source code.

Minnesota Statutes § 634.16 provides that:

In any civil or criminal hearing or trial, the results of a breath test, when performed by a person who has been fully trained in the use of an infrared or other approved breath-testing instrument * * *, pursuant to training given or approved by the commissioner of public safety or the commissioner's acting agent, are admissible in evidence without antecedent expert testimony that an infrared or other approved breath-testing instrument provides a trustworthy and reliable measure of the alcohol in the breath.

*4 (Emphasis added.) Minnesota Rule 7502.0420, subp. 3, is the rule approving the Intoxilyzer 5000EN for use throughout Minnesota. The commissioner reads the presumption of trustworthiness set forth in section 634.16 as taking away the district court's jurisdiction over challenges to the reliability of individual breath tests performed using the Intoxilyzer 5000EN. This reading is premised on the commissioner's conclusion that, once the department formally approves a breath-testing device, “[the device] is by definition deemed to be reliable under the statute.” Therefore, the commissioner contends that the only way to challenge the reliability of such tests is to challenge Rule 7502.0420 in the court of appeals under Minn.Stat. § 14.44, which provides that the

validity of any rule may be determined upon the petition for a declaratory judgment thereon, addressed to the Court of Appeals, when it appears that the rule, or its threatened application, interferes with or impairs, or threatens to interfere with or impair the legal rights or privileges of the petitioner.

(Emphasis added.)

Underdahl asserts that he is challenging his specific test results under Minn.Stat. § 169A.53, subd. 3(b) (2006), not the validity of Rule 7502.0240. Citing to Minn.Stat. § 169A.53, subds. 2 and 3 (2006), Underdahl argues that section 169A.53 specifically provides him with the right to challenge the validity of his test results in the district court. Section 169A.53, subdivision 2, provides that after a driver receives notice and order of the revocation of his or her license for driving under the influence of alcohol, the driver may seek judicial review of the revocation in the district court in the county where the alleged offense occurred. Section 169A.53, subdivision 3, limits the scope of that judicial review to ten specific issues. Subdivision 3(b)(10), which reads, “Was the testing method used valid and reliable and were the test results accurately evaluated?,” permits the driver to challenge the validity of his or her test results.

[4] The commissioner's argument that Underdahl may only challenge the reliability of his test results by challenging the rule approving the Intoxilyzer 5000EN for statewide use relies on an overly expansive reading of section 634.16. Under section 634.16, the results of a breath test conducted with an approved testing instrument are admissible and presumed trustworthy and reliable “without antecedent expert testimony.” But section 634.16's presumption of reliability may be challenged in a proceeding under section 169A.53, subdivision 3(b)(10), which specifically permits a driver to challenge the reliability and accuracy of his or her test results. Because Minn.Stat. § 169A.53, subd. 2, gives the district courts jurisdiction of section 169A.53, subdivision 3(b)(10), proceedings, the commissioner's argument that the district court lacks jurisdiction in this case necessarily fails.

[5] Second, in order to determine if a writ of prohibition may issue, we consider whether the order at issue relates to a matter that is decisive of the case. Thermorama, 271 Minn. at 84, 135 N.W.2d at 46. Here, we conclude that it does not. The district court's discovery order addresses whether the source code for the Intoxilyzer 5000EN is discoverable. The issue to be addressed in the underlying implied consent hearing is whether Underdahl's test results are valid. Resolution of the pretrial discovery issue, however resolved, will not be dispositive of the underlying issue. It is enough to note that this is a pretrial matter seeking discovery of information that may or may not be admissible at trial.

*5 [6] [7] [8] Third, we consider whether the district court's order mandated discovery of information that is clearly not discoverable and for which there is no adequate remedy at law. Thermorama, 271 Minn. at 84, 135 N.W.2d at 46. “[A] trial judge has wide discretion to issue discovery orders and, absent clear abuse of that discretion, normally its order with respect thereto will not be disturbed.” Shetka v. Kueppers, 454 N.W.2d 916, 921 (Minn.1990). We review a district court's order for an abuse of discretion by determining whether the district court made findings unsupported by the evidence or by improperly applying the law. See, e.g., Frauenshuh v. Giese, 599 N.W.2d 153, 156 (Minn.1999), superseded in part on other grounds by Act of Apr. 27, 2000, ch. 444, art. 1, § 5, 2000 Minn. Laws. 980-984 (codified at Minn.Stat. § 518.18(d)(i) (2006)). “[D]iscovery rules are remedial and must be construed liberally.” Anderson v. Florence, 288 Minn. 351, 361, 181 N.W.2d 873, 879 (1970). This is so because of the philosophy underlying our discovery rules that “ ‘a lawsuit should be an intensive search for the truth, not a game to be determined in outcome by consideration of tactics and surprise.’ ” Id. at 356, 181 N.W.2d at 876 (quoting David W. Louisell, Discovery and Pre-Trial Under the Minnesota Rules, 36 Minn. L.Rev. 633, 639 (1951-52)).

[9] Minnesota Rule of Civil Procedure 26.02(a) provides that “[p]arties may obtain discovery regarding any matter, not privileged, that is relevant to a claim or defense of any party.” Rule 26.02(a) further provides that the information sought need not be admissible at trial so long as the information sought is “reasonably calculated to lead to the discovery of admissible evidence.” Minnesota Rule of Civil Procedure 34.01 provides that a party may serve a request for production of documents and tangible things “which constitute or contain matters within the scope of Rule 26.02 and which are in the possession, custody or control of the party upon whom the request is served.” (Emphasis added.) The party objecting to the production of information has the burden of establishing that the sought-after information is immune from discovery. Brown v. St. Paul City Ry. Co., 241 Minn. 15, 35-36, 62 N.W.2d 688, 701-02 (1954).

[10] The district court ordered the production of the “complete computer source code” for the Intoxilyzer 5000EN. In support of its order, the district court found that under the contract between the state and CMI, the state owned the source code for the Intoxilyzer 5000EN. The court of appeals concluded that the district court's finding was not clearly erroneous given the concession in the state's petition seeking the writ of prohibition that it owned that portion of the source code created exclusively for the Intoxilyzer 5000EN.

The commissioner does not specifically argue that the source code for the Intoxilyzer 5000EN is not discoverable under Rule 26.02; rather, the commissioner argues that the source code is not discoverable under Rule 34.01 because the source code is not within the commissioner's possession, custody, or control. The commissioner argues that ownership of the source code is determined according to the definition of derivative works under 17 U.S.C.A. § 101 (Thomson/West 2005). The commissioner argues that under federal copyright law, the state owns only a portion of the source code used in the Intoxilyzer 5000EN and, therefore, cannot comply with the district court's order to produce the complete source code. Underdahl responds by arguing that the “complete computer source code for the operation of the [Intoxilyzer 5000EN]” is a work for hire pursuant to 17 U.S.C.A. § 101, and that, as such, the district court did not abuse its discretion when it issued its discovery order.

*6 Having carefully reviewed the record presented and the arguments of the parties, we conclude that we cannot decide the copyright issues raised. Although the parties direct us to copyright law regarding works for hire and derivative works, they provide only a superficial application of that law to the facts of this case. Perhaps that is because the factual record before us is inadequate, thereby making any determination regarding either copyright theory impossible.

[11] Resolution of this issue, however, does not require us to apply federal copyright law because we also conclude that the commissioner has failed to meet his burden of demonstrating that the information sought is clearly not discoverable and that he has no adequate remedy at law. While on the one hand the commissioner argues that ownership of the source code for the Intoxilyzer 5000EN is to be determined under federal copyright law and that under that law he does not have possession, custody, or control of the source code, on the other hand he concedes that the state owns and thus controls some portion of the source code. That concession is supported by the express language of the RFP granting CMI the right to supply the Intoxilyzer 5000EN to the state. Further, given the express language of the RFP that requires CMI to provide the state with “information * * * to be used by attorneys representing individuals charged with crimes in which a test with the [Intoxilyzer 5000EN] is part of the evidence” when production of the information is mandated by court order “from the court with jurisdiction of the case,” it is not clear to us that the commissioner is unable to comply with the district court's order. Accordingly, we cannot conclude that the district court ordered the production of information that is clearly not discoverable.

We conclude that the commissioner failed to demonstrate that he has no adequate remedy at law. The commissioner concedes that he could sue CMI to “force it to turn over ‘the complete computer source code.’ ” However, the commissioner asserts that a lawsuit compelling CMI to turn over the source code does not constitute an adequate legal remedy because the commissioner does not believe he is entitled to the source code and thus a lawsuit seeking it would be frivolous, therefore exposing the commissioner to sanctions. The commissioner asserts that the only other remedy would be to appeal a final order, which he asserts is inadequate because it would not address the “statewide concerns” at issue in this case. We do not agree that the commissioner lacks adequate remedies at law. As discussed above, irrespective of whether the state owns any portion of the source code, CMI agreed, in the RFP, to provide the attorneys representing individuals charged with crimes “in which a test with the [Intoxilyzer 5000EN] is part of the evidence” information necessary to comply with a court's order. We conclude that the commissioner's ability to enforce its contract with CMI constitutes an adequate legal remedy. FN1

*7 [12] We turn finally to whether the issue in the case relates to a rule of practice affecting all litigants. Thermorama, 271 Minn. at 84, 135 N.W.2d at 46. It is enough to say that this case does not raise any issue relating to a rule of practice affecting all litigants.

Thus, none of the four circumstances justifying the issuance of a writ of prohibition under Thermorama, 271 Minn. at 84, 135 N.W.2d at 46, are present in this case. We, therefore, hold that the court of appeals properly denied the commissioner's petition for a writ of prohibition.


FN1. This example is not intended to convey that the commissioner has only one adequate legal remedy.


The source code is the enabling technology for all breath test machines in use in the United States. Every machine running the same software, as delivered in semiconductor EPROMs by the manufacturer, will faithfully execute any defective software in the same way on every machine in which the software is deployed.

Source Code for Breath Test Instruments is different from the source code that enables radar detectors or other commodity instruments, because the source code is different in each of the 50 states for a given instrument, driven by differences in regulations and law in each jurisdiction.

Production of the Source Code has been litigated in states across the United States, with varying results. The trend towards “per se” violations has made the analysis of how the machine operates, and what defects may exist, crucial to the administration of justice.

Of special interest is the difference in attitude of the various manufacturers concerning disclosure of “source code” information. For example, National Patent, which owns and manufactures the BAC Datamaster series of forensic devices has willingly offered to provide their source code, so long as protected by court order. Hence, no litigated cases exist for this device.

On the other hand, CMI’s abject refusal to turn over the “source code” of either the Intoxilyzer 5000 or the Intoxilyzer 8000 is now a thing of criminal defense lore. One must ask the question, “With such resistance to disclosure, what has CMI to HIDE from disclosure?” After all, in Georgia, the offer was made by the defense to pay 100% of the costs of analysis of the software and source code commands that tell the Intoxilyzer how to run its various “routines” in obtaining a sample.

1 William C. Head is Senior Partner in Head, Thomas, Webb & Willis, LLC, an Atlanta, GA law firm that handles over 600 DUI cases annually. In 1996, Mr. Head attended a 40-hour course for the Intoxilyzer 5000 and has owned several of the early models of this device. He has participated in three other courses relating to Intoxilyzer training, the latest being held in 2004. He currently owns an “EN” model of this device. He has also attended a factory training course for the BAC Datamaster series of breath testing devices. Mr. Head is a member of and attended the Robert Borkenstein Institute in 2000, and in 1999 was named National Chairman of a Safety Committee supervised by NHTSA that focused on the “aggressive driving” problem in America. Mr. Head is also an Instructor in the Standardized Field Sobriety Tests, and has assisted in training over 300 students who have taken the “practitioner” course. One of the 12 original “founders” of The National College for DUI Defense, Inc., Mr. Head is now a retired Regent from that organization. He has handled over 4000 DUI cases personally, and has taken nearly 1500 to trial in his 31 year career. His e-mail is: His main web site,, is ranked in the top 10 websites for criminal defense attorneys by

2 Thomas E. Workman Jr. is an attorney with a criminal defense practice in Taunton, Massachusetts. He has a BS and an MS in electrical engineering from the University of Texas at Austin (1970 and 1974) and a JD from Suffolk Law School with a concentration in High Technology Law (1997). He is also admitted to practice before the U.S. Patent Office and the First Circuit. He operates a computer forensic consulting business, with a website at: He can be reached in his office at 41 Harrison Street, Taunton, Mass 02780, by phone at (508) 822-7777, or email at He has testified in Federal and State Courts on computer forensic issues relating to criminal matters, including first degree murder trials, and has testified on source code issues relating to the Intoxilyzer 5000.

3 A ROM is a Read Only Memory, a circuit that is custom designed and cannot ever be changed without a re-design of the semiconductor device. These are the least expensive to manufacture, but have a high initial setup design cost.

4 An EPROM is an “Electrically Programmable Read Only Memory”, and the contents can be erased by exposing the device to an ultraviolet light for a short duration of several minutes, and then the blank device can be loaded with any data using a programming device, a piece of equipment that is used to load machine language instructions onto the EPROM.

5 An EEPROM is an “Electronically Erasable Programmable Read Only Memory”, and is distinguished from an EPROM in that the circuit can be erased with an electronic signal. A machine with an EEPROM in it could be changed by the manufacturer, if they had remote access to the machine over a network, and if the equipment was designed to permit a remote user to change the device. Traditional computer users perform this step when they “flash the BIOS” of their computer or of a peripheral device.

6 Microsoft Press Computer Dictionary, Third Edition, page 197.

7 Microsoft Press Computer Dictionary, Third Edition, page 441.

8 One listing of such resources can be found at:

9 CMI made changes to the Arizona machine so that an age limitation of over 100 years was not allowed. The accomplished this by processing the two digit year, and on January 1, 2006, the machine would not process any samples, because every sample appeared to be of a person who was older than 100 years old. The source code was defective in its implementation, and the defect never presented itself until January 1, 2006, at which time every Arizona machine malfunctioned for every sample.

10 In New Jersey, police officers were instructed to wait an additional hour before making their 20 minute observation, so that the time printed would always appear to be after the time of arrest. Some attorneys mused that during a leap year, defendants might have to wait a whole extra day.

11 Most computer systems will interrupt the flow of the software when known error conditions are detected, e.g. dividing by zero or attempting to access a memory location that does not exist. These error situations can be dealt with by ignoring the error, or by taking some predetermined action. By definition, there is no way to present a “correct” result. These errors indicate that the results from this execution of the software are invalid, yet many systems will deliver some answer “in spite of” knowing that the calculations are defective per se.

12 Automobiles and copy machines routinely log error codes, those cryptic letters and numbers that direct the repair person to the correct area of the machine for repairs. Some intelligent copy machines will even dial the repair technician and communicate the logged error codes, so that the technician can show up with the correct parts and tools to effect repairs.

13 For a second refusal, the state of Florida can incarcerate a citizen for up to a year, a draconian penalty if the citizen actually did provide an adequate sample, and the machine incorrectly reported that the citizen had not. FSA sec 316.1939.

14 If every 20th instruction is a control statement, and there are 1,000 statements total, then there are 1,000 divided by 20 control statements, or 50 control statements.

15 The number is computed by dividing 250 by 60 to compute the number of hours; divide that by 24 to get days; divide that by 365 to get years – the result is 2,142,123,110 years.

16 Adams, Edward N., “Optimizing Preventing Service of Software Products:, IBM Journal of Research and Development, Vol 28, No 1, pp 2-14, January 1984

17 One study reported that 0.628 defects were introduced for each change and enhancement made. Kan, Stephen H, Metrics and Models in Software Quality Engineering, Addison-Wesley Publishing, Reading, Massachusetts, 1995.

18 The manufacturers at best provide a plumbing connection through which the breath sample is discharged from the machine, and modifications to discharge a sample of the last air in the chamber through a custom discharge port. No facility to trap the sample is provided internal to the machine, nor are supplies and training provided by the manufacturers. Any solution is left to the “after market” suppliers of accessories for the various machines.

19 New Hampshire and Colorado have used the ToxTrap, a facility that captures a sample of the air that is present at the conclusion of a breath test. Oklahoma and Arizona have case law that refers to the ToxTrap, though the author believes that only New Hampshire and Colorado require the preservation of a sample using the ToxTrap silica gel breath capture product.

20 There are notable exceptions. At least Florida and South Carolina are believed to make available on the Internet data captured with every breath test administered, with the results available for statistical analysis.

21 CMI sells a program called COBRA which systematically contacts each machine within the jurisdiction, over a modem, and uploads the values stored concerning recent breath tests administered.

22 The Science of Debugging, Telles and Hseih, Coriolis Technology Press, 2001, page 57

23 Direct examination, under oath, of STEPHEN B. SEIDMAN, page 6, lines 4-6 of volume 16T, Supreme Court of New Jersey, docket 58,879, New Jersey v. Jane H. Chun et al., October 3, 2006 Hearing.

California DUI Attorneys can use this information to get the source code for California DUI breath test machines.