How to Deal with the Quality Dispute in the Software Development Contract

Author: Zhong Yi, Michael Ni [Shanghai Runhe Law Firm]

1.   Brief Introduction to the First Instance

The plaintiff and the defendant entered into an contract providing that both parties collaboratively develop a set of software whose support of creation and art crafts, and manufacture and sales, etc. is provided by the plaintiff and the defendant shall be responsible for development and script plan of the programme; the copyright of the product belongs to the defendant; the price of the Contract was paid separately by procedure like down payment, test and etc.; after the product is on the market for 30 days and if no quality issues which arouse return of goods, the rest payment will be made by the defendant, or the payment will be offset for the losses of goods; the copyright will be transferred to the plaintiff if the defendant is late for make payment. After the plaintiff delivered the developed software to the defendant, the defendant made it published by publisher for sale in the market under the condition that the software hasn't been accepted in a formal way.  During the procedure of sales, the plaintiff provided supplemental "Q&A of Installation" and "Software Patches" which are sold together with the software by the request of the defendant. After that, the defendant refused to make the rest payment on the grounds that the software has quality issue for which the plaintiff filed the case to the court requesting the defendant to pay the rest payment for developing the software.

The Court of the first instance held that in the field of software development, after the development is over and the delivery of the software, there is still possibility for revision. The defendant shall have the foresight of the consequence for publishing the software without acceptance. The defendant ignored the acceptance for putting the software into market as soon as possible and delivered to third party for pulishing without acceptance. Meanwhile, the "Q&A of Installation" and "Software Patches" are sold to customers as a part of the product delivered by the plaintiff, which shows the recognition of the defendant to the quality of the software development.  Under such condition, that the defendant failed to pay the plaintiff for the software development is a breach of contract for inappropriate performance of the obligation and the defendant shall bear all the liabilities.

Hereby, the court of the first instance decided for the plaintiff.

2.  Brief Introduction to the Second Instance

The defendant of the first instance appealed against the judgment of the first instance.

The appellant (the defendant of the first instance) alleged that 1) the appellant found two defects of the software involved after tests before the software was published into the market. The software was still sold for the avoidance of enlarging the losses; 2) the two tests failed to be made due to the reason that the appellee finished the programme design at the night before the date of delivery; 3) the investigation time of the first instance didn't reach the time of the breakdown, which makes the investigation conclusion unable to reflect the issues of the software.  4) it is the performance of counterargument right for security that the appellant failed to pay the rest amount to the appellee in accordance with the contract; therefore, the appellant asks the court to revoke the judgment of the first instance, remand a lawsuit for a new trial or render a new judgment according to law.

The appellee (the plaintiff of the first instance) argued that the facts were clearly ascertained and the evidences were sufficient. The law applied was correct, and the appellee requests the Court to affirm the judgment of the first instance.

The court of the second instance held that the basic facts ascertained by the court of first instance were clear. The law applied was correct and the procedure was legal.

According to the general condition of software development, the software needs to be continually revised and optimized after the development is over. That the software involved in the case has defects doesn't consequentially mean the software has quality issues. Whether the engineering of software development has quality issues shall be subject to the technical standard agreed in the contract.  The contract of this case failed to clarify the technical standard, time of investigation, method of the software development. Therefore, the real declaration of intention and the legal liability of both parties to the contract shall be determined by the extent of actual performance and consequence of both parties.  Concerning the reasons that the appellant declared such as the developer breached the contract first for the software has series quality issues and as a result, the appellant is entitled to perform the counterargument right for security for not paying the rest payment. The court of the second instance held that the appellant has no evidence to prove the appellee breaches the contract regarding the software quality issues before the publishing of the developed software and actually recognized the quality of the developed software. Therefore, it shall be deemed as both parties has reached an contract on the quality of the developed software.

Hereby, the court of the second instance dismissed the appeal and sustained the original judgment.

3.  Comments on the Case

(a) the defects of software doesn't necessarily mean the right owner has raised quality objection

Our opinion on the relationship between whether the software has quality defects and raising the quality objection are as follows:

Whether the software has quality problem is substantial issue, whose point is the delivery (quality) standard agreed in the contract; whether the right owner raises quality objection belongs to procedural issue, whose point whether the right owner has the evidence to prove that he/it has performed the notification obligation;

If the delivery (quality) standard is not clearly agreed in the contract and entrusting party has no evidence to prove he/it has raised quality objection,

Under such condition, that the entrusting party accepts the software developed by the developer is deemed as there is no objection to the delivery (quality) standard of the developed software.

(b) that the software has defects doesn't mean it has quality issues

The court of the first and second instance both held that according the general condition of software development, software needs continually revision after the development is finished. Whether the engineering of software development has quality issues shall be subject to the technical standard agreed by the contract.

In accordance with Contract Law of the People's Republic of China (hereinafter "Contract Law"):

“Article61 For a contract that has become valid, where the parties have not stipulated the contents regarding quality, price or remuneration or the place of performance, or have stipulated them unclearly, the parties may supplement them by agreement; if they are unable to reach a supplementary agreement, the problem shall be determined in accordance with the related clauses of the contract or with trade practices.

Article 62 Where the parties have unclearly stipulated related contents in a contract and fails to determine them in accordance with the provisions of Article 61 of this Law, the following provisions shall apply:

（1）     in case of unclear quality requirements, the contract shall be performed in accordance with State standards or trade standards, or in the absence of such standards, in accordance with common standards or special standards conforming to the aim of the contract."

In our view, if the delivery (quality) standard of software development is not clearly agreed in the contract and no national standard, industrial standard or other general standard could be applied, there might be the risk of losing the case although the entrusting party has evidence proving that he/it has already raised quality objection.

（c） that the software has defects doesn't consequentially mean the right owner can refuse to pay the rest payment

It is quite common that the right owners refuse to make rest payment for the developed software has defects. In our opinion,

If both parties agree to offset the rest payment for software development by the losses aroused by the defects of the software (or penalty), it is appropriate.

If both parties can not reach an contract, there might be legal risks if the entrusting party unilaterally refuses to make the rest payment for the defects of software development (take this case as example, if the developer of the software ask for the rest payments as well as the penalty or overdue fine, the entrusting party will bear extra payments after losing the case).  Under such condition, if the developer of the software raise a lawsuit asking for the rest payments, the entrusting party can contradict by quality defects; if the developer of the software does not file a lawsuit, we suggest the entrusting party positively raising a lawsuit asking the developer to bear the liability of breaching the contract,  i.e., the burden of prove belongs to the entrusting party to show the software has drawbacks or quality defects in quality disputes concerning the software development contract. Such legal uncertainty can be solved by litigation (quality dispute), which obviously is favourable to the entrusting party.

（d） whether the rest payments can be refused by performing counterargument right for security if the software has defects

According to Article 66 of the Contract Law, "Where the parties are in debt to each other and there is no time order for discharging the debts, they shall meet their respective liabilities simultaneously. Either party has the right to reject the other party's demand for the discharge before the latter meets its own liabilities. Either party has the right to reject the other party's demand for the discharge if the latter fails to meet its liabilities as contracted.

In this case, the liability of the entrusting party is making the payments of software development and the liability of the developer is to deliver the developed software; after the entrusting party accepts the delivered software by the developer, counterargument right for security becomes inappropriate.  While software having defects (quality dispute) belongs to the scope whether the subject matter of the contract that the developer delivered conforms to the agreed standard, except that the contract expressly agreed that "the delivered software shall conform to some standard and shall acquire the acceptance report issued by third party. The entrusting party shall pay within 5 days upon the receipt of the acceptance report" and other expression like that. Quality Dispute of software product is generally inappropriate to apply counterargument right for security.

(The above comments is only for your reference! June 7, 2010)