Source as a safeguard

A hot topic lately in the US technology media has been the discussion of the right to access the source code forming the basis of the software included in breathalyzers. Citizens accused of drinking while intoxicated have demanded access to the source code for the device in question, the breathalyzers that present the primary evidence against them in the accusation.

The request raises some issues. On one hand, the device - the Intoxilyzer 5000EN - is employed by the police and should as such be subject to scrutiny by the public. On the other hand, the company behind it is a private entity which reserves the right to deny access to the software source on the basis of trade secrets apparent if the code is made public.

Unfortunately, the debate has been somewhat obscured by a sidetrack into an open source versus proprietary software issue. While this is understandable - and more on that later - it is not actually a question of signing over the rights to the code, but simply to allow perusal of the code to ensure that no-one receives an unjust verdict. A commenter on Ars Technica posting under the name xoa suggests that it is unacceptable that this type of device is a “Black box”, an undocumentable analysis engine, and that all such devices should be developed openly and source should be placed in the public domain for inspection.

It is hard to come to an end-all conclusion on this discussion, since it squares a company’s private property against a public demand for - and right to - insight in a technological process which has the potential to influence many lives. But the discussion is important.

Interestingly, as an aside into the open source discussion, Eric Raymond argues in his classic work on the open source development model The Cathedral and the Bazaar that it is in the interest of the company - he mentions as an example producers of graphics cards - to release the driver source code, since this partially outsources the development of the driver and makes little influence on the development cycle, since by the time the competition has been able to reverse engineer the product, the producer will have moved on the next generation of the product. While I am no expert on breathalyzers, I suspect that the breath analysis market is somewhat different from the graphics cards scenario.

But the discussion is relevant, as has also been made clear by the debate around electronic voting machines. The potential for a democratic deficit is a very real and relevant concern, and it should not be dismissed. Contrary to the breathalyzers, the customer base here is clear - and in this case, it is the right (but perhaps not immediately apparent to be in the interest?) of the consumer, the state, to be able to submit the source code for review along with the election results. This is not much different from a right to a recount of votes on paper. In this otherwise technologically advanced country, a pencil mark on a piece of paper remains the method of choice for the citizen’s submission of a vote for referendums and public elections - to avoid the black box, the mystery method, between the voters and the result.

Something similar can be said to apply to medical equipment, but this is the (mine) field of patents, secret methods and methodology, proprietary software and hardware specifications locked down to an extreme extent. Still, one might argue that the source code of the software and the hardware plans of a medical device performing diagnostics or even treatment should be subject to peer review to ascertain that safety protocols have been followed and potential hazards taken into account -  if nothing else, then post mortem in order to examine the cause of the fatality and to avoid further injury. Obviously, only a select few scientists would have the knowledge and abilities to assess this question, a highly specialized combination of medicine and informatics.

I shall finish off with a quote by a representative of the natural sciences, a mathematician to be more exact, who has taken the consequence of scientific accountability and, as the project leader of the free software application TeXmacs, Joris van der Hoeven presented the following conclusions:

As a mathematician, I am deeply convinced that only free programs are acceptable from a scientific point of view. I see two main reasons for this:

• A result computed by a “mathematical” system, whose source code is not public, can not be accepted as part of a mathematical proof.
• Just as a mathematician should be able to build theorems on top of other theorems, it should be possible to freely modify and release algorithms of mathematical software.

However, it is strange, and a shame, that the main mathematical programs which are currently being used are proprietary. The main reason for this is that mathematicians often do not consider programming as a full scientific activity. Consequently, the development of useful software is delegated to “engineers” and the resulting programs are used as black boxes.