Should Microsoft Be Liable For Bugs?
from the the-big-question dept
The big question that keeps coming up over and over again is whether or not Microsoft should be liable for all these bugs. Now it's even being asked by Microsoft's hometown paper. Those who favor the argument say that if any other product had the amount of flaws with the impact that Microsoft's flaws have, there would be class action lawsuits galore. Those against it point out that it's impossible to know how people will use software and to figure out ways to fix all bugs. Worse (and this is the part that concerns me the most) it would make it nearly impossible for small or independent software operations to release anything. It would slow down innovation. At the same time, even if Microsoft could be sued for the flaws, it would be unlikely that they would lose. The lawsuits would have to show that Microsoft was specifically "negligent" in their actions. While some may feel that Microsoft should be doing a better job, that doesn't necessarily make them negligent.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Reader Comments
Subscribe: RSS
View by: Time | Thread
DLL's
[ link to this | view in chronology ]
Re: DLL's
Mac computers have been really bad about this until recently, but the OS is now candy coated unix.
Anyway, I dont think they are complaining as much about bugs as they are about security flaws/exploits. The title of that article is really poor.
You're lucky you didnt post that on slashdot, you'd be all crispy now.
[ link to this | view in chronology ]
Re: DLL's
What about the security flaws/exploits of other OS's? There are plenty of unix viruses.
"You're lucky you didnt post that on slashdot, you'd be all crispy now."
Too much traffic, too complicated filtering system, so I don't do slashdot.
[ link to this | view in chronology ]
Re: DLL's
[ link to this | view in chronology ]
Re: DLL's
[ link to this | view in chronology ]
Re: DLL's
VMS is an amazingly stable OS. Our VMS servers never crash. But if you want to upgrade or add anything you're locked into proprietary hardware and software. Ever since Compaq bought up DEC they've been trying to kill off the VMS product line and now the whole Alpha product line.
[ link to this | view in chronology ]
Re: DLL's
[ link to this | view in chronology ]
Re: DLL's
whoa there Dorpus. Who is feeding you this info? I've know of viri on windows, macos and I even remember them back on the Amiga, but I dont think I've ever heard of a unix/linux virus.
Worms, sure. But I'll bet that most of the bad publicity that unix/linux got was from the two most craptastically exploitably programs apparently written by drunks: bind and sendmail. These two programs have a fairly simple function but for some reason keep getting cracked. If those were written correctly unix/linux would have a much better track record.
As for those terminals locking up when the keyboard was unplugged I suspect it was a hardware problem, not the OS, but even if it was you cant really judge a OS's robustness by its ability to handle changes in hardware while its running. I dont even know if old sun terminals were running unix, it might have been some stripped down OS that ran an X server.
[ link to this | view in chronology ]
Re: DLL's
[ link to this | view in chronology ]
Ok, then explain this.
There is a call that lets you get the MAC layer address from your network card. When Mircosoft 'patched' for the blaster issue, that call now returns a fixed address.
Please explain how such programming is not negligent?
[ link to this | view in chronology ]
Re: Ok, then explain this.
Please clarify--why is a call for the MAC address a problem, and what do you mean by 'fixed address'?
[ link to this | view in chronology ]
Yes, because "the hood is welded shut."
[ link to this | view in chronology ]
ms = bugs = profit
[ link to this | view in chronology ]
Re: ms = bugs = profit
When I read this subject line, only one thing came to mind..."We are getting a hell of a profit fixing Microsoft's bugs!"
After all, if it wasn't for Microsoft, I probably wouldn't have the decent paying, great experience, "god I love to come to work" job I have right now. They are literally paying my paycheck with their lack of security.
Of course, my job as a Linux/BSD/Cisco administrator is stable, so I could always just spend all my time at work doing that, but it is more fun doing heavy patching of Windows boxes, and then of course the extra time spent investigating the break-ins and viruses under the Windows OS which makes my life complete...
Hidden and tags within document.
[ link to this | view in chronology ]
Analogies with other products
With many products there's a concept called "merchantability", which basically says that if a device is sold as a sewing machine, it needs to be able to sew in the way a reasonable person would expect to do so. Another example is a used car, the steering should turn the wheels, it should move when expected to, it should eventually stop when the brakes are pushed. After that, you're on your own.
Maybe there's a way to include concepts like this for software. Perfection isn't expected, but a package should state it's intended functions, and should, at a minimum perform those functions in any reasonable computing environment. Using the Firestone example, I should be able to fit the tire to any appropriately sized wheel, and I should be able to expext a reasonable product lifetime when driven over typical surfaces. If I put the tires on the wrong size wheels and drive 150 MPH on gravel, well, I guess it's my fault if I get a flat (or worse).
Security-wise there's plenty of precedent for "reasonableness" in other areas - I can't very well accuse someone of theft if I leave my CD player on the sidewalk overnight with no identification on it. If they break into my locked car to get it, that's a different story. Maybe these sorts of examples can be made into a workable "reasonable" standard for security expectations for software vendors.
The key here is to provide some sort of information (and possibly recourse) to consumers without creating barriers to entry for new software authors. Not an easy problem, but probably not impossible either.
[ link to this | view in chronology ]
Re: [False] Analogies with other products
1. The concept of implied warranties of merchantability or fitness for a particular purpose were legal constructs designed to allow for physically injured persons to recover when they were harmed by a product. Those doctrines became strict liability, which says that you can't bargain away, as in an EULA, your protection from physical harm. Legal thinking then and now is that people should be allowed to bargain away their protection from economic harm since people and businesses do this all the time - it's called insurance or hedging or any of a dozen other forms. Those concepts are not readily transferred to software.
2. You most certainly can be convicted of theft of a CD player with no name on it left on the street. States have slightly different versions of their statutes, but in NY for example, anything you find has to be turned in to the police and, if unclaimed, you may claim it. So your premise is unfortunately wrong (in spite of all we've heard, finders are not keepers and losers not always weepers).
Even if it were true, I'm not sure that "reasonableness" is as good a standard in this situation as we might think. I am not a Mac expert or even casual user, but do we all believe it's *really* true that Macs are impervious to viruses, or that MS is simply a bigger target (for many reasons)? What Mac users think is "reasonable" may simply be luck or anecdotal evidence.
[ link to this | view in chronology ]
Re: [False] Analogies with other products
You are quite correct when you talk about exisitng liability concepts having trouble in application to software. The original article makes this point as well. That's why I think we'll eventually be in a situation where definitions and applicability will need to be legislatively determined. Not an appealing idea when you consider how bad some of our computing-related laws have been. But you're right, in thier current form you'd have trouble getting merchantability laws to work for software.
As for the second point - I simplified the example to the point of inaccuracy. We're not even talking about criminality here, rather civil matters (for which liability limits need to be defined). I probably should have referred to being able to recover damages if you haven't met the burdens of discovery and minimization in relation to minding your own "security" - but that just seemed to be a little too obtuse.
So, thanks for the excellent points. Have a great weekend.
[ link to this | view in chronology ]
Re: [False] Analogies with other products
"But since the mid-1990s, a string of court decisions has upheld the validity of using license (nb: context implies shrink-wrap) agreements to limit a software maker's liability."
Is this true?
Have products sold over the counter ever been determined to be not Uniform Commercial Code?
Can anyone cite a reference please?
[ link to this | view in chronology ]
Possible marketing advantage for Microsoft
- adam
[ link to this | view in chronology ]
MS should not be liable...
[ link to this | view in chronology ]