using the PSF license for one's code

David Brown david at no.westcontrol.spam.com
Thu Nov 7 04:33:51 EST 2002


"Bengt Richter" <bokr at oz.net> wrote in message
news:aqco2l$q2f$0 at 216.39.172.122...
> On 6 Nov 2002 18:29:13 -0800, donnal at donnal.net (Donnal Walter) wrote:
>
> >"Anton Vredegoor" :
> >> 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
>                                           ^^^^^^^^^^^^^^^^^^^^^^[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

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).







More information about the Python-list mailing list