Slashdot Mirror

It is also worth noting that this decision is widely considered to have been incorrectly decided, according to every one of the dozen or so books on technology law I've read through. (The first one that comes to mind is Kaner&Fels' book on software law; couldn't find a link to the book but see Dr. Kaner's page for information.)

So no, there isn't a whole lot of case law on the books on this point, but as far as I can tell it is fairly controversial. (Personally, I think ProCD was decided incorrectly, too, but again, IANAL.)

One thing to remember about code is that "all errors are final errors". Case in point, I was working on a product and during testing the illustrious Cem Kaner himself (who was heading up testing, and who had not written The Big Book of Testing yet) instructed the testers to randomly modify bytes in the document files to make sure we handled the situation correctly. I was so annoyed, I added a dialog box when the corruption was detected:

"Document is corrupt. I recommend suicide."

The intent was to remove it after the testers saw it.

I didn't. It shipped. Customer saw it. Got yelled at.

Here is what I believe is the core issue in this discussion: as we practice software development today, protecting ourselves from software liability laws is a practical impossibility. If Software Lemon Laws existed, we'd probably all be out of a job, and/or software would very expensive to own. Plus, the Open Source movement as we know it would probably dry up.

Many of the posts in this discussion focus on the results of, or the viability of, Lemon Laws on the Open Source or the Closed Source software development industries. Futher, many posters have held out automobile manufacturing as a example, both to defend and assault the effects of liability laws on the software industry.

I submit that automobile manufacturing (or most any other manufacturing process) is orders of magnitude less complex than building significant software systems. So much so that I contend that it's currently next to impossible to know with 100% assurance that your software is correct (using current techniques and technologies). Software is too complex (or our testing software and techniques are too inadequate) to test to the point that we can be sure that we won't be sued, or that if we are sued our position is defensible. Also, given the current state of affairs in the liability law arena, if you can be sued, eventually you will be sued.

The beauty of manufacturing is that manufacturing, and the products produced, are constrained by physical laws. Parts fit together in specific ways, they exist in space, they take up room and they interact according to known physical (or chemical or nuclear) laws. Under these conditions it's "easy" (relatively speaking) to model an entire vehicle in software, or in engineering diagrams, before you ever start tooling a plant. Boeing's 777 was entirely built and tested in CAD/CAM before being manufactured.

How many "parts" are there in, say, a Ford SUV (including fasteners)? 25K? 50K? 100K? By today's software standards, this is a relatively simple system.

If we liken a line of code to a "part" in a vehicle (and by "parts" I would even include screws, nuts and washers), when was the last time that you ran across a significant piece of software (an OS, a word processor, a CAD/CAM system, a accounting package) that has less than 100K "parts" (aka, lines of code)? Most significant software, the kind that would require Lemon Law protection, is significantly larger than 100KLOC. But size is just the beginning of the problem.

When was the last time that you were able to model and test a 100KLOC (or 500KLOC or 1MLOC) software system before "manufacturing" it? A new car, or a new airplance, can be almost completely modeled and tested in virtual space before seeing the light of physical space. Not so for software systems, at least not ones that the average business can afford. (not that any software ever really "sees the light of physcial space," anyway ;-)

Additionally, software doesn't function just as the "parts" that are "manufactured." Some "parts" don't exist until the software is executed (i.e., files, objects and other data). So, how do you test something 100% (or at least to a level that makes your lawyers happy) that has 250K (or 500K or 1M) parts, when you can't touch those parts, or even anticipate 100% what all the parts will look like? If manufacturing worked this way (where parts are created and destroyed, modified and manipulated when the product is sent to the field), would Henry Ford ever have been able to create an assembly line. Likely not.

Add to this idea that 100% test coverage of every logical branch, and every permutation of data manipulation, approaches an N-Complete problem. Currently, problems that are N-Complete are considered intractable. As a problem approaches "N-Completeness," it also approaches insoluability (using current technologies). Though 100% testing is not a true N-Complete problem, it is one that is difficult to manage and address -- and doing so ain't cheap.

Finally, stir in the real X-Factor: our users (God bless 'em ;-). Developers: how many times have your users come to you and said "your software is broken," when, in reality, they were using the software for something that you'd never intended for it to do? Once, or twice, I'd guess. When this happened, who was "at fault?"

When software is "driven," unlike SUV's, it isn't constrained by physical laws. There's little risk in "trying something new." On the other hand, SUV drivers understand that "trying something new" (driving off a cliff, taking a corner at high speed, backing into a closed garage door, leaving the windows open during a rain storm, locking your kids inside in the heat of the day) normally has some obvious physical consequence. This is usually not the case for software (unless your software is controlling a CAT scanner... ;-).

With business software, users "try stuff," they get creative, they push the envelope. When you push the envelope in an SUV, it falls over. When a user pushes the envelope in an SUV and it tips over, who's liable? When a user "pushes the envelope" using software and the software "tips over," sending a gigabyte of data to data heaven, who's liable?

Our SUV driver, like every wheeled-vehicle user, is constrained by physical laws. We accept that it may be irresponsible for a driver to "push the envelope" in an SUV. The consequences are obvious and well known to all wheeled-vehicles users. If the consequences are not obvious to the driver at first, they become so quickly. Still, is Ford liable for someone dumping his Excursion into a ditch, even when the user exceeded the design parameters of the system? Not so much.

However, when a software user "pushes the envelope" the consequences are usually not rooted in physics. So, when an intrepid user tries something new, and flushes precious data down the bit-toilet, who's really at fault? The user? Or the "manufacturer" for not anticipating this particular use of the system? A number of a factors would affect assessing blame, and asessing blame could happen in court -- and court ain't cheap.

(Please note that man-rated systems like space shuttle and airliner avionics, nuclear power plant control systems, PET/CAT/MRI control software are, and must be, held to a higher standard than business software and much of what I'm saying doesn't apply there -- but that level of quality ain't cheap, either.)

We could build business software, today, that would better stand the challenges of Lemon Laws, but that would drive up the costs of development. However, would end-users really want to pay $5,000 for M$ Office so that they're assured that it's fully tested -- at least to the point that M$, and it's lawyers, believe they could withstand the assault of a nation full liability attorneys?

What about the Open Source software? Granted, in Open Source bugs are shallower due to the greater number of eyes-balls scrutinizing the code. However, would any of us be willing to spend the time needed to truly test software (peer reviews are effective, but only go so far) to ensure that it'd survive it's day in court? Not likely. Beside, as already noted, since Open Source software is essentially free (without cost), open source developers may not be liable in court.

So, where does this leave us?

To me it seems that Lemon Laws for software are a practical impossibility, at least using today's technologies and practices. Raising the quality bar for software such that it could survive litigation would significantly raise the cost of software itself, likely making software prohibitively expensive. Further, if such laws were enacted, in the current climate (sue! sue! sue!) there would be law-suits. Maybe lots of them. Such activity would sap profits from the industry in the form of legal defense costs. These profits would have to be replaced, further increasing the cost of software to the end-user.

As for Open Source software, as mentioned in other posts in this discussion, Open Source would probably not be liable (or at least "sue-able") under Software Lemon Laws. Hence, there would be little incentive to raise the quality bar sufficiently to protect against litigation.

If it were determined that the Open Source community is liable, since it's primarily a volunteer work force, the work force would dissipate out of fear of litigation. I don't know of too many Open Source developers who would be willing to lose their homes and cars to Software Lemon Law litigation.

The future may change this situation. Who knows? Hopefully, it will. Otoh..... maybe Lemon Laws would force us to get our feces in one sock.....

I was able to scrounge up a couple of references that speak to some of these issues, both for and against:

http://www.kaner.com/coverage.htm
http://www.bullseye.com/coverage.html
http://www.badsoftware.com/qindex.htm
http://www.bostonspin.org/slides/CemKaner.ppt (PowerPoint... sorry)

Some of these issues have been previously discuss here, at our beloved /.:

http://slashdot.org/developers/02/04/21/0058214.sh tml?tid=172

Finally, please note that I don't believe that Software Lemon Laws are inherently bad. What I believe is that they are currently bad for the industry. The industry would not likely withstand the costs associated with protecting itself against Lemon Laws. At least not yet. I remain hopeful that the picture will change in the future.

Thanks for listening... ;-)

P.S.: this is my first post at /., please be gentle... hehehe

The lawyer's website (and it's Cem, not Cern - silly C|Net reporter) contains some interesting links on UCITA, license "agreements", and other aspects of computer law. He also co-authored a very good book on software testing, Testing Computer Software.

Go look under "Computer Law" and read some of the papers there. He talks a lot about UCITA and the whole liability question. Actually, if you get a chance, go listen to him speak. Cem is a very entertaining and informative speaker.

Cem Kaner would also be a good person to bring in. He's a developer and a lawyer. He has web pages at http://www.kaner.com and http://www.badsoftware.com; the latter starts off with anti-UCITA information.