Warranty software in the English-speaking contract (Part 1)
I am a lawyer of an IT company that develops mobile applications and is based in the CIS, and by the nature of its activities it is closely connected with the process of signing contracts with customers who, lately, more and more often choose not to agree with the terms of our “sample contract”. And now the next British Customer requires a review of the guarantee obligations that we usually offer. For the convenience of the customer, English law is chosen by the applicable law, which implies certain difficulties in agreeing on such complex conditions as guarantees.
The Customer’s natural desire is to protect himself from risks as much as possible, and the sales manager is so persistent, demanding not to waste time on all the legal subtleties - he doesn’t want to lose a good client and sign the contract “yesterday”, as usual.
At first, there is a desire to give all guarantees to the Customer, and thereby preserve a good client and friendly relations with the manager. Our team works efficiently and on time, and problems with customers arise mainly on cosmetic issues. But does this mean that we are ready for unlimited guarantees?
')
I am sure that neither we nor any other domestic development company is ready. And if the main task of a lawyer is to recognize and level out legal risks, then I should think about what guarantees we can offer to the Customer, and which ones to leave behind.
After a little research, I want to share my conclusions about this:
First, a little theory:
“What is a guarantee in British IT law?”
Warranty is a contractual obligation. This term is typical of the laws of the countries of the common law system. Through the warranty, one of the counterparties ensures that a certain fact of reality or fact that will take place in the future is true.
To the generally accepted guarantees include:
Warranty of Function - warranty;
Warranty of title is a guarantee on the purity of the title to the transfer of ownership of the product (the developer has the right to provide such a service);
Infringement Warranty - a guarantee that no copyright infringements are made during the development process;
Warranty of merchantability - a guarantee of product suitability for use;
Warranty of fitness for a specific purpose - “Customer’s goals will be achieved”;
Warranty as to Capacity - a guarantee that the developer is authorized to sign legal documents;
Warranties as to Viruses and Disabling Code - a guarantee of viral security of the product;
Warranty of Compatibility is a guarantee of the compatibility of the hardware of the parties.
At the same time among the general guarantees in a special group can be distinguished "implied warranties" ( Implied Warranties ), which are automatically part of software development contracts. If you do not explicitly exclude the validity of these guarantees, then they will apply to legal relations within the framework of this contract. Implied Warranties, for example, include: 1) Warranty of Title, 2) Infringement Warranty, 3) Warranty of Merchantability, 4) Warranty of fitness for a specific Purpose.
It is worth noting that the parties may provide any other guarantees in the contract in order to achieve specific goals that may be relevant only in a particular situation. Their content must accurately reflect the true intent of the parties and the nature of the guarantee.
It's time to move from theory to practice. In the future, I will talk more about all types of guarantees, and I propose to start with the most popular: Warranty of Function . In my case, there was no disagreement with the Customer regarding this guarantee, but I propose to treat it carefully and disassemble a few formulations.
Examples of successful formulations:
1. "Provision of warrants during the year
2. “Provide warrants for each of the 180 days after installation,” he said.
Guarantee of software operation means that the software will function (at least during the warranty period) according to the technical specification, which is an integral part of any development process. The main task of the developer in formulating such a guarantee is to accurately determine the correctness of the working capacity and the list of documents that describe this very operation.
The formulation in the Successful Example No. 1 successfully coped with this task. This example is also successful in using the term “ materially ”. This term protects the software developer from the risks associated with problems and obligations arising from the identification of minor (cosmetic) defects by the Customer. Naturally, it is worth taking seriously the drafting of a technical specification regarding the writing of the functional, since A good example, No. 1, trusts the specifications and presumes that it is of high quality and reflects the actual intentions of the parties.
A good example number 2 goes even further and uses the conditional label " Official Product Documentation ", which is affixed to the necessary documentation and combines the package of all documents related to the product. It is worth noting that this measure is an excellent example of systematization of project workflow. A good example number 2 is also notable for its preventive construction “ substantial conformance is a significant correspondence”. Indeed, we cannot be sure that the product will function ideally in accordance with the project documentation upon the completion of development. The goal of this design is to add flexibility to the overall performance guarantee.
In practice, you can meet with such unfortunate formulations as:
• “Provider represents and warrants that the software will be in good working order” - What in this case is “good working order” and how is it described? Such a formulation is too vague and, by its uncertainty, carries with it a heap of risks of claims on the part of the Customer.
• “ Provide according to its documentation” - What is meant by “Software documentation” ? By “Software documentation” you can understand an unlimited number of documents that are associated with the product development process. But what will happen if we include here and correspondence with sales managers or business analysts? The letter, including electronic, is a document and refers to the product. But do we need the software to function in accordance with the provisions outlined in the correspondence? I think not, because we are not so serious about writing a letter, like, for example, the drafting of a technical specification. In the letter, you can promise a lot or underestimate something, and then you have to prove that the specification has more legal force than a letter. After all, it is unlikely that someone includes letters in the hierarchy of project documentation and prescribes rules of priority for letters.
A performance guarantee can also be addressed to specific requirements that are written in its context. For example: "Provider warrants when they are installed
Conclusion:
So, we have considered one of the most important guarantees of the developer, but there are a number of guarantees, which also need to be treated carefully and carefully.
This guarantee is definitely worth including in the contract, since the Customer is unlikely to sign a contract, not being sure that the software will work and will work in the future or at least he will have a legal remedy in case of failure. At the same time, it is worth limiting the warranty periods (for example, “the first 180 days after installation”), because you do not want to have an indefinite headache for a product that was developed in the past decade and has long been forgotten by everyone.
If it is interesting, then I can answer questions on the features of other types of guarantees and how to correctly exclude the validity of implied guarantees.
The Customer’s natural desire is to protect himself from risks as much as possible, and the sales manager is so persistent, demanding not to waste time on all the legal subtleties - he doesn’t want to lose a good client and sign the contract “yesterday”, as usual.
At first, there is a desire to give all guarantees to the Customer, and thereby preserve a good client and friendly relations with the manager. Our team works efficiently and on time, and problems with customers arise mainly on cosmetic issues. But does this mean that we are ready for unlimited guarantees?
')
I am sure that neither we nor any other domestic development company is ready. And if the main task of a lawyer is to recognize and level out legal risks, then I should think about what guarantees we can offer to the Customer, and which ones to leave behind.
After a little research, I want to share my conclusions about this:
First, a little theory:
“What is a guarantee in British IT law?”
Warranty is a contractual obligation. This term is typical of the laws of the countries of the common law system. Through the warranty, one of the counterparties ensures that a certain fact of reality or fact that will take place in the future is true.
To the generally accepted guarantees include:
Warranty of Function - warranty;
Warranty of title is a guarantee on the purity of the title to the transfer of ownership of the product (the developer has the right to provide such a service);
Infringement Warranty - a guarantee that no copyright infringements are made during the development process;
Warranty of merchantability - a guarantee of product suitability for use;
Warranty of fitness for a specific purpose - “Customer’s goals will be achieved”;
Warranty as to Capacity - a guarantee that the developer is authorized to sign legal documents;
Warranties as to Viruses and Disabling Code - a guarantee of viral security of the product;
Warranty of Compatibility is a guarantee of the compatibility of the hardware of the parties.
At the same time among the general guarantees in a special group can be distinguished "implied warranties" ( Implied Warranties ), which are automatically part of software development contracts. If you do not explicitly exclude the validity of these guarantees, then they will apply to legal relations within the framework of this contract. Implied Warranties, for example, include: 1) Warranty of Title, 2) Infringement Warranty, 3) Warranty of Merchantability, 4) Warranty of fitness for a specific Purpose.
It is worth noting that the parties may provide any other guarantees in the contract in order to achieve specific goals that may be relevant only in a particular situation. Their content must accurately reflect the true intent of the parties and the nature of the guarantee.
It's time to move from theory to practice. In the future, I will talk more about all types of guarantees, and I propose to start with the most popular: Warranty of Function . In my case, there was no disagreement with the Customer regarding this guarantee, but I propose to treat it carefully and disassemble a few formulations.
Examples of successful formulations:
1. "Provision of warrants during the year
2. “Provide warrants for each of the 180 days after installation,” he said.
Guarantee of software operation means that the software will function (at least during the warranty period) according to the technical specification, which is an integral part of any development process. The main task of the developer in formulating such a guarantee is to accurately determine the correctness of the working capacity and the list of documents that describe this very operation.
The formulation in the Successful Example No. 1 successfully coped with this task. This example is also successful in using the term “ materially ”. This term protects the software developer from the risks associated with problems and obligations arising from the identification of minor (cosmetic) defects by the Customer. Naturally, it is worth taking seriously the drafting of a technical specification regarding the writing of the functional, since A good example, No. 1, trusts the specifications and presumes that it is of high quality and reflects the actual intentions of the parties.
A good example number 2 goes even further and uses the conditional label " Official Product Documentation ", which is affixed to the necessary documentation and combines the package of all documents related to the product. It is worth noting that this measure is an excellent example of systematization of project workflow. A good example number 2 is also notable for its preventive construction “ substantial conformance is a significant correspondence”. Indeed, we cannot be sure that the product will function ideally in accordance with the project documentation upon the completion of development. The goal of this design is to add flexibility to the overall performance guarantee.
In practice, you can meet with such unfortunate formulations as:
• “Provider represents and warrants that the software will be in good working order” - What in this case is “good working order” and how is it described? Such a formulation is too vague and, by its uncertainty, carries with it a heap of risks of claims on the part of the Customer.
• “ Provide according to its documentation” - What is meant by “Software documentation” ? By “Software documentation” you can understand an unlimited number of documents that are associated with the product development process. But what will happen if we include here and correspondence with sales managers or business analysts? The letter, including electronic, is a document and refers to the product. But do we need the software to function in accordance with the provisions outlined in the correspondence? I think not, because we are not so serious about writing a letter, like, for example, the drafting of a technical specification. In the letter, you can promise a lot or underestimate something, and then you have to prove that the specification has more legal force than a letter. After all, it is unlikely that someone includes letters in the hierarchy of project documentation and prescribes rules of priority for letters.
A performance guarantee can also be addressed to specific requirements that are written in its context. For example: "Provider warrants when they are installed
Conclusion:
So, we have considered one of the most important guarantees of the developer, but there are a number of guarantees, which also need to be treated carefully and carefully.
This guarantee is definitely worth including in the contract, since the Customer is unlikely to sign a contract, not being sure that the software will work and will work in the future or at least he will have a legal remedy in case of failure. At the same time, it is worth limiting the warranty periods (for example, “the first 180 days after installation”), because you do not want to have an indefinite headache for a product that was developed in the past decade and has long been forgotten by everyone.
If it is interesting, then I can answer questions on the features of other types of guarantees and how to correctly exclude the validity of implied guarantees.
Source: https://habr.com/ru/post/134007/
All Articles