using the PSF license for one's code
Donnal Walter
are many to choose from, two of which are GPL and the PSF license. If
one chooses GPL, there are explicit instructions at the Gnu Web site
on how to use the license. On the other hand, I have not seen any such
instructions for using the PSF license. Can one simply refer to the
PSF license without making changes? Or is it advisable to make a
revised copy, changing the name of the name of the owner/copyright
holder from PSF to oneself, for example? What else is required?
Thanks,
Donnal Walter
Arkansas Children's Hospital
Terry Reedy
"Donnal Walter" <don...@donnal.net> wrote in message
news:918bc22f.02110...@posting.google.com...
Since the PSF license is part of the package covered by the PSF
license, I would assume that it covers itself. That should mean that
a) you can use and modify it (and you should change copyright holder
unless you really mean to donate it to PSF) and b) you do so at your
own risk (if you get into trouble with it, you don't sue PSF).
Terry J. Reedy
PS The above is offered on the same terms 8-).
Martin v. Loewis
> If one wishes use an OSI-approved license for one's own code, there
> are many to choose from, two of which are GPL and the PSF license. If
> one chooses GPL, there are explicit instructions at the Gnu Web site
> on how to use the license. On the other hand, I have not seen any such
> instructions for using the PSF license. Can one simply refer to the
> PSF license without making changes?
No: that is "between the Python Software Foundation (PSF), and the
Individual or Organization (Licensee) accessing and otherwise using
Python 2.2 software". Unless you are the PSF, and unless you ship
Python 2.2, you cannot meaningfully establish such a contract.
> Or is it advisable to make a revised copy, changing the name of the
> name of the owner/copyright holder from PSF to oneself, for example?
> What else is required?
If you systematically update all legal entities in this document, you
certainly arrive at what I would consider a meaningful license, and
you could use it right away. I don't think anybody but you and your
licensee could "require" anything about your license: If you want to
put the text "you can use this software only on Sundays" into the
license, nobody could stop you from doing so.
Of course, with any changes to the license text, the license probably
loses their OSI-approvedness (ask OSI for details).
In short, we (the PSF) don't care about other uses of this text,
beyond it being a license for Python.
Regards,
Martin
phil (at) linux2000.com
>
> In short, we (the PSF) don't care about other uses of this text,
> beyond it being a license for Python.
>
I have been wondering for some time how it is possible for anything
other than Python 2.2.x to be licensed under the PSF terms, but there
seem to be a substantial number of coders out there doing just that.
So where does this leave software such as PythonCard ?
(http://pythoncard.sourceforge.net) - this is released "under the Python
2.2 license".
As a result of writing some software of my own and making it available
for download from my website, I've actually spent some time this last
few days looking at the various 'Free software' licenses, and have come
to the conclusion that by far the majority of them are anything but.
I've been apalled (and my apologies for straying slightly off-topic
here) by the amount of fragmentation that exists in terms of the
licenses deemed to be either "Open source compatible" and/or "GPL
compatible" on the OSF website.
The open source community seems to be shooting itself in the foot on
this particular issue, as far as I can see.
</rant> :-)
Martin v. Loewis
> So where does this leave software such as PythonCard ?
> (http://pythoncard.sourceforge.net) - this is released "under the
> Python 2.2 license".
That statement may or may not be legally relevant, IANAL. However, I
think that doesn't matter: what matters is whether users get an idea
what the author of the package allows them to do with the software. If
the user and the author have the same understanding of what is
permitted, and users stick to these rules, the legal standing of the
license is irrelevant.
If users do things that the author dislikes, and the authors brings
that up to court, the court will decide. On thing it is clear in that
case: the lawyers win.
> I've been apalled (and my apologies for straying slightly off-topic
> here) by the amount of fragmentation that exists in terms of the
> licenses deemed to be either "Open source compatible" and/or "GPL
> compatible" on the OSF website.
>
> The open source community seems to be shooting itself in the foot on
> this particular issue, as far as I can see.
I very much doubt that. People developing and using open source
software are much more bound by social constraints than by legal
ones. They interpret licenses themselves (without having lawyers
analyse them), to get the spirit of the license. If some organization
apparently violates some license, the community gets upset, and the
organization reconsiders.
Regards,
Martin
David Brown
"phil (at) linux2000.com" <"phil (at) linux2000.com"> wrote in message
news:3dc867de$0$24754$7b0f...@reader.news.newnet.co.uk...
> Martin v. Loewis wrote:
> >
>
> The open source community seems to be shooting itself in the foot on
> this particular issue, as far as I can see.
>
Just for comparison, can you think of any two close-source packages that
have the same licence? Most suppliers seem to change their EULAs, Terms and
Conditions, etc., faster than they change their software.
There are basically two categories of open source licences, as far as I can
see - gpl-type licences (you can use our source, but you have to apply the
same licence to the modified code) and bsd-type licences (you can use our
source for anything you want, but you have to acknowledge the copyright). I
am a great believer in the spirit of a licence rather than the letter of the
licence, and as far as I can see, the Python licence is in the same spirit
as the BSD licence. I don't know how that would stand up in court, however,
but hopefully it will never have to.
Chris Gonnerman
From: "David Brown" <da...@no.westcontrol.spam.com>
> Just for comparison, can you think of any two close-source packages that
> have the same licence? Most suppliers seem to change their EULAs, Terms
and
> Conditions, etc., faster than they change their software.
Indeed, sometimes faster than they change their socks.
Read a EULA for a commercial product sometime; especially
one from the evil billionaire's club in Redmond. Then
compare it to the GPL, for instance. Even rabid GPL haters
must admit that the GPL is much less vicious and nasty
than anything from most commercial vendors.
Chris Gonnerman -- chris.g...@newcenturycomputers.net
http://newcenturycomputers.net
Donnal Walter
> There are basically two categories of open source licences, as far as I can
> see - gpl-type licences (you can use our source, but you have to apply the
> same licence to the modified code) and bsd-type licences (you can use our
> source for anything you want, but you have to acknowledge the copyright). I
> am a great believer in the spirit of a licence rather than the letter of the
> licence, and as far as I can see, the Python licence is in the same spirit
> as the BSD licence. I don't know how that would stand up in court, however,
> but hopefully it will never have to.
Well, I'm not likely to take anyone to court, and neither is my
University for that matter.
For entities like PSF that distribute a lot of copies of their
software, it probably makes sense to write their own specific
licenses, but for everyone else (like me) it seems to boil down to
choosing GPL or BSD. Who would have guessed that it could be this
simple? (And I am not being sarcastic; this thread has helped me
considerably.) Thanks.
Donnal Walter
Arkansas Children's Hospital
University of Arkansas for Medical Sciences
David Brown
That's certainly how I look at it (perhaps with a bit of variation - if I
want to release a Python module, I'd probably say "python licence" rather
than "bsd" licence, simply to be consistant with other python modules). But
if you are doing something big or important, you might want to get some
legal guys to look at it - my (perhaps unfounded) impression is that
American lawyers are much better at "letter of the law" than "spirit of the
law".
Anton Vredegoor
>For entities like PSF that distribute a lot of copies of their
>software, it probably makes sense to write their own specific
>licenses, but for everyone else (like me) it seems to boil down to
>choosing GPL or BSD. Who would have guessed that it could be this
To me it isn't that simple. From my perspective the GPL is using the
same kind of "weapons" to defend it's followers against the "evil"
closed sourcerers.
Using the same kind of weapons as the enemy risks becoming oneself
that what is feared. I think this is meant by "not resisting evil" and
"turning the other cheek" and such ideas as one can find in the old
books.
So the GPL is the enemies weapon turned around and used against the
enemy itself. Just read the legal language inside the document to
proove this.
The BSD is of a somewhat less radical nature in that it is trying to
defend the authors against users trying to legally attack them. It
could be described as a shield. But we know how murky "defense only"
arguments can get.
There also is the option of completely giving away all rights to the
code -placing it in the public domain- which can be compared to having
no defense at all, like "turning the other cheek". This is dangerous
too because although one can give code away, some legal attacks might
succeed in linking the code to the author again and even sue the
author because the users were not properly warned against possible
dangers arising out of using the code.
So to me the license one uses is an indication of what moral level one
is currently acting on. For me this means that although I see that it
is better to not resist evil I am still not wise enough to not step
aside if someone is hitting me, so that means it's BSD for me now, and
sometimes public domain if I am in a philosophical mood.
AV.
1 Corintians 6:13
sism...@hebmex.com
>
> ...
> There also is the option of completely giving away all rights to the
> code -placing it in the public domain- which can be compared to having
>
> AV.
>
I might be wrong, but in the US, and other countries I believe,
you cannot disclaim your author's rights, or somehing like that,
which means that even if you say "I place it in the public
domain", it doesn't actually become "Public Domain" in the
true sense of it, but more like "Freely Distributable", but
very much yours. So, you *are* legally vulnerable to claims
and attacks.
So there is a need for a license to permit free distribution,
disclaim any responsability upon use of the software, "you're
on your own, you're getting your dollar's worth in support,
etc etc".
:-/
sux.
-gustavo
Donnal Walter
> To me it isn't that simple. From my perspective
> the GPL is using the same kind of "weapons" to
> defend it's followers against the "evil"
> closed sourcerers.
> Using the same kind of weapons as the enemy risks
> becoming oneself that what is feared. I think this is
> meant by "not resisting evil" and "turning the other
> cheek" and such ideas as one can find in the old books.
As the OP, I did not intend to start yet another flame war regarding
the merits and/or evils of "copyleft". I was merely puzzled by the
fact that the Python License is on the list of acceptable licenses one
can choose for a SourceForge project, but I couldn't figure out how I
could use the PSF License without modification. Martin confirmed the
fact that I can't. It appears, then, that a number of developers
simply use "Python License" as a well-understood synonym for BSD-style
license, which is fine with me. But I figure I might as well say what
I mean, so my options are GPL or BSD, the relative merits
notwithstanding.
Having said this, I see both as valid options in my situation. I am
working on two different kinds of projects. The first project is to
develop a kind of toolset and notation for building custom clinical
applications. I had planned to use the PSF License and now plan to use
the BSD license for this project, as I want to encourage its
widespread use by not using a restrictive license. I only hope that
*some* of its users give me valuable feedback about how to make the
toolset better. If other users want to use the toolset for other
purposes, I only ask that not hold me liable if it doesn't work as
they expected, etc.
The other project, however, involves using this toolset/notation to
build a set of clinical applications for newborn intensive care. In
this case, I truly do want to be restrictive. If others derive
products from this project, I want the derived products to be open
source as well. In saying this, I don't view myself as being hateful
or vindictive or as fighting evil. I simply want to encourage
individuals and companies who build on these applications to give
their products back to the pediatric community. So, for the second
project, I am strongly inclined toward GPL.
Donnal Walter, M.D., Ph.D.
Bengt Richter
^^^^^^^^^^^^^^^^^^^^^^[1]
>this case, I truly do want to be restrictive. If others derive
^^[2]
>products from this project, I want the derived products to be open
>source as well. In saying this, I don't view myself as being hateful
>or vindictive or as fighting evil. I simply want to encourage
>individuals and companies who build on these applications to give
>their products back to the pediatric community. So, for the second
>project, I am strongly inclined toward GPL.
>
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.
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.
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 threshhold 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?? ;-/
Regards,
Bengt Richter
David Brown
"Bengt Richter" <bo...@oz.net> wrote in message
news:aqco2l$q2f$0...@216.39.172.122...
I would also obtain legal advice before deciding on the licence. Perhaps
you can make a seperation between the software you write, which could well
be gpl'ed, and the use of the software for pediatric care, which might need
additional legal contracts or disclaimers. Your software might save the
lives of a hundred babies, but if someone claims it made their baby puke
you'll have lawyers pulling you to shreds.
However, don't be alarmed about using software that disclaims all
warranties - you won't find software anywhere, closed or open, with
warranties covering more than the media they are distributed on. At least
with open source software you can personally audit the code you use.
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).
Donnal Walter
> 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,
Anton Vredegoor
<da...@no.westcontrol.spam.com> wrote:
>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).
This thread is filled with reverse psychology! First the idea is
proposed to use the GPL because it's in the best interest of the
babys, which is doubtfull. Then it amounts to using lawyers to protect
the interests the authors of the sourcode, which would certainly
damage the interests of the babys. Now it reaches a state where using
a "safe and reliable" language is proposed instead of using python,
which is comparabale to throwing away the babys and keeping only the
bathing water.
Please stop trying not to start a flame war.
AV.
David Brown
"Anton Vredegoor" <an...@vredegoor.doge.nl> wrote in message
news:aqdpmv$lv1$1...@news.hccnet.nl...
The author thinks the GPL is in the best interest of the babies, because it
will let other doctors freely use the program, and will ensure that any
improvements to the program will benifit all users. The lawyers are
involved to protect the author from other lawyers, so that he can go on
writing and using this code for the benifit of the babies.
As for the safety of the language, it all depends on what the system is
doing. Judging from other posts, it looks like it will be a calculation aid
rather than directly controlling something, so there are additional human
checks along the line. Python makes it quick and easy to write code, but if
you are controlling something this important directly, then you want a
language that will give you the best help in getting correct code, and that
means using a strongly-typed language - in addition to Python for the
non-critical parts.
> Please stop trying not to start a flame war.
Meaning please start one?
>
> AV.
sism...@hebmex.com
>
> "Anton Vredegoor" <an...@vredegoor.doge.nl>
>
> > Please stop trying not to start a flame war.
>
> Meaning please start one?
>
Liberally sprinkled with negatives, it gives us:
"Please Don't Stop Not Trying Not To Not Start A Flame War"
which is almost but not quite exactly unlike the original
meaning. Sounds like a telegraph.
-gustavo
pd: Have a nice thursday! ;-)
Anton Vredegoor
>"Please Don't Stop Not Trying Not To Not Start A Flame War"
Ok. I was trying to explain that overdoing things might result in the
opposite outcome. Also I had planned to quote an entirely different
part of the corintians. It must have been an act of god that prevented
me from doing that.
All this is giving me a headache so I'd better quit.
Regards,
AV.
reading Douglas Adams will get you into trouble.
Donnal Walter
> All this is giving me a headache so I'd better quit.
My original question was answered clearly, and as a result I am
preparing a BSD license for Project 1 instead of piggybacking on the
PSF license. Thank you everyone for the thought-provoking comments
regarding Project 2. Today I joined the Openhealth mailing list, where
I intend to pursue these issues in greater detail.
When I have something to release, I will return here with an
announcement. :)Now back to lurking (I learn so much from this
newsgroup/list).
Terry Hancock
> 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.
Yep: "high use-value, low-sale-value" fits Eric Raymond's analysis anyway.
> 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 like the idea that *full-disclosure* should be a defense against
liability claims. Because it seems fair to me that if I can find out
fully how something works, it's reasonable for me to take
responsibility for it.
I think the thing to realize about open-source versus closed-source
for reliability is that using closed source may reduce your responsibility
-- i.e. you can pass the blame onto the source of the software more
easily if it fails and kills somebody. But it doesn't do anything to
reduce the actual chance of it killing somebody. In fact, the "fewer
eyeballs" effect -- an indirect, but definite correlation to being closed-
source -- probably *increases* the actual risk.
Or to put it another way -- no amount of life insurance will save your
life. Wear a seatbelt instead.
For people who *really* care about safety (as opposed to liability),
open-source is usually going to be a good choice. That's because
there's just no practical way to get so many people to check closed-
source code. I'd like to think that when the stakes are life and limb,
that people *are* more concerned about safety than liability.
I think this is the reasoning behind the military and data security
folks who argue for using open-source code. Certainly it was not
an obvious result. I think it started because a lot of users had a
feeling that open-source code was more reliable without actually
knowing why. Then I remember there were some articles talking
about proving it by running the Gnu utilities and the control
group of commercial Unix utilities against random data and counting
the crashes. It was only after that that I started seeing arguments
for *why* this should be so. (IIRC -- other people may remember
this differently, I certainly don't have references).
It was certainly a revelation for me -- I guess I'm a "free-software
convert".
> 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.
Really, though, the software should be extensively tested at the
run-time level, anyway. Also, the real question is "what happens
if it does break?". In this case, it sounds like a pharmacist checks
it anyway. If it's too far out of bounds (i.e. deadly), they're going
to catch it right-away (humans are good at that). If it's subtly
wrong, it probably won't kill anybody -- medicine isn't *that*
precise. I remember being somewhat shocked at how imprecisely
pharmaceutical units are defined or measured (how big is a "drop"?).
And as the OP points out, the accuracy ratio is better compared
to hand-calculation anyway, so while some hypothetical ADA-based
solution might be even more reliable, it seems like the problem
is getting solved.
Cheers,
Terry
--
Anansi Spaceworks
http://www.anansispaceworks.com
Bengt Richter
>Donnal Walter wrote:
>> 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.
>
>Yep: "high use-value, low-sale-value" fits Eric Raymond's analysis anyway.
>
>> 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 like the idea that *full-disclosure* should be a defense against
>liability claims. Because it seems fair to me that if I can find out
>fully how something works, it's reasonable for me to take
>responsibility for it.
I think that is an interesting point, though usually you depend on trust
a fair amount. There just isn't enough time to do source walkthroughs of
all the software you are going to run. I wonder if you could design open
software to generate module coverage/use statistics that could be contributed
with a click or two to a QA server, to generate automatic reliability ratings.
So you could tell absence of problem reports from absence of use.
>
>I think the thing to realize about open-source versus closed-source
>for reliability is that using closed source may reduce your responsibility
>-- i.e. you can pass the blame onto the source of the software more
>easily if it fails and kills somebody. But it doesn't do anything to
>reduce the actual chance of it killing somebody. In fact, the "fewer
>eyeballs" effect -- an indirect, but definite correlation to being closed-
>source -- probably *increases* the actual risk.
>
>Or to put it another way -- no amount of life insurance will save your
>life. Wear a seatbelt instead.
>
>For people who *really* care about safety (as opposed to liability),
>open-source is usually going to be a good choice. That's because
>there's just no practical way to get so many people to check closed-
>source code. I'd like to think that when the stakes are life and limb,
>that people *are* more concerned about safety than liability.
I think so too, however, attention has to be attracted and eyes motivated
by some presentation of the information. It's not automatic.
There is no such thing as a "safe" language that can turn a bad or
incomplete specification into a good program. An incomplete specification
does not adequately reflect the role of the software in the total system, and
unnecessarily leaves it to humans to notice that e.g., a 16-kg preemie weight
probably should be 1.6 kg etc. An Ada program that just calculates proportional
dosage can be "correct" but garbage in garbage out is not the right attitude
for a system affecting lives. The spec should say something about human keying
errors etc. Re that, see
http://catless.ncl.ac.uk/Risks/21.49.html#subj2
and for a read that will turn your stomach re software and medical devices, follow
the link to
http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html
(for a mix of more or less consequential stuff, browse http://groups.google.com/groups?q=comp.risks)
Would open source have done better? Well, I think we should say "the open source
community" rather than just "open source," because the key is a bunch of _people_
who care to engage their minds, and a relatively efficient mechanism for getting
their attention and collaborating.
I am sure many suggestions for improvements would have appeared in short order
if the Therac software had been posted to a public medical software QA newsgroup,
where people would be extra motivated to help make it right. And OT post here
would probably not do too badly either ;-)
I have no doubt that the open source phenomenon could be brought to bear on the
concept and specification phase of systems design much more generally than
just software aspects too. I.e., if the software is used by a doctor, but the
result always goes through the hands of a pharmacist and a nurse, what would make
the system as a whole more reliable? It takes a combination of people who intimately
understand various aspects and interactions in the system, and what is critical and
what isn't, and also others who can imagine technical _system_ possibilities as well
as implementations of particular micro-jobs. E.g., what if everyone involved had wifi
pda's and there was a system monitoring events in time and space, and sanity-checking
values and delays, and lighting big red lights and making automated cell calls when
something is out of norms. Well, in an open forum there will be people who see both
flaws and opportunities in blurts like that, and so the entire process becomes a kind
of genetic algorithm operating to evolve and refine ideas.
Regards,
Bengt Richter
Donnal Walter
> ...Well, in an open forum there will be people who see both
> flaws and opportunities in blurts like that, and so the entire
> process becomes a kind of genetic algorithm operating to evolve
> and refine ideas.
>
Yes, exactly. A small part of my motivation is to come up with custom
applications that are not available elsewhere, but a greater incentive
is to create applications that can evolve. The software we build today
will necessarily reflect many of our established work processes, but
well-crafted software should help us see ways to improve our work flow
as well, and then the software must evolve to fit the new processes.
The open-source approach fits right into that way of looking at
things.
This is one of the reasons I am enthusiastic about Python. I'm
experienced enough to know that there are no magic solutions, but
Python makes it easier to make incremental changes with extensive
testing than any other environment I have ever used.