[
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
|
