Slashdot Mirror
Florida DUI Law and Open Source
pete314 writes "A Florida court this Friday will hear arguments in a case where the accuracy of a breathalyzer is being scrutinized because the manufacturer refuses to release the source code. A state court ruling last year said that accused drunk drivers are entitled to receive details about the inner workings of the "mystical machine" that determined their guilt, and defense attorneys are now using that ruling to open up the device's source code.Is this part of a larger trend? With software bugs being a fact of life, consumers and organizations could claim that they need to be able to verify an application's source code before they accept that their calculations are accurate. Think credit card transactions, speed detecting radar guns, electronic voting machines..." Here is our previous story when this first became an issue in Florida.
If, ideally, the government exists soley for it's citizens. Would it be in our best interest to be able to view the source code of non classified projects? If the government is in fact using our tax dollars to pay programmers, should we be entitled to view the outcome of their work and does it become public domain if paid for by public funds?
2. So is this kind of ruling going to spread to radar detectors, baggage-scanning equipment, automated video cameras, etc?
I'm all for Free Software too.. and I also dont think the drunk driver should be let off the hook. That's why the source code has to be released.. Its not as if it was complex software.. and I mean.. they are selling a machine. Its not like asking Microsoft to Free Windows .. it wont kill the company.. But will probably guarantee a fair trial.. And it creates a good precedent for voting machines, etc.
The larger problem here is that a lot of these tools (breathalyzers, RADAR and LIDAR guns, etc) are dealing with ambiguous data in the first place. For example, the algorithm used to determine BAC in a breathalyzer may be implemented correctly, but what if the algorithm itself is wrong? You're dealing with many variables (a person's mass, their metabolism, etc), and those variables have different values for different people. It's well-known, for example, that women will blow higher on a breathalyzer than a man simply because they're generally smaller.
Similarly for LIDAR (laser speed detection), the underlying principle is using distance and time to determine rate. Sounds straightforward, as d = r * t, but how do you know you've got the right values for d? It's been shown that rapid movement of a LIDAR gun can cause even inanimate objects to register a rate. How do we know the LIDAR gun measured the distance your car traveled over a period of time, rather than the distance of your car at one point in time and the distance of some other reflective object (say, a much closer stop sign) at a different point in time? At the distances in question, we're talking sharpshooter skills as a requirement for using a LIDAR gun, but it seems that every cop on the force has one. Can they expect us to believe that every cop is a sharpshooter, or that several cups of coffee won't induce shaking in the cop's hands that could cause false readings?
It's a good precedent, forcing the breathalyzer source to be opened to inspection, but the assumption is still that the underlying algorithm is accurate when it's not. I don't understand why courts continue to rely on technology such as the breathalyzer or the LIDAR gun when there are better, proven tests that could be used instead (blood tests, RADAR or pacing with a calibrated speedometer). Worse, once a court has chosen to allow such evidence (this is not arbitrary, but once the admissability of such a test is challenged and lost it's almost impossible to re-challenge), you can no longer argue that the underlying tool is bad (without extenuating circumstances that would bring the acceptability of such tools back into question). You can argue that the machine wasn't properly calibrated or maintained or that the officer using it was untrained or unqualified or out of practice, but you can't argue that the tool itself is inadmissable as evidence even if the facts are on your side.
... friends don't let friends code drunk.
If the software is complex enough to require "numerous software upgrades", then it is complex enough to have bugs. And it seems to me that not all bugs would necessarily show up under testing.
You go to a bar. Someone buys you ten beers. So your intoxication was free as in beer. Then you get pulled over and get a breathalyzer test which gets thrown out of court because the software was not free as in speech. So then you walk out of court, free as in Willy!
One of the easiest ways to get a speeding ticket overturned/dropped (at least in the UK) is to request all of the calibration reports for the particular camera/radar gun used to take your speed.
If the reports cannot be produced or are older/outside the statutory testing period, then the data produced by the machine will not hold up in court, and so the case will be dropped.
In some cases, the police simply cannot be bothered/do not have the time to do all of the necessary paperwork, and so the case may just be forgotten/ignored.
I don't know if this could be applied to a breathalyser, but it would be an interesting to see what would happen...
[All Your Fish Are Belong To Us]
I pulled jury duty earlier this year and was placed on a DUI trial. I can tell you that breatholizers are complete bullshit. In Texas if you are pulled over refuse to take the test and offer to have a blood sample instead. They will threaten to take your license away if you say no but it's an administrative process and you can still get exemptions and keep driving.
I learned alot more about DUI law during that trial and while I never personally drink and drive I could see very easily how one could be falsely suspected and convicted.
So how did the jury decide? We didn't there was a mistrail because the "sleezy lawyer" ( the prosecutor in this case ) asked the cop a question about the administration of a PBT ( portable breath test ). These are not admissible in TX court and the judge had already said it wasn't allowed in. The judge felt that we wouldn't ignore the fact that we had heard the cops answer and declared a mistrial. He said he felt the prosecutor made a "mistake" but I don't believe it. I think she knew the trial wasn't going her way and wanted a way out.
It kinda sucked actually.... it was like reading a novel and not getting to read the end of the book.
Even if the brethalyzer's accuracy had been tested, so what?
Think about easter eggs and date bugs: How do you know the software works correctly on leap year day? On Sundays? On the 295th test? If the cop enters "124341+" on the keypad just before running the test?
You don't.
The output of a machine is NEVER evidence in a trial. What is evidence is the expert testimony of a human - hired by the prosecution - that the output is correct. (This has an incentive structure that encourages both fraud and rose-colored-viewing on the expert's part.)
To mount a defense the accused needs to be able to hire his OWN expert and let HIM examine the machine and identify any ways it could have made a false indication. Then you get a conviction if, and only if, the prosecution's expert is able to show that none of those occurred, so the reading is accurate.
For the defense expert to be able to do his job on a software-using system he needs access to the source. If the prosecution is able to deny him that, he has been denied - by his opponent - his due process right to challenge the evidence against him. So the evidence MUST be thrown out if he is to have a fair trial. IM(NAL)HO that's cut and dried.
Imagine if the machine was a witness. The prosecution gets to question the witness. The defense does not get to cross-examine him. See where that would lead?
How about a program that allegedly (according to a prosecution's expert witness) examines evidence and says "he's guilty" or "he's innocent"? Without a defense expert examining the code how do you know it's not:
g = "innocent"
repeat until eof
if input line == "officer O'Malley saw a rabbit"
g = "guilty"
print "he's " g
So it's:
1) open the software generally,
2) open the software to a long string of (expensive) defense expert witnesses,
3) not use the software's output if challenged, or
4) deny due process.
If they try to settle on 2) it's easy to argue that not going to 1) denys due process to the poor, since they can't take advantage of the expensive experts.
Result: No closed-software devices can be used by the procecution if challenged (unless the courts decide to deny due process).
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
This has nothing to do with the accuracy of the breathalyzer and everything to do with the sleazy practices of DUI defense attorneys.
An attorney is the last defense between a defendant and The Government, which can, at the point of a gun, take away one's money, freedom or even life. It should be plainly obvious that The Government is much more powerful than the individual, and so it is vitally important that the individual be allowed a representative who will point out when The Government doesn't have an i dotted or a t crossed. Having a defense attorney that gets his client off on "a technicality" is the best way to insure that the government will do ITS job properly, fairly and fully, rather than putting someone in prison unjustly.
Let me assure you I'm not happy with drunk drivers or any lawbreaker getting off, but it would be much worse for an innocent person to be found guilty.
I once inherited a "simple" project, a pressure transducer with microcontroller that gave readings to a 'main' computer in decimal. While testing it I noticed that readings were sometimes way off. There was a bug in the binary to decimal conversion routine that causes about a 10 percent error in 1 out of about every 50 values (I recall it was an odd little table lookup thing).
So these days it DOES happen, and with bugs in "simple" devices perhaps moreso than ever, a "simple device" CAN be very wrong, and in this case it could cause the defendant a large fine, loss of license or even a jail term even though he may have actually below the legal limit.
You may argue that the legal limit for DUI alcohol tests is too high and should be lowered (further than has been done in recent decades), and there's probably a good argument for that (based on the punishment and very low drunk driving rates in some European contries), but again, this is a different matter than properly enforcing the current law.
Tag lost or not installed.
I've never forgotten that lesson. If I know what algorithms are, and how they work, and what a particular language can (and can't) do, I can certify a project, based on the look on the programmer's eye when they answer The Questions.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Because the accuracy of the machine can only be demonstrated with the test data that is available. While this should be very close to reality, we have no way of verifying that the test data chosen is relevant to the case of the person on trial. With the source code, we can verify the implementation, and make sure that that implementation will accurately reflect on the defendant.
Put another way: This software is only slightly less critical than the software which is used in the space program. There, people die. In this case, lives can be destroyed by a wrongful conviction. At least if you die, your problems are over and done with. Now, what if a particular test case was missed? How would you know? Even worse, what if THAT test case shows that one in every 10 readings will be wildly inaccurate? Without the source code, what chance do you have of proving this?
GPL made simple: What was my stuff is now our stuff. If you improve our stuff, please keep it our stuff.
I've built medical devices before. This is in essence a medical device. If this were being used in a medical laboratory for medical purposes, source code changes which were not properly recertified would void the FDA approval for the device. There's a reason for that.
It's a truism in software that you can't verify the absence of bugs by black-box testing, no matter how complete the test vectors. This is doubly true when the software is interacting with the real world, in a nontrivial manner.
Consider: The device undoubtedly measures a change in itself that occurs in response to the presence of ethanol. A voltage is produced, a current is seen, or a color change occurs in some sensitized material. Some chemical reaction occurs, and produces a detectable change in the device state. But because chemical reactions are susceptible to variation in temperature, in the age of the reagents, in the particular lot of the reagents, and in subtle machine-to-machine differences between reaction sites, the software for the machine must contain built-in adjustments for all of this. If you have a half-dozen linear adjustments that you have to make (not uncommon, in laboratory equipment), the six-dimensional test vectors that you have to check are massive. If you have a dozen such factors, you literally can't test enough combinations to be sure that every combination works. And even worse, you have to verify that the machine is in a known state at the beginning of such a test, and without access to the source you have no way of knowing.
The question isn't whether the machine can be made to work in a laboratory setting. The question is whether the machine worked this time, in the middle of the night, in an un-airconditioned drunk tank in God-knows-where, as the thirty-fifth breath test that night. If you don't have the source code, you literally can't possibly know what the chances are that it really worked.
As much as I hate drunk drivers, and as much as I think that the machines are probably pretty good, I'm with the defense attorneys here: produce the source, or stop pretending that this machine can produce proof beyond reasonable doubt.