“The Proposed Final Draft of the Principles of the Law of Software Contracts was approved, subject to the discussion at the meeting and to editorial prerogative. Approval of the draft clears the way for publication of the official text of this project.” (from a report to members on the actions taken this week at the American Law Institute’s annual meeting.)
I’ll talk more about these at CAST, this summer.
This document will influence court decisions across the United States. It is the counterbalance to the Uniform Computer Information Transactions Act, which vastly increased software seller’s powers, virtually wiped out customers’ abilities to hold companies accountable for bad software—UCITA passed in 2 states, then died because it was so widely seen as so unbalanced.
The main provisions of the Principles that affect us:
(1) Companies will be required to reveal known defects at time of sale
(2) Reverse engineering will be more legally defensible. People will now have ALMOST as much right to reverse engineer software, in the United States, as they have for every other kind of product in the US. This brings us closer to international standards, making our development efforts less uncompetitive compared to most other high-tech countries.
I helped write the Principles. I wish I could give you more details about the discussion at the meeting (and will be able to by CAST). Unfortunately, I got a nasty virus last week and could not travel.
One comment. Earlier in the week, there was a lot of baloney on the web about a carefully timed letter from Microsoft and the Linux Foundation that (a) pleaded for delay because they said they needed more time to review the draft and (b) said that the disclosure requirements were very new and onerous.
Actually, the community has been aware of proposals for disclosure since 1995, when Ed Foster published widely-read articles on UCITA (then called Article 2B) in Infoworld, which were followed up by a lot of mass-media attention. There have been several follow-up reports to our community (software development, software testing) since then, including talks that I’ve given at previous CAST meetings.
In terms of awareness by LAWYERS, Microsoft has been involved in the drafting process for UCITA and the ALI Principles for longer than I have (I stated working on this in 1995; I think they started in 1989). The Open Source communities have been more variable in their activism on these laws, but several attorneys within that community have been active. More to the point, the Principles specifically exempts open source software from the disclosure rule because the distribution models (and availability of code) are so different from traditional proprietary software. The MS/Open Linux letter also complained that the ALI is treating all software transfer as if it were packaged software. This is a criticism that was applied to early drafts of UCITA (which Microsoft, Apple and IBM played heavy roles in writing) but that was pretty cleared up before UCITA was introduced to state legislatures in 2001. The ALI Principles were started after that, well after everyone in the process understood the variety of distribution models for software. Letters like this make good copy on slashdot and in blogs where authors don’t know much about the law or history of the work they’re blogging about, but as serious criticisms, they seem devoid of merit.
>>>Companies will be required to reveal known defects at time of sale
Cem, I would be interested to know how this statement and several others in Law of software contracts, applies to IT services (application development and testing for IT shops) and outsourced software services delivered from countries like india ….
If the contract is created in the United States, then American law probably governs disputes arising out of the contract. If the contract is created in India, Indian law probably governs. The contract itself can specify which law governs. If both parties are businesses, most courts will honor the choice of law.
— Cem
What does this mean to software? What sort of obligations are proposed to be imposed on software testing service providers?
I haven’t spent much time reviewing the principles in terms of how they change the law as it applies to pure services. I don’t think there are many changes. You might want your lawyer to review it. The current draft is at http://www.ali.org/index.cfm?fuseaction=publications.ppage&node_id=121.
— Cem
Shrini
knowing nothing about the details of this law or law in general, what is to prevent a company from killing its testing activities, cut documented bug reporting, and generally inventing creative ways for plausible deniability and such in order to minimize the amount of “known bugs” at the time of sale.
Many engineers express this fear. There are three fallacies:
(1) It is fundamentally self-destructive for the company. If the company actually cuts testing to avoid knowledge, it will end up with a lot more bugs and will have serious problems in the marketplace. If the company doesn’t cut testing, learns the problems but chooses not to document them, some of its staff will end up as witnesses, testifying that the bugs were found and covered up. This would create enormous liability to the company.
(2) Even if the company doesn’t know about a bug at time of release of the product, people will call the company to complain about it. After you hear reports enough times, you know there’s a problem. The question of how much time you should have to verify a customer report and prepare a description for customers is going to have to be resolved on a case-by-case basis, but this is a relatively straightforward issue for judges and lawyers to deal with. Therefore, the ignorance defense expires, no matter what the publisher does to try to maintain its ignorance.
(3) If the company discloses the bug, the bug becomes a feature. Maybe not the world’s most popular feature, but from a liability perspective, if we say that the program will erase the hard disk if you do X, then we can’t be sued if that happens. Thus many companies will decide that they have a strong incentive to make a clear disclosure.
Basically, the system makes honest practice cheaper and safer than trying to beat the system.
— Cem Kaner
(3)
I had a recent discussion with a developing manager about a software used in house that performs analysis software and reports provided to physicians (part of our customer base). When a known bug is not disclosed to physicians that affects the reports, does this type of situation fall into the same type as commercial software? A service is conducted and monies are exchanged based on the software’s analysis, so I would think known problems must be disclosed based on your presentation at CAST and here on your blog. Or are services based on data analysis software excluded?
You don’t actually give me enough information to answer your question. Depending on who (what human) is doing the analysis, serious weaknesses in the service provided might constitute malpractice (e.g. medical malpractice). In addition, much of the software relied on by physicians is regulated by the Food and Drug Administration (in the US; comparable agencies elsewhere) and failure to disclose a serious known defect might be a crime.
— Cem
Hi Cem,
Thanks for sharing this information! Might you share more about the repercussions of this law? Namely:
1) How might this law be leveraged against software companies? What kind of lawsuits might be brought, and upon what might the ruling be based?
2) How would companies be able to defend themselves from competition studying their ‘known defects’, and using this knowledge as a counter-selling-point?
3) Must companies declare every little jot and tittle known defect, or only known issues that may hamper ‘happy path’ core product functionality (e.g. what if there is a spelling error, or a color scheme on a page that is obviously an error, but which will not be fixed in a current release. Must a company publish this?)?
4) What about integrations? Perhaps a companies product works fine on Oracle, but if you connect it with mySQL, there are issues. The issues aren’t really with the product, but with what the product is pushed together with (e.g. mySQL). Would these be issues that would have to be documented? If so, I would assume that software companies would probably market their product as only integrating with with one other product (in this case Oracle), but would give their sales people cart blanch to sell into other integrations. Would there be anything to prohibit such a tact?
It seems the implication of this kind of law will be huge! I’m finding it hard to wrap my mind around the headaches and the opportunities that such a law might provide.
Thanks,
†jds
The easiest way for a company to deal with its known bugs — if it can’t live with the idea that the public might hear about them or the competitors might bash the company for having them — is to fix them. This rule is a marketplace-oriented incentive for companies to fix their serious bugs.
The alternative–widely discussed in consumer protection circles and very seriously considered by several states’ Attorneys-General (and what WILL be done if this doesn’t have a positive effect over the next 10 years)–is to hold companies accountable for damage caused by serious errors whether the company knew the error existed or not. That is, software might be made subject to the same laws governing all other products, instead of the much gentler treatment it’s getting today.
The competitor who uses your known bugs against you is playing an interesting game. If their product is actually more stable, you deserve what you get from your competitor. On the other hand, if their product is buggy too, you get to compete the same way.
The impact of this type of competitive advertising is that you will eventually fix those bugs that cause the most pain in the marketplace–as will your competitor.
A company doesn’t have to disclose any bugs. It can disclose none, some, or all. The consequence of not disclosing a known bug is that a customer who suffers losses that are caused by an undisclosed-but-known bug will be able to recover the losses. If a spelling mistake doesn’t cause losses, there is no liability-related risk in not disclosing it.
As to your final question, a company whose agents misrepresent the company’s products is liable for the misrepresentations by the agents. That’s been true for a long time (like, centuries) and it will be true for a long time to come.
The foundation of a free market is information. If buyers and sellers have sufficient knowledge, they can make rational deals. To the extent that information is hidden from one side by the other, the deals will probably be unfair.
Sympathy for this proposal increased tremendously in the late 1990’s as some very large companies attempted to block customers and journalists from disclosing bugs they found in the normal use of the product and from writing blogs or articles about the software that contained benchmark comparisons, bug reports or criticisms. The companies argued that they had the right to put any conditions they wanted into their contracts, including bans on all types of disclosure.
I see disclosure rules sometimes attacked by pseudo-Libertarians on the grounds that forcing a company to disclose information is evilly regulatory. On the other hand, it is just as regulatory for a government to enforce clauses in contracts. The power of The State comes into play in both cases. The State has only recently created intellectual property rights in software (probably, after you were born) and even more recently begun to enforce no-reverse-engineering clauses in contracts. If you want the State to give your company some powers (like IP rights) for dealing with customers and competitors, don’t complain that the State is also giving your customers and competitors some power against you.
— Cem