In practice, we still often encounter requirements for the longest possible guarantee for purchased or developed software. However, such guarantee may not always be sufficient. There is also a more appropriate legal concept for a client buying software to ensure its flawless functionality, proper maintenance, further development, etc. Let’s compare the possible options and the software servicing modes already commonly used on the market.
When our clients have a major software implemented within their company, they often ask the supplier to provide the longest possible guarantee for the software (in the Czech legal system, this means a guarantee for the quality of the software delivered). This requirement may be raised, of course; however, if not correctly captured in the agreement in question, it may be practically useless.
We believe the client should rather enter into a service level agreement with the supplier, which can cover both defect removal and other necessary activities to ensure the longest possible life cycle.
As we often receive questions about the pros and cons of the different legal modes, we briefly describe them below, compare them and refer to some of the market standards that are now commonly used.
Statutory Liability for Defects
General liability for software defects is implied by the Civil Code. For this purpose, no additional guarantee needs to be negotiated with the supplier.
However, this general liability only applies to defects that the software had at the time of the “transfer of the risk of damage”, which usually occurs at the moment the software is handed over after the implementation has been completed.
A defect, within the meaning of the statutory regulation, is primarily a non-conformity of the software with its agreed specification, which is not the same as general non-functionality of the software caused by various factors, including those for which the supplier is not liable.
In general, defects must be reported to the supplier without undue delay after their discovery, but no later than six months or two years of software delivery, depending on the specific type of contract.
The scope of rights ensuing from a defective performance always depends on the specific contractual type and the nature of the breach (material/non-material). In relation to software, this will most often involve the removal of a defect or, alternatively, the provision of a reasonable discount on the fee.
In the case of non-standard and serious breaches, the client may be entitled to withdraw from the agreement (and to be refunded for part of the fee paid). It is also important to note that unless otherwise agreed, the defect is to be remedied within an unspecific “reasonable time limit”.
Quality Guarantee
A quality guarantee is not automatically provided by law for software, so if you want it, it must be expressly provided for in your contract.
The scope of the quality guarantee and the rights arising from it can be contractually modified in various ways. For example, the guarantee can only be provided for a certain part of the software, its validity can be conditioned by various obligations, or the rights arising from the guarantee can be limited in various ways. It is therefore always important to pay attention to the specific wording of the quality guarantee and the related warranty conditions.
In general, however, unlike the liability for defects described above, the quality guarantee is also able to cover defects that occur in the software during the agreed warranty period (i.e. not only at the time of the transfer of risk / handover of the software).
In this case, defects must also be reported without undue delay after their discovery, by the end of the warranty period at the latest.
Unless otherwise agreed, prompt remedy of the reported defect is not guaranteed in any way even if a quality guarantee has been provided. Again, under the statutory regulation, defects are to be remedied within an unspecified “reasonable time limit”.
Crucially, however, even the quality guarantee generally does not cover software “defects” caused by end-user activity, nor does it cover any regular updates, legislative updates, etc. A quality guarantee is generally only intended to ensure that the software in question retains its features for the duration of the warranty period and conforms to the related specification.
Since the software does not “spoil” over time, the quality guarantee is often an empty phrase without any practical benefit for the client. Malfunctions of software are often caused by incorrect use, its obsolescence, incompatibility of its interface to connected software or datasets that are subject to further development. Therefore, software should be “cared for” instead, meaning that it should be regularly updated, optimised, adapted to legislative updates, etc., to ensure longer flawless functionality for the client.
Service Level Agreement
The best way to ensure proper operation, maintenance, and the longest possible life cycle of the software is, in our view, to enter into a service level agreement, ideally directly with the supplier of the given software (however, it is not excluded that the support may be provided by an entity different from the entity that developed or implemented the software).
The advantages of a service level agreement over previous schemes are mainly the following:
- The term “incident”, which is a broader term than a mere “defect” within the meaning of statutory regulations, can be clearly defined and categorised according to the severity.
- A suitable range of flat-rate services, i.e the basic service framework, can be agreed in return for a lump-sum fee.
- On-demand services such further development, training, consulting and other software modifications, can be provided, usually on more favourable terms than without a service level agreement.
- Binding SLA criteria (the level of service provided) can be agreed; their non-compliance is sanctioned by an appropriate contractual penalty or constitutes a reason for a discount on the service fee. For example, the following criteria are usually stipulated:
- Response time – the time between the reporting of an incident and the acknowledgement of its receipt;
- Incident resolution time – the time between reporting an incident and remedying it (or accepting an acceptable work-around solution);
- Software availability – actual availability of the software in the given period, normally reported as a percentage; or
- other criteria such as recovery time objective (RTO) – the time between software failure and restoring the software from backup, or recovery point objective (RPO).
However, when negotiating a service level agreement, you should always consider – in relation to the importance and value of the software – what service activities you really need, how strict you want your deadlines in the SLA to be, how high the penalties for non-compliance should be, etc. If you don’t consider these criteria, you may end up paying the supplier unnecessary fees for a performance you don’t need, since a higher scope of services, stricter SLA criteria or higher penalties naturally increase the fee for these services.
Summary
From the software user’ point of view, it is not particularly useful to rely solely on statutory regulation or on a quality guarantee. Entering into a service level agreement is the best possible solution to ensure that your software will work properly and have the longest possible life cycle, especially if it is a key information system of your company. In principle, this is already a common practice, with suppliers often coming up with this concept themselves. Quite logically, with an SLA, they can ensure their regular income for additional services on top of the “one-off” delivery of the software.
If you are implementing or considering the implementation of a significant software for your company, we recommend that you do not underestimate the drafting of appropriate contractual documentation, both in relation to the implementation of the software itself, as well as its operation and maintenance – and that you ideally negotiate both contracts simultaneously.
In practice, we often encounter situations where companies, having underestimated this area, face longer and more expensive delivery of their entire project, or even an overall failure and emergence of long-lasting and costly disputes.
If you wish any assistance with your implementation project or any other technology legal issue, our technology team is of course ready to help you.
