[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: License Feedback -- health and safety issues


software safety issues
* Ken North <kennorth@s...> [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@e...
    - http://engrm.com/blogometer/index.html
    - http://engrm.com/blogometer/rss.2.0.xml

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.