Culpatic programming
In the legal world, there is this latin term “culpa”, which translates roughly to “carelessness” or “neglience”. The term does not seem to be used in US Law, but I’m guessing a similar concept still exists in all Common Law countries (it might be worth mentioning to the casual Google refereant that this post is written based in my understanding of swedish law — if you’re in some other jurisdiction you should take this with an even larger grain of salt).
The concept of culpa, or rather careless behaviour, is very important when it comes to assessing whether a certain harmful action (or sometimes inaction) by a person should make that person liable for damages. The rules differ somewhat if the two parties were in a legal agreement of some kind, but basically — if you cause harmful effects, you’re generally worse off if it was due to carelessness than if it was by accident (”casus”).
For example, if a supplier did not deliver his goods to the customer at the agreed time and place, and this was harmful to the customer in some way, the supplier is more likely to be liable for damages if the reason for the failed delivery was due to him forgetting about it, as opposed to there being a unforeseeable traffic jam that prevented him from reaching the delivery place on time.
To determine wheter a particular action should be categorized as casus or culpa, a court need to have some sort of guideline as to what is generally considered to be careless in the context of the harmful action. In some cases (such as traffic, or working environments), there are rules that more or less spell out what is considered careless. In the absence of those rules, courts generally observe what level of carefulness that is considered adequate by those proficient in the profession or trade.
In the programming world, there’s a whole lot of “culpatic programming” going on — proficient developers know about appropriate steps to ensure at least some level of quality in their delivered products, ranging from design methologies to source code management to customer involvement to established QA techniques. They also know that these steps often are not followed — for whatever reason. The result is buggy software that cost time, money and sometimes lives.
Yet, the fact that many programs and systems are carelessly written ise rarely discussed — most of the time, it is observed that bugs will happen, a EULA or other agreement that absolves the company of liabilities due to bugs in the code is slapped on, and that’s the end of that.
While is true that it’s impossible (in any practical sense) to write bug-free programs, it is possible to make a meaningful distinction between bugs cased by carelessness (”culpa” bugs) and bugs cased by accident (”casus” bugs). The intented usage for the system will probably affect how the distinction is made (a off-by-one bug might well be determined to be a “casus” bug in a admin UI for a in-house CMS, but is probably a “culpa” bug in the firmware for a electronic pacemaker). This also means that software that, when written, is likely to capture a mass market (such as the RPC server in the next Windows version) could and should be held to a higher standard than software written on a hobby basis, when it comes to determine carelessness.
Often, when the issue of software liability is raised, the discussion is cut short by the observation that software will always have bug, and that some of them will cause disastrous effect. It’s also observed that there is a point in software development where the cost of finding and fixing the remaining bugs is larger than what the customers are prepared to pay, and if we make the law demand software developer liability, no programs (particularly open source ones) will get released. While it’s true, it’s a all-or-nothing argument. As a (semi-retired) developer, I’ve caused my fair share of bugs in my time. Many of these were casus bugs, but some were culpa bugs, bugs that I would not have created had I followed adequate development procedures. It’s the latter sort of bug I’m talking about — the ones that are technologically AND economically feasible to eliminate, but developers lack incentive to do so (other than pride of craftmanship).
One large problem is that very few are qualified to determine whether a bug is culpa or casus. Then again, very few are qualified to determine if a certain food handling procedure is adequate or neglient, or wheter a car’s failing braking system was carelessly designed or not. The legal system still demands that we make a destinction between culpa and casus in these cases, and does not allow the food or car industry to sell their products with attached general disclaimers that frees them from responsibility. Wheter enough care was taken is determined by experts in the respective fields. For the software case, this will mean letting independent parties review the code and particular the conditions of the bug. This will, in many cases, be expensive, but so are the problems that software bugs cause.
Tags: Juridik, programmering, skadeståndsrätt