[SystemSafety] Personal and corporate liabilities as a consequence of safety, security and other mistakes of similar importance

paul_e.bennett at topmail.co.uk paul_e.bennett at topmail.co.uk
Thu Oct 4 13:49:27 CEST 2018


On 04/10/2018 at 12:24 PM, "Paul Sherwood" <paul.sherwood at codethink.co.uk> wrote:
>
>Hi all,
>in recent discussions the topic of 'who goes to jail' has arisen 
>in the 
>context of fallout from software design/development/deployment 
>mistakes.
>
>I'm hoping that I'm misunderstanding the situation, because the 
>picture 
>that is emerging for me seems to lead to a disconnect between
>
>- the need for evidence of what was done and
>- the need for people to be able to work in a safe environment, 
>without 
>fear
>
>It may be FUD, but I believe I heard recently that "any engineer 
>contributing to an automotive project may ultimately be considered 
>personally liable for impacts of their work". Impacts in 
>automotive 
>could include recalls and road accidents, obviously. If that's 
>true, why 
>would any sane engineer ever agree to contribute to an automotive 
>project?
>
>And then there's the FOSS/public work consideration. I recently 
>asked a 
>colleague to contribute to a public project, and during spinup 
>this 
>question of liability arose, expressly phrased as
>
>"If I contribute, is there any possibility that I or Codethink 
>might 
>ultimately be liable for (say) harm resulting from road accidents?"
>
>In the ensuing discussion it was pointed out that:
>
>- if the contribution is to a project applying any of the common 
>FOSS 
>licences (Apache, MIT, ISC, GPL etc) then there is expressly NO 
>WARRANTY
>- any subsequent application/distribution of that software by 
>another 
>party which attempts to enforce a warranty claim on the authors 
>has 
>expressly breached the licence, and has effectively stolen and 
>misused 
>the software
>
>While this reasoning is attractive, I'm not convinced it's enough 
>to 
>convince me that there's no potential liability for individuals.
>
>Are any readers able to guide me on existing literature/reasoning 
>for 
>this?
>
>br
>Paul
>
>
>
>
>_______________________________________________
>The System Safety Mailing List
>systemsafety at TechFak.Uni-Bielefeld.DE

With the FOSS software having the caveat of 'USER BEWARE' in its
approach, then it is difficult to see that anyone but the final integrator
would be liable. As well as breaches to the licensing terms, he would
have failed to apply due diligence in his assessment of teh fitness for
purpose.

For the most part, production of software for acknowledged Safety Related
or Safety Critical Systems would probably be seen in terms of whether
or not the full and appropriate management of the project was compliant
with best practice (even emergent best practice).

It is those who are unaware that their products may pose risk to the end
users and who remain outside the informed safety systems community
that may inadvertently find themselves in such a situation. Is the training
of software developers at the stage that they would automatically ask a
client about such matters?

The population of this list are already well informed enough about the risk
factors, and probably develop their systems software to a high level of
dependability. We do, however, have a big educational remit to continue
spreading the word to the wider community of software developers that
cobbling together 'bloatware' and not being mindful of how they go about
constructing their systems may end up killing someone someday. While
the integrators of such systems should shoulder much of the blame, the
natural effect may be to try and shift the blame elsewhere. The developer
may seem to be a softer and easier target.

Perhaps all software developers should include the 'Not Warranted for Use
in Systems where Safety or Security are issues without consultation with
the author' type statements in the comments of their source code. The
alternative is for everyone developing software to be forced to comply with
a full on and intensive development process that can pass muster in the
approvals ratings. Might stifle some of the very creativity we deem is worth
exploring.

For my end, education of our developers should include the discussion of
risk factors, especially in an increasingly litigious world.

Regards

Paul E. Bennett IEng MIET
Systems Engineer
Lunar Mission One Ambassador
-- 
********************************************************************
Paul E. Bennett IEng MIET.....
Forth based HIDECS Consultancy.............
Mob: +44 (0)7811-639972
Tel: Due to relocation - new number TBA. Please use Mobile.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************



More information about the systemsafety mailing list