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.
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.
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
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.