OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] License Feedback -- health and safety issues

[ Lists Home | Date Index | Thread Index ]

* Ken North <kennorth@sbcglobal.net> [2005-08-17 02:00]:

> > > or intended for use in the design, construction, operation or
> > > maintenance of any nuclear facility."

> >     It seems obvious that off-the-shelf software is
> >     inappropriate for use as-is in real-time or security intense
> >     environments. Is there a specific reason for nuclear?

> When I was consulting at a nuclear facility, there was a serious
> safety culture.  Chernobyl put nuclear safety in the spotlight,
> but even before the disaster, health and safety issues were a
> major influence on the design, programming and testing of
> applications.

    Before Chernobyl there was Three Mile Island. Before Three Mile
    Island there was Fermi-1. Before Fermi-1 there was Windscale...

    The nuclear plant is the application that is raised whenever
    people start to argue  about software as engineering, as opposed
    to software as a literary work. It's kind of odd, and kind of
    not, that Sun tacked it onto their license. I'm wondering if it
    wasn't in response to Sun specific business at the time the
    license was authored.

> There are a variety of applications at nuclear facilities that
> involve health and safety requirements. If these applications
> fail, people's lives and health are put at risk.

    [SNIP] Interesting.

> We used off-the-shelf compilers, networking software and developer
> tools, but all of the tools went through a review before they were
> approved for development.

    This is what I'd expect. At a nuclear facility there is going to
    be an auditing process for software adoption.
    
    I've read about the line by line audits of code at the FAA, when
    they use exsiting software in critical applications. I'm sure
    for nuclear applications, they are at least as rigorous.

    Thus, the nuclear disclaimer in particular is one that doesn't
    appear to be necessary.
    
> "IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE
> FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
> OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS INTERRUPTION)"

> That boilerplate covers business losses, but there are a variety
> of applications that involve health and safety requirements --
> police and fire dispatching systems, hospital lab, patient care
> and radiology systems, air traffic control, vehicular traffic
> control, pharmaceutical manufacturing and distribution,
> environmental monitoring, defense systems and so on.

    The sentance that proceded the one you quoted appears to cover
    all those applications.

    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
    CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
    INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
    MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
    DISCLAIMED.

    "FITNESS FOR A PARTICULAR PURPOSE" covers all those particular
    purposes. 

    If my software is adopted for one of the nuclear facility
    applications you mentioned, I'm sure the actual software used
    would be actually be a derived work.
    
    Wouldn't the burden be on the the application developers who
    adopted software "AS IS"?

> Perhaps you want to consider a disclaimer about your software not
> being intended for use in applications that put lives or health at
> risk.

    I still don't think I want to get into specific disclaimers,
    because that would call into question the value of the blanket
    disclaimer. Nuclear, aviation, and defense, are applications
    that have audits. Disclaimers for the obviously safety critical
    applications seem frivolus.
    
    Then I'd be concerned that they would call into question why I
    said nuclear, aviation, and defense, and not such-and-such, and
    so-and-so. It's almost as if I'd set an implicit suitability boundry,
    and that boundry is terribly high.

    Thanks for your comments. I hope I don't sound dismissive. I'm
    considerting them carefully. It's very helpful.

--
Alan Gutierrez - alan@engrm.com
    - http://engrm.com/blogometer/index.html
    - http://engrm.com/blogometer/rss.2.0.xml




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS