[SystemSafety] A Fire Code for Software?

[Ferrell, Uma D.]

I am not so sure that regulation is the only answer; the cultural norm for all involved (software engineers, hardware engineers, system engineers, safety engineers, managers at various levels) should ideally be "to do the right thing".  This would mean to conduct an objective risk analysis, and determine the level of tolerable risk. Adjust the system and software processes to the level of risk.  Policy is almost always a step behind cultural norm.  In case of safety critical software it is the culture that is way behind.  We need to educate organizations that there are economic benefits for nurturing a safety culture. To impose policy solutions to lift the culture that is way behind, will give us superficial solutions instead of lasting holistic result.

-----Original Message-----
From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Philip Koopman
Sent: Monday, March 19, 2018 11:25 AM
To: Steve Tockey <Steve.Tockey at construx.com>; paul_e.bennett at topmail.co.uk; systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] A Fire Code for Software?


I was personally involved in that exercise, including testimony at the US Federal Trade Commission.  The short, not-attempting-to-be-legally-perfect summary is that it would make shrink-wrap license disclaimers legally enforceable even if they conflicted with what would otherwise be default consumer rights.

Turns out that the UCITA proponents weren't able to make a legal distinction between embedded computers and "regular" computers (whatever those might be) and that resulted in too many discontinuities in practical application.  For example, a vehicle maker might be able to disclaim responsibility for all warranty repairs (even purely mechanical
failures) if there was any software in the vehicle at all.  Or could remotely disable your product on a whim ("self help" -- turns out it's not the customer who is being helped.)

Last I heard it was law in Virginia and Maryland but nowhere else, and basically died a quiet death in practice.

Cem did great work on that.  I was just a supporting player.  But I did learn a lot about consumer projection and how political forces work (and don't work) when it comes to attempting to regulate software.

-- Phil

On 3/19/2018 4:41 AM, Steve Tockey wrote:
> As a FYI, Cem Caner has been doing some work along the lines of 
> Consumer Protection and software in the US. Basically, everything is 
> supposed to be governed by something called the Uniform Commercial 
> Code (UCC) that, apparently, can supersede anything that the software 
> vendors would like you to think.
>
> You might want to see: http://badsoftware.com/sepg.htm
>
> It¹s 20 years old now so I can¹t say how up-to-date it is, but it did 
> make for some interesting reading.
>
>
> Cheers,
>
> < steve
>
>
>
>
> -----Original Message-----
> From: systemsafety 
> <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
> on behalf of "paul_e.bennett at topmail.co.uk" 
> <paul_e.bennett at topmail.co.uk>
> Date: Sunday, March 18, 2018 at 4:13 AM
> To: "systemsafety at lists.techfak.uni-bielefeld.de"
> <systemsafety at lists.techfak.uni-bielefeld.de>
> Subject: Re: [SystemSafety] A Fire Code for Software?
>
> On 18/03/2018 at 10:01 AM, "Peter Bernard Ladkin"
> <ladkin at rvs.uni-bielefeld.de> wrote:
> [%X]
>
>> Another move could be holding SW and SW-based-kit supply companies 
>> more accountable for deficits in their products. But the question of 
>> assigning responsibility for such a deficit is already fiendishly 
>> complicated, because of the complexity of the supply chain. It might 
>> just result in expanded legal departments everywhere, along with 
>> ensuing price rise to pay for them.
> I am told that the Consumer Protection Act (in the UK) has the 
> necessary sharp teeth if the legal eagles would bare them. It would 
> definitely make the court cases and preceding investigations longer as 
> they would have to get a much more thoroughly detailed brief.
>
>> I don't think the question of getting everyone to use more reliable 
>> development methods for SW is an easy one. Neither do I think it will 
>> be the solution to the "SW problem". Requirements engineering poses 
>> challenges that are at least as big, and to my mind less susceptible 
>> to pro forma solution.
> Getting good requirements delivered to you demands developers to be 
> more questioning. I know I have expounded this here before but all 
> requirements should be Clear, Concise, Correct,  Coherent, Complete 
> and Confirmable (Testable). Developers should accept nothing less, no 
> matter what discipline they operate in.
>
> Regards
>
> Paul E. Bennett IEng MIET
> Systems Engineer
> Lunar Mission One Ambassador


--
Phil Koopman -- koopman at cmu.edu -- www.ece.cmu.edu/~koopman

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE