> 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. _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
