| |||||||||||||
Software liability laws: a dangerous solutionSoftware liability laws: a dangerous solutionPosted Sep 8, 2007 10:53 UTC (Sat) by NAR (subscriber, #1313)In reply to: Software liability laws: a dangerous solution by giraffedata Parent article: Software liability laws: a dangerous solution So if the law removes the option, the buyer will have to pay the higher price to the seller. Who is that good for? In Hungary a couple of years ago cars with two stroke engines were effectively outlawed: basically the customer will have to pay a higher price for the four stroked cars. And actually it's good for the rest of us because it's better on the environment. Not selling flawed software to the clueless users is also good for the (virtual) environment, meaning less botnets, less spam, less DoS attacks, etc.
(Log in to post comments)
Software liability laws: a dangerous solution Posted Sep 9, 2007 1:47 UTC (Sun) by giraffedata (subscriber, #1954) [Link] Not selling flawed software to the clueless users is also good for the (virtual) environment, meaning less botnets, less spam, less DoS attacks, etc. OK, that's a good point and my argument may have wandered a little from the point. But I think it's still possible that putting the liability on the buyer does the job better. Hungary could have achieved the same thing by outlawing driving of new two-cycle cars, putting the regulation closer to the actual source of the problem. I've thought for a long time that the solution to the spam problem is to make people -- even bot hosts -- pay to send email. This would cause users to demand that their ISPs limit their ability to send mail and to invest in virus control measures. Or software without bugs, if that's how the viruses are getting in.
paying to send email Posted Sep 12, 2007 8:17 UTC (Wed) by copsewood (subscriber, #199) [Link] A good idea, but unfortunately very difficult to see it happen unless the existing email system collapses, assuming that Metcalfe's law holds.Nevertheless, I have written a paper and specified outline protocols for a payment system that might be of interest if the existing email system does collapse (or in connection with other mass applications for micropayments, assuming the preference for flat-rate communications costs becomes outweighed by the general desirability of being able to make larger numbers of smaller payments more flexibly.)
|
|||||||||||||