At the risk of biting on troll-bait:

Should we continue to pay Microsoft for its buggy
software packages?

Well, not unless you want to. There *are* plenty of alternative packages out there. No need to buy from M$.

Can we sue it for the damages that
it can potentially cause to our company (interms of
cost, reputation, etc)?

<RANT> Aye, there's the rub. Read the license and the answer seems decidedly no. Furthermore, where else but in software can a product which has significant problems be released, the problems concealed until the manufacturer is ready to deal with them, and the fixes be considered proprietary?


Before all of the software engineers dive on me, let me qualify my comments.

(1) As a practicing civil engineer, liability for failure of a
structure I design would follow me for life.  Literally.  Even
failures due to loading beyond the required design capacities at
the time of construction.  This leads to a different standard of
care and rate of correction for errors in what we do than I have
observed in many other disciplines.  Should everyone be held to
this standard?  I'm not even sure *we* should be, but there it is.

(2)  The damages suffered by persons and businesses affected by the
Ford/Wilderness AT tire recall fiasco a couple of years ago had their
tires replaced *at the expense of the manufacturer*.  Even this did
not relieve liability for those who had suffered supplemental damage,
such as bodily injury, as I understand the situation.  Software
firms supply patches, at best, and many are beyond obfuscated about
finding them.  This is becoming better, but often deluges your
email address with so many peripheral sales emails, it's hard to
find the patch announcement.

(3) If the air traffic control system, or the computers at a
series of large corporations suddenly went down due to a flaw in
some OS/software, my reading of practically every license I have
ever seen absolves the OS/software producer of any liability.

The software is, generally speaking, "provided without any
warrantee explicit or implied, including a warrant of
merchantability or fitness for the purpose sold."  This is
an actual quote from an EULA sent to me by a student some time
back.  I'd have to dig up where it originally came from, but most
software licenses have similar terms included.  Can such license
terms be enforced?  I dunno, IANAL, nor do I play one on TV.
I can tell you I'm not happy that the word processing software
I buy may not function as a word processor, and the license, if
I read it correctly, specifically disclaims any warrantee of
functionality. Of course, I have yet to actually *encounter* software
which did not at least *mostly* fulfill the advertised features,
or which was not accepted as a return by manufacturer if it did
not.

Well, since I ranted for so long, I might as well offer ideas
for altering the situation.  I hesitate to call them "fixes", since
I know how dangerous such an idea can be.

(1) Perhaps software should at the very least be warranted to perform
the basic functions advertised and designed in.  If it doesn't, the
manufacturer should be liable for the costs to apply patches, beyond a
"reasonable" application time which is universally accepted.  Remember
I didn't call these fixes?  ;-)  Patches must be supplied free of charge
to fix problems with released software.  No bundling patches with
feature alterations and calling it an "upgrade".  Bugs should be fixed.
It's just good coding practice.  Yes, it's expensive.  Make fewer
mistakes.  [He says, charging into the mouth of the dragon.]

(2) I assume that special-purpose software, such as air traffic control,
which perform life-safety functions is designed, tested, and warranted
to a higher standard.  If not, this item perhaps moves to item 0.

(3) As much as I understand the reasons for maintaining confidentiality
while a patch is being developed, I think that it would be good practice
for at least security vulnerabilities to be released to the registered
owners of the pertinent software packages when they are discovered.
Getting hit by a bug before you know it exists sucks. At least if you're looking, an alert network or sys admin might be able to nail down the
doors while waiting for a patch to be released. There will probably be
plenty of black hats who hear all about the vulnerability long before
the company has a patch available.


(4) Responsible reporting of problems by customers has to play a role in
effective software maintenance.  I can't tell you how many times I have
had someone tell me that their actuator/data acquisition system/instrument
isn't working when I ask how their test is coming.  When I ask when
the problem started, the answer is frequently "right at the end of the
last test."  So why didn't you *tell* me right at the end of the last test.
*Sheesh*
</RANT>

Just my $0.02.

Charley

--
Charles Hamilton, PhD EIT               Faculty Fellow
Department of Civil and                 Phone: 949.824.3752
    Environmental Engineering           FAX:   949.824.2117
University of California, Irvine        Email: [EMAIL PROTECTED]



---------------------------------------------------------------------------
----------------------------------------------------------------------------



Reply via email to