home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / security / misc / 2340 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  6.9 KB

  1. Xref: sparky comp.security.misc:2340 comp.org.eff.talk:7797
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!ub!csn!teal!bhayden
  3. From: bhayden@teal.csn.org (Bruce Hayden)
  4. Newsgroups: comp.security.misc,comp.org.eff.talk
  5. Subject: Re: Stupid Licenses (YUCK!)
  6. Message-ID: <bhayden.724690634@teal>
  7. Date: 18 Dec 92 14:57:14 GMT
  8. References: <1992Dec11.163322.24608@news2.cis.umn.edu> <XNmqVB1w165w@ruth.UUCP> <bhayden.724495103@teal> <1992Dec18.024239.11331@news2.cis.umn.edu>
  9. Sender: news@csn.org (news)
  10. Organization: Colorado SuperNet, Inc.
  11. Lines: 123
  12. Nntp-Posting-Host: teal.csn.org
  13.  
  14. charlie@umnstat.stat.umn.edu (Charles Geyer) writes:
  15.  
  16. >In article <bhayden.724495103@teal> bhayden@teal.csn.org (Bruce Hayden) writes:
  17. >>rat@ruth.UUCP (David Douthitt) writes:
  18. >>
  19. >>>charlie@umnstat.stat.umn.edu (Charles Geyer) writes:
  20. >>
  21. >>>Thank goodness someone else noticed those warrantees.  What a load of
  22. >>>MALARKEY ...  Thank goodness for the part that says "SOME OF THESE
  23. >>>LIMITATIONS MAY NOT BE VALID IN SOME STATES" -- ie, some states have
  24. >>>passed laws that actually (GASP!) force a company to be (OH MY!) RESPONSIBLE
  25. >>>for its products... in Wisconsin, Ibetcha it's the "Lemon Law" that I've
  26. >>>heard about...
  27. >>
  28. >>>Now if it was only possible to get rid of the part that says,
  29. >>>YOU DON'T OWN THIS PRODUCT, WE DO.  YOU ONLY PURCHASED THE RIGHT TO USE IT.
  30. >>>ANYTHING WE SAY GOES...
  31.  
  32. >No not me.  I was the "someone else" the someone else you quoted quoted.
  33.  
  34. >>Not to give legal advice, but shrink-wrap licenses were recently discussed
  35. >>either here or on another forum. My feeling is that they are not enforceable
  36. >>as a license. There is no consideration to support the imposition of
  37. >>a license. (under the theory that old consideration is bad consideration).
  38.  
  39. >And we weren't talking about shrink-wrap for bitty boxes.  What we were
  40. >talking about is that no vendor of general purpose computers of any sort
  41. >stands behind the product as much as an auto manufacturer.  If the software
  42. >is broken, tough shit, you lose.  Buy an upgrade, which probably breaks lots
  43. >of things that work now.  You lose again.
  44.  
  45. Sorry - it wasn't clear to me, and I had been wrapped up in the 
  46. shrink wrap discussion.
  47.  
  48. >This has been said a lot better than I can.
  49.  
  50. >An extract from RISKS DIGEST 11.15 (21 Feb 91)
  51.  
  52. >> In RISKS 11.14 there were many responses along the lines of "If I pay
  53. >> good money to buy software, I expect it to work as it should."
  54. >>
  55. >> Brace yourself -- you didn't buy it.  You have licensed it.  If you check out
  56. >> all the fine print somewhere, you'll see that you have a limited license to
  57. >> use the software.
  58. >>
  59. >> Also, if you look in that same fine print, you are probably going to find a
  60. >> disclaimer of warranty that absolves your vendor of all liability, and that
  61. >> explicitly disclaims any warrant of mechantability or fitness for any purpose.
  62. >> I.e., the software may not do anything, but they aren't *legally* representing
  63. >> it as supposed to be doing anything!
  64. >>
  65. >> I don't think this is a proper way to do business, but it has become standard
  66. >> in the industry.  There have been some cases where such warranty disclaimers
  67. >> have been struck down in courts if the software failed to even boot up, but I
  68. >> have never heard of the provisions being struck down for something like the
  69. >> security bug leading to this discussion.
  70. >>
  71. >> In general, if you were to purchase a car or TV or any other major
  72. >> appliance, and in so doing had to sign a piece of paper that said
  73. >> (effectively):
  74. >>   "You are not really buying this, you are leasing it.  You can't sell
  75. >>    it or give it away without our permission, nor are you allowed to
  76. >>    take it apart to see how it works.  We don't promise that it does
  77. >>    anything in particular, despite what the salesman said.  If you try
  78. >>    to use it and it fails, we're not responsible for any damages of
  79. >>    any kind.  If really pressed, we'll exchange the item for a pile
  80. >>    of the raw materials we used to construct it, at no charge to you.
  81. >>    No other warranties are in effect on this item (except what may
  82. >>    be in your state law) no matter what the salesman says -- we
  83. >>    disavow any promises he made beyond this statement."
  84. >> would you buy it?  We do it with software all the time.....
  85. >>
  86. >> The problem has complex roots, beyond the scope of a short message
  87. >> here: intellectual property, software specification and testing, and
  88. >> poorly-informed consumers add to the problem.  We have cultivated a
  89. >> professional and commercial attitude that is really like only 2 other
  90. >> professions -- and they have state licensing imposed on them:
  91. >>    "I'm sorry, we did everything we could to treat the infection, but
  92. >>     he just didn't respond."
  93. >>    "I'm sorry -- we gave it our best shot, but the jury didn't
  94. >>     believe you."
  95. >>    "I'm sorry -- we used state-of-the art methods, but you know how
  96. >>     hard it is to find *every* bug."
  97. >>
  98. >> The bottom line: by current definition and tradition, your vendor is not
  99. >> really obliged to provide a fix unless you have a separate maintenance
  100. >> agreement.  Talk of a recall is "silly."  If you don't like it, you can
  101. >> always try to find another vendor to whom you take your business.
  102. >>
  103. >> Before any of you get too outraged by this, check carefully:
  104. >>   *  If you sell a computer product, what do *you* disclaim?
  105. >>   *  If you are a consumer, how many products have you bought
  106. >>      this way without complaint?
  107. >>   *  When have you conveniently blamed something on "the computer"?
  108.  
  109. >If I sold software, I'd do the same I suppose, but I don't and this stuff
  110. >really pisses me off.  The customer is really screwed because the vendors
  111. >are all alike.  The way I figure it, the first vendor that had any real
  112. >respect for quality would wipe out the rest like Japan wiped out Detroit.
  113. >But apparently no one in the industry sees it that way.
  114.  
  115. Well, the problem is that it is very hard to write software that doesn't
  116. fail (ever), especially at commercially reasonable prices. So - everyone
  117. is worried that they will get sued for the failure. This may be because
  118. software is inhearantly more complex than other forms of engineering
  119. (at least in my opinion). Ask yourself - how many parts does the averege
  120. appliance, etc. have? Not that many does it. Now - how about software?
  121.  
  122. Another problem is that the courts have yet to address the question
  123. of the normal level of care required in a software program. Is one 
  124. bug in a 1,000 lines of code inidicative of due care? How about 10
  125. or 100? How significant is the error? I'm here making it sound
  126. easier than it really is. More than just software metrics is required.
  127.  
  128. I am now an expert witness in a software case. My opinion is that the
  129. software is defective, and that due care was not used in its preparation.
  130. I think that this case is obvious. Many others are borderline. As a
  131. plaintiff's attorney, I would argue for a high standard of care. As
  132. a defense attorney, I would argue for a much lower standard.
  133.  
  134. Bruce E. Hayden
  135. (303) 758-8400
  136. bhayden@csn.org
  137.