[SystemSafety] Post Office Horizon System

[Steve Tockey]

PBL wrote:

“One possible outcome of the Horizon case is that the notion of strict liability for software is being given a serious airing. The liability is not at the level of individuals but at the level of the developing organisation.”

Of course I am no expert in law, but my understanding is that here in the USA by default the corporation assumes liability. I think it’s called the “Industrial Exemption”. On the other hand, and this was my maybe-too-subtle point earlier, NSPE and the state licensing boards are supposed to be watchdogs that require licensed (I.e., chartered) engineers to “seal” work products on ALL projects that put the health, safety, and welfare of the general public at risk. In “sealing” those work products, that licensed engineer is taking on personal liability. Large amounts of software are clearly putting the health, safety, and welfare of the general public at significant risk and yet NSPE and the state licensing boards are (or, at least appear to be) at best moving on geologic time scales.

At least 10 of US states do offer a professional licensing route for Software Engineering, but it is not required for work on what should easily be considered critical projects:

Alabama
Delaware
Florida
New Mexico
New York
Michigan
Missouri
North Carolina
Texas
Virginia


“Requirements specification is an unsolved engineering problem, and is likely to remain so for quite a while (if not for ever).”

I would disagree, personally. Software requirements can be specified precisely, concisely, etc.


”Software systems are often used outside of formal requirements. . . . Suppose someone uses that product outside those formally over-strict requirements. Developer points the finger at user, and, with a good legal department, wins in court.”

This is not a problem that’s at all unique to software. Ridiculous product warning labels abound:

“Not for internal consumption” on a wire coat hanger.
“Do not use while sleeping” on a hair dryer.
“Do not put any person in this washer” on a clothes washing machine.
“This product is not intended for use as a dental drill” on a Dremel electric tool.
“Do not hold the wrong end of this chainsaw”.
“The Vanishing Fabric Marker should not be used as a writing instrument for signing checks or any legal documents.”

And so on.


“I agree with your examples, of course, especially the one in which you quote me back at myself :-)”

I knew you would—smile.


— steve



-----Original Message-----
From: Peter Bernard Ladkin <ladkin at causalis.com<mailto:ladkin at causalis.com>>
Organization: RVS Bielefeld and Causalis
Date: Monday, April 26, 2021 at 12:04 PM
To: Steve Tockey <Steve.Tockey at construx.com<mailto:Steve.Tockey at construx.com>>
Cc: "systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>" <systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>>
Subject: Re: [SystemSafety] Post Office Horizon System



On 2021-04-26 20:26 , Steve Tockey wrote:
... But the question still remains in
the general case: more and more software is being delivered which is leading to material harm to the
general public—when will the developers and/or suppliers of such faulty software be held accountable
and liable?

One possible outcome of the Horizon case is that the notion of strict liability for software is
being given a serious airing. The liability is not at the level of individuals but at the level of
the developing organisation.

It is going to be hard to relegate a subtle technical problem to the mercy of the courts, though.
Requirements specification is an unsolved engineering problem, and is likely to remain so for quite
a while (if not for ever). Software systems are often used outside of formal requirements.

So introduction of strict liability could lead to the situation in which developers communicate
formally over-strict requirements on the use of their product. Suppose someone uses that product
outside those formally over-strict requirements. Developer points the finger at user, and, with a
good legal department, wins in court.

Whereas the user might well have been using the system for its intellectually-intended purpose,
where it failed and caused harm. In circumstances in which there was not strict liability and
formally over-strict requirements, that might have led to a negotiation in which the developer
agreed to accept some responsibility for the harm caused.

I agree with your examples, of course, especially the one in which you quote me back at myself :-)

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
ClaireTheWhiteRabbit RIP
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20210427/61aee87c/attachment.html>