using the PSF license for one's code

[Donnal Walter]

Bengt Richter:
> Your motivations would seem laudable, but when it comes to
> babies who are very vulnerable to mistakes [1] I would hate
> to think of, e.g., an IV dosage or flow rate accidentally
> computed with the wrong kind of division.

True. First, let me emphasize that my original question was about how
to license Project 1 (the toolkit/notation), which could *potentially*
be used to write software to run a nuclear power plant or an air
traffic control system as well as clinical applications. I would have
no more say in this regard than GvR does over how the world uses
Python. So for Project 1, a BSD-style license makes sense, and having
reached that conclusion (with the help here), I am not at all
uncomfortable with it.

As you point out, however, Project 2 is another matter. I'll say more
about this below, but in regard to "babies who are vulnerable to
mistakes" let me relate this story. Six years ago we wrote an
"application" using a spreadsheet with GUI overlay to facilitate
writing hyperalimentation fluid orders. Previous to that all of the
orders were hand-calculated by physicians. This app cut the time
required for writing hyperal orders by 70-80% and reduced the number
of errors discovered by pharmacy by 90%. We have used this program to
create over 20,000 hyperal orders, without a single known adverse
outcome. I've had dozens of individuals tell me we should market this
program. Of course it would be difficult to market a spreadsheet, and
I have had no desire to consider it. I also have no desire to release
it as open source, as long as it is in the form of a spreadsheet. But
my point is simply that this is the kind of application that cries out
for *some kind* of open source distribution. On the other hand, most
of the applications we have in mind have more to do with organizing
information than with performing calculations.

Let me also say that we have extensive quality checks OUTSIDE the
application itself. In the case of the hyperal program, a pharmacist
checks the order *carefully* before entering it, another pharmacist
checks it as it is being formulated, and then a nurse checks the order
before hanging fluids.

Incidentally, there is (now) a commercial product available to do this
task, and it carries a disclaimer that the user is responsible for
verifying the accuracy of output. Of course, the source code is not
available for us to look at.

> I would hope that you would concern yourself at least as much
> about using restrictions [2] to ensure that well-meaning but
> inadequately tested "contributions" don't get used by other
> well-meaning but perhaps not so software-QA-issue-aware folks.

Excellent point. Previously, I had not considered writing a custom
license, but this might be the place for it. (With the help of a
lawyer, of course.)

> I would think also that you are skirting very close to a whole
> raft of laws meant to protect those under medical care from
> deficient devices or procedures, and some of those probably
> override attempts to avoid liability. IANAL, but my guess is
> you might want to talk to one to get the real scoop.
>
> I.e., there (I hope) must be more of a threshold to pass
> before using software in the pediatric community than googling
> and accepting the NO WARRANTY conditions, unless it's for games
> in the waiting room or other non-critical uses. But newborn
> intensive care?? ;-/

Yes. When we looked into this a few years ago, the laws and
regulations covering medical devices were quite vague with regard to
software. But IANAL either and it is probably time to get one (or
more) involved again.

David Brown:
> Have you considered whether Python is really a suitable
> language for this job?  It is probably ideal for your first
> project, but not necessarily for the second one.  Python
> makes it easy to write great software, but it also makes it
> easy to make mistakes which can only be found at run-time.
> You might want to consider writing the key working parts
> of the software in a language designed with safety and
> reliability in mind, such as Ada (not C!), while using
> Python for the secondary work (user interface, logging
> results, or whatever).

For a while we considered Eiffel (also designed with safety in mind),
but at the time we looked into it we found the development cycle to be
too cumbersome for writing "custom applications." We have no intention
of becoming a software development shop. We are mostly interested in
"custom applications" that are not being produced by commercial
vendors. Of course safety is of crucial importance to us, but we have
found that Python facilitates the kind of custom development (and
evolution) that we are looking for. To help assure reliability,
though, we separate the abstraction layer and presentation layers and
then do extensive unit testing on the abstraction layer. In fact, we
write the unit tests first.

Regards,
Donnal Walter
Arkansas Children's Hospital