<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Principles of the Law of Software Contracts approved</title>
	<atom:link href="http://www.satisfice.com/kaner/?feed=rss2&#038;p=48" rel="self" type="application/rss+xml" />
	<link>http://www.satisfice.com/kaner/?p=48</link>
	<description>On the craft and community of software testing</description>
	<pubDate>Thu, 09 Sep 2010 01:29:17 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: John Shaw</title>
		<link>http://www.satisfice.com/kaner/?p=48&cpage=1#comment-50445</link>
		<dc:creator>John Shaw</dc:creator>
		<pubDate>Mon, 26 Oct 2009 14:53:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.satisfice.com/kaner/?p=48#comment-50445</guid>
		<description>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

&lt;em&gt;&lt;strong&gt;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&lt;/strong&gt;&lt;/em&gt;</description>
		<content:encoded><![CDATA[<p>Hi Cem, </p>
<p>Thanks for sharing this information! Might you share more about the repercussions of this law? Namely: </p>
<p>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?</p>
<p>2) How would companies be able to defend themselves from competition studying their &#8216;known defects&#8217;, and using this knowledge as a counter-selling-point?</p>
<p>3) Must companies declare every little jot and tittle known defect, or only known issues that may hamper &#8216;happy path&#8217; 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?)? </p>
<p>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&#8217;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?</p>
<p>It seems the implication of this kind of law will be huge! I&#8217;m finding it hard to wrap my mind around the headaches and the opportunities that such a law might provide.</p>
<p>Thanks,</p>
<p>†jds</p>
<p><em><strong>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.</p>
<p>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.<br />
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.<br />
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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.<br />
&#8211; Cem</strong></em></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jean Ann Harrison</title>
		<link>http://www.satisfice.com/kaner/?p=48&cpage=1#comment-50214</link>
		<dc:creator>Jean Ann Harrison</dc:creator>
		<pubDate>Thu, 22 Oct 2009 16:30:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.satisfice.com/kaner/?p=48#comment-50214</guid>
		<description>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?

&lt;strong&gt;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&lt;/strong&gt;&lt;em&gt;</description>
		<content:encoded><![CDATA[<p>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&#8217;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?</p>
<p><strong>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.</p>
<p>&#8211; Cem</strong><em></em></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Öge</title>
		<link>http://www.satisfice.com/kaner/?p=48&cpage=1#comment-47073</link>
		<dc:creator>Öge</dc:creator>
		<pubDate>Wed, 24 Jun 2009 06:30:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.satisfice.com/kaner/?p=48#comment-47073</guid>
		<description>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.

&lt;strong&gt;&lt;em&gt;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&lt;/strong&gt;&lt;/em&gt;

(3) 
</description>
		<content:encoded><![CDATA[<p>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 &#8220;known bugs&#8221; at the time of sale.</p>
<p><strong><em>Many engineers express this fear. There are three fallacies:</p>
<p>(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&#8217;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.</p>
<p>(2) Even if the company doesn&#8217;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&#8217;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.</p>
<p>(3) If the company discloses the bug, the bug becomes a feature. Maybe not the world&#8217;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&#8217;t be sued if that happens. Thus many companies will decide that they have a strong incentive to make a clear disclosure.</p>
<p>Basically, the system makes honest practice cheaper and safer than trying to beat the system.</p>
<p>&#8211; Cem Kaner</em></strong></p>
<p>(3)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shrini Kulkarni</title>
		<link>http://www.satisfice.com/kaner/?p=48&cpage=1#comment-46443</link>
		<dc:creator>Shrini Kulkarni</dc:creator>
		<pubDate>Fri, 22 May 2009 02:54:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.satisfice.com/kaner/?p=48#comment-46443</guid>
		<description>&gt;&gt;&gt;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 ....

&lt;em&gt;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&lt;/em&gt;

What does this mean to software? What sort of obligations are proposed to be imposed on software testing service providers?

&lt;em&gt;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&#038;node_id=121.

-- Cem&lt;/em&gt;

Shrini</description>
		<content:encoded><![CDATA[<p>>>>Companies will be required to reveal known defects at time of sale</p>
<p>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 &#8230;.</p>
<p><em>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.</p>
<p>&#8211; Cem</em></p>
<p>What does this mean to software? What sort of obligations are proposed to be imposed on software testing service providers?</p>
<p><em>I haven&#8217;t spent much time reviewing the principles in terms of how they change the law as it applies to pure services. I don&#8217;t think there are many changes. You might want your lawyer to review it. The current draft is at <a href="http://www.ali.org/index.cfm?fuseaction=publications.ppage&#038;node_id=121" rel="nofollow">http://www.ali.org/index.cfm?fuseaction=publications.ppage&#038;node_id=121</a>.</p>
<p>&#8211; Cem</em></p>
<p>Shrini</p>
]]></content:encoded>
	</item>
</channel>
</rss>


