[Asterisk-Users] Re: Advice on OS Choice

[Joe Greco]

> On Friday 15 October 2004 15:19, Joe Greco wrote:
> > I don't know.  I've been in a position where it's been a concern.  Have
> > you?
> 
> That condition should never come up.

Well you can say "should this" and "should that".  Terrorists should never
blow up innocent people.  Doesn't seem to stop it from happening.  :-(

This is the real world.  Few things are absolute.

> > However, the electronics shop staff at many larger hospital facilities are
> > sharp cookies.  The possibilities for "well let's just do..." are quite
> > extensive.  These people are not automatically qualified to go changing
> > the code on these devices just because they've got it and they're able to
> > read C, but providing the code would be unnecessary temptation.  They lack
> > the background on the hardware, and more importantly the resulting product
> > isn't certified, so now you have an unknown.
> 
> If they're sharp cookies then they're also smart enough to know that they are 
> liable if they fuck something like that up.  Having access to the source is a 
> red herring in this case.  They could just as easily tinker with hex dumps 
> and try to make it work.

Giving them the source is like a road map to the system.

With hex dumps, it's a lot more difficult for them to bypass your redundant
system integrity checks.  Not impossible, but a lot more difficult.  It
means you need to put some serious effort into the reverse engineering.

If you give them source, it's more a matter of "grab the appropriate
compiler off the 'net and have at it".

Now, in many cases, the side effects of that might be harmless.  Changing
the display color scheme isn't going to harm anything.  Until, that is,
a parameter goes into alarm, and the system misallocates a color for the
alarm font, and suddenly the font that should have been drawn in red is
being drawn in black, against a black screen, because the original design
allowed for a certain number of colors, and was validated extensively with
that, and along came this unauthorized and unvalidated code revision, and
suddenly it fails, because there was a fundamental misunderstanding that
the hardware only supported 256 colors, most of them used for shades of
yellow for the antialiased line requirements.

And someone dies because the doctor can't see the alarmed value, which
the device is valiantly trying to point out.

So much for harmless little changes.

Now what happens next is even worse, because the electronics shop guy who
did this, in a very human gesture of "CYA", replaces the modified image
with the factory image, because the first thing they did was to send the
unit down to the shop as defective.

Are they liable?  Well, of course they are, if you can prove it.  This
requires that someone be clued in to the possibility that this happened.

Under a closed source model, this kind of thing is generally considered
highly unlikely to virtually impossible, because the equipment in question
runs a variety of integrity checks to make sure that the program image has
not been altered (most frequently due to the storage medium going bad).

> > The obvious answer is: don't distribute the source, which is merely an
> > attractive nuisance.
> 
> I suppose, but it doesn't mean that having the source handy makes it a 
> problem.  Regardless of whether the source exists or not the policy 
> surrounding the equipment is every bit as important as the existence of 
> source.

Of course, but that doesn't always translate as you'd hope.

You can have all the nifty policies you want, but there's always the person
who thinks they're smarter than the policy.  Frequently they might even be
right, because many policies are moronically stupid.  Unfortunately, these
people tend to learn to ignore policies and do as they please anyways.

Which brings us back to square one.

There are indeed times when it is not appropriate for the source to a
distributed work to be published.  I'm fine with the idea that such
projects cannot necessarily use GNU software.  I'm not fine with the
attitude of GNU evangelists that "oh well they get what they deserve",
or that somehow it is to the advantage of a software project to blow
off such potential contributors just because they are not able to
license their entire product under GPL.

(Incidentally, this is part of why the LGPL was introduced, so even
the so-called FSF has tipped its hat to these legitimate concerns.)

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.