What you need to know before you purchase software licences

Buying software licences - legal aspects you need to know about

Purchasing software is still complex, even though IT services are now part of everyday life and hardly anything works without IT. Regulations are important, if only to avoid disputes. They are indispensable if a dispute arises regardless. Once the project is in trouble, any effort invested beforehand in sensible and realistic contract design is effort well spent. Moreover, contractual agreements are useful to promote the success of the IT project contract.

When purchasing software, it is not a matter of regulating as much as possible, but rather of ensuring that what is regulated is regulated as completely as possible. In this article we present an overview of the mandatory regulations and give tips for contractual formulations. It is also important for the user to choose a reputable and experienced supplier. Whoever regulates the services in the contract with a reputable and experienced supplier in some detail, taking into account the points listed below, has already done the essential work of securing the contract.

This article was written by our cooperation partner Dr. Meinhard Erben. Dr. Erben is
Management Partner at the law firm Dr. Erben Rechtsanwälte and has been advising software users on commercial law, especially IT contract law and cloud computing, for more than 20 years. Dr Erben is a lecturer and publisher of several books on the subject of IT contract law.

Contract Preparations

First of all, the task must be formulated as solidly as possible. External advice is often useful for this. However, the user does not have to provide a description of the software's functionalities, but only describe the application requirements. The implementation of the application requirements in the software is then up to the supplier. When you have reached the point, either internally or with external advice, where you know exactly what you need in terms of performance, it is advisable to ask various suppliers to submit a bid (see draft cover letter). The incoming offers are then assessed. It makes sense to draw up a concept beforehand according to which the various criteria are weighted. After all, what has not been clearly asked for cannot usually be reasonably assessed later on. The following criteria in particular can be considered for evaluation: price, fulfilment of the specified quality features, necessary cooperation of the user taking into account the effects on the price, scheduling, technical knowledge, IT knowledge of one's own departments, experience in similar G bids, similar IT projects with other customers, experience with the provider, staff profiles of the provider.  

Sufficient time should be planned for the examination of the offers. Experience shows that it takes much more time than expected to receive offers and make them comparable. Within the framework of the evaluation, a pre-selection should then first be made according to whether all knock-out criteria are fulfilled. It is recommended to define the issue of long-term maintenance of the software as a K.O. criterion, because in the course of using the software, the user spends considerably more money on its maintenance than on its purchase. So he should make sure beforehand whether and under what conditions the maintenance is to be provided. All documents relating to the draft contract should be updated until the final selection. Then, later, only the results of the final negotiations need to be incorporated into the individual partial documents. Finally, the contract can be signed.

Cover Letter to Pre-Selected I.T. Suppliers (Software Licence Providers/Software Houses)

The invitation to tender should include the terms of reference drafted in as much detail as possible, the remainder can be formulated as follows: 

Subject: Invitation to Tender for the Creation of Software for USERS 

Annexes:

1. Draft contract
2. Specifications 
3. Performance certificate 
4. Questionnaire
5. Notes on the preparation of the offer 

Dear Sir or Madam, 

we intend to have a software created for DESCRIPTION. The software is to be [...] .  Details can be found in the specifications attached as Annex 2. 

We will ... (= description of the user's involvement in bringing about the goal). 2. [...] Your offer shall consist of: 

- the performance certificate completed by you according to Annex 3. The estimated effort is to be stated in working days for each bullet point It is not binding as a performance obligation, but is intended to provide information on the intensity of the processing; 

- the solution proposal. In it, you can describe how you will fulfil the requirements. The outline of the performance specification is to be adhered to as far as possible. You are asked to clarify your approach as far as possible, in particular to outline the solution planned for the individual points. You are also asked to indicate which of your own preliminary work you can draw on. In the time and work plan, you are asked to describe how you plan to handle the project in terms of personnel, deadlines, cooperation with us, etc., taking into account the specifications. is planned on your part; 

- the qualification certificates of the employees planned for the individual work; if necessary, several employees can be specified, between whom you can choose later; 

- Information about your company and references on similar projects. This also applies to subcontractors who are to be involved in the contract; 

- the answers to the questionnaire; 

- a statement of the terms and conditions of the contract we require, as set out in the draft contract attached as Annex 1; 

- a supplier's presentation; 

- the covering letter, which should contain the following text: 

'The services listed in the attached proposal are hereby offered. These cover all requirements of the task according to the specifications, unless exceptions are explicitly listed in the solution proposal. [...] We also accept the terms and conditions of the contract, unless reservations are listed below, namely: We shall be bound by this offer until the end of the envisaged commitment period, i.e. until DATE'. 

3. Tenders that do not comply with the following requirements will not be considered: ... 
4. We ask you to check this request for completeness and to inform us immediately if the documents contain ambiguities or contradictions or if you have concerns about the intended type of execution. 
5. With your offer, you undertake to present it to our company on one day after its submission, separately for the management and for the IT department. If your offer makes it into the final selection, you undertake to ... (test installation, project manager meetings, update offer, etc.);  
6. We will make the selection based on the following criteria in particular: ... [K.O. criteria are marked with *]. 
7. If necessary, further points". 

It is extremely important that providers present their effort estimates in detail. They can only do this if a corresponding list of service items is included in the service specifications. In this way, the user can check on the basis of the effort estimate whether the provider estimates the task similarly to the user and how the provider differentiates and weights the individual partial services from each other. This should not lead to a decision, but it facilitates the decision-making process and increases its comprehensibility. 

Contractual Arrangements

Define the Contract As a Contract for Work

When purchasing software based on standard software, individual services are regularly subject to the law on contracts for work and services, while others are subject to the law on sales contracts or the law on contracts for work and services.  The law on contracts for work and services offers the user significantly more advantages of a legal nature. It is also the most suitable type of contract, because it focuses the user on the overall success: delivery, installation and introduction of software that is ready for acceptance. 

Software ready for acceptance, including all associated services. Therefore, the applicability of the law on contracts for work and services should be agreed as a whole: 

"This contract is subject to the law on contracts for work and services as a whole". 

Performance Standards

The specifications for the supplier must be as clear as possible and thus verifiable. For example, the user does not want to have to put up with excessively long response times when it comes to performance: 

"The performance of the software is such that, with X active dialogue participants, a response time for simple processing steps of no more than 2-3 seconds is achieved in 95 % of all cases." 

Since without a contractual provision it is not legally certain whether the standard programme on which the software procurement contract is based must include all functions customary in the industry as normal use, it is advisable to safeguard this: 

"All programme functions customary for use by USER and/or in USER'S INDUSTRY are present." 

Finally, the user can make the contract revocable for himself: "Vendor" has a right of revocation until DATE. A basic configuration is installed first and the preparation for use is carried out to such an extent that the user can decide whether he wants to exercise the right of withdrawal. If the USER exercises the right of withdrawal, he shall pay for the support services provided up to that point. In addition, he retains SYSTEM SOFTWARE COMPONENTS / APPLICATION SOFTWARE COMPONENTS and pays for these services."

Availability of Employees

• Many projects get into difficulties because the supplier's employees and/or project managers are replaced. This can be partially prevented by agreeing on a date for acceptance secured by a contractual penalty. In addition, however, the user also wants to regulate that the supplier may not simply replace his key employees: 
• "The project manager and the supplier's other named consultants may not be exchanged for other employees as long as they remain available to the supplier in their previous function. If the supplier replaces other employees, it shall bear the induction costs." Contractual penalties for default.

• Suppliers often fail to meet the agreed deadlines. Many software companies offer to pay a contractual penalty in this case. If this is not the case, the user should in any case provide for a contractual penalty provision, because the damage caused by delay suffered by the user is often difficult to determine: 
• "If the supplier is in default, USER may demand a contractual penalty of 1% of the value of those services which cannot be used for their intended purpose for each week of default or part thereof, but not more than _% of the order value." 

Provide for Acceptance

• Even if the law on contracts for work and services applies, it is extremely important for the user to provide for a total acceptance for all services. This is because the supplier's claim to remuneration only becomes due upon acceptance, the burden of proof is reversed and the limitation period for warranty claims begins to run. Therefore, the user has an interest in postponing the acceptance as far as possible and to be able to check all services including their interaction beforehand. The minimum requirement must therefore be that the supplier demonstrates the operational readiness of the IT application system after its installation and that the user then confirms the successful demonstration. The user should also demand a provision that an acceptance test is carried out with test cases prepared by him, in particular also with rare cases, so that he can check the application range of the system.

Warranty Not According to Law

• Software houses frequently and gladly eliminate errors in programmes only in the context of the delivery of a further developed version within the scope of maintenance. This also applies if the software procurement contract is based on standard services from the supplier, as is regularly the case.  The user therefore wants to agree that error correction is owed immediately, ideally secured by service level agreements with contractual penalty obligations. In addition, the supplier should undertake in the contract to create workarounds so that the impairment of use is largely mitigated: 
• "The supplier shall immediately eliminate errors in the software that preclude or significantly impede the use of the entire system or a part thereof. To the extent necessary, it shall immediately devise a workaround. Errors which impair use but can be accepted until the delivery of the next version need not be eliminated until the delivery of a next version. The supplier shall also work out a workaround for such errors within a reasonable period of time and communicate it to ANWENDER." 
• The warranty period (for some years now the law has called this the limitation period for liability for defects) should be at least the statutory warranty period, i.e. 24 months, also because the supplier side always emphasises that software errors cannot be ruled out. In addition, the user wants to postpone the start of the warranty period as far back in time as possible: 
• "The limitation period for liability for defects is 24 months. It begins uniformly for all services with the last partial delivery".

Price Coverage Clause

• Often, either the supplier's offer is not complete, so that additional services are required. Or the supplier lists services in the contract for which there is no clear obligation to pay. There is also the case that services are required which the supplier has not clearly named in the offer, so that the user does not know this at the time of concluding the contract. Therefore, the user should always provide a price cover clause: 
• "The agreed remuneration for the overall system covers all services required for the commissioning of the turnkey system, unless exceptions are expressly stated in the contract".

Arrange Late Payments

• Cash makes sense. Payments before acceptance should therefore generally be warned against, especially as some smaller software suppliers are also frequently threatened by insolvency. Down payments should always be secured by bank guarantees with payment on first demand. Incidentally, it is advisable for the user not to commit to payments for parts of the services, but at least to define sensible partial services, which then only have to be paid for after complete performance and (partial) acceptance by the software supplier in each case. The following applies to the software: If it is to be paid for after installation, its functionality must be demonstrated in advance. 

Care Guarantee

• The user spends a lot of money on the software and wants to work with it for a long time. So he needs a maintenance guarantee. It makes sense to include safeguards for care and maintenance in the transfer contract if the contracts for care and maintenance are concluded at the same time as the transfer contract. This is particularly obvious for the application software because the maintenance services are already required from installation or acceptance and because these services go far beyond the legal warranty, which only includes error correction. There is an urgent warning against users underestimating the issue of maintenance. There are at least three (3) reasons for regulating maintenance and servicing, at least in the main features, already at the conclusion of the software procurement contract:
• First, the user's bargaining power is much greater at this point than later. 
• Secondly, it is unclear to what extent the supplier is obliged to provide these services at all if this is not regulated in the contract.
• Thirdly, practice already shows when invitations to tender are issued that answers on this subject are often meagre and imprecise. In particular, the supplier side likes to leave out how unwilling it is to rectify errors quickly. Those who provide reasonable and good information have considerable advantages in the evaluation of the bids.

Individual Programming & Fixed Price

• If there is extensive individual programming, the result is regularly the same problems: The customised programming costs more than expected, arrives later than expected and is worse than expected. This is not always the fault of the supplier alone, as users think. Nor can the difficulties be eliminated one hundred per cent by contractual regulations, because they involve actual problems. What is the use of paying a contractual penalty if the agreed service is still not provided? - The user can make a significant contribution to ensuring that the programming actually meets his requirements in terms of price, timing and functionality by actually cooperating on an ongoing basis and actually monitoring the status of the project. Furthermore, it is recommended that the user lowers his expectations somewhat from the outset and instead does everything that can lead to an improvement in the supplier's programming services. With custom programming, it is like marriage: divorce becomes expensive. 
  
  
• For various reasons, the price of custom programming is difficult or impossible to calculate. Nevertheless, practice shows that users insist on fixed price agreements for the most part. If the user then sees in the course of the project what is possible through the use of software, this supports his imagination and inspires his expectations. This often leads to the user using something as a benchmark when accepting the programme system that was not originally agreed upon. Of course, the supplier is then supposed to deliver this standard within the fixed price! - In the end, only good control management and reasonable expectations in line with reality can help here: the contractual agreements must be updated promptly with regard to price, deadlines and, if necessary, effects on performance, especially if the user wants more services than originally agreed. Otherwise the project will almost inevitably get into difficulties and the user will tend to make unjustified demands. In the end, this is of no use either to the user, who wants the programming including the change requests, or to the supplier, who naturally wants to realise additional services only against additional remuneration. What can be done concretely?  
  
  
• Firstly, it should be remembered that even if the project management has largely been transferred to the supplier, the user should continue to take care of the project on a regular basis: The user is still responsible for the overall management, the management of his duties to cooperate and the control of the contractor. For the rest, the following applies: If a fixed price is to be used, then it should at least be formed correctly. For the calculation of individual programming, the user should realise that a reasonable supplier would have to calculate considerable surcharges on the probable effort, but that he does not do this or does not do it sufficiently because the competition does not do it either.
  
  
• In the end, however, with a fixed price the project will be more expensive for all suppliers by a certain amount of the surcharges - or the user will have to make concessions in quality: 
  Basis: probable effort based on the client's specifications in the case of proper project implementation (= calculated effort x safety factor),
  Including the cost of warranty 100% surcharges: 

Secondly, the user should define his requirements for the services and their quality in a reasonable way so that the provider can also calculate the costs reasonably. This should also be done so that the user can compare the offers with each other. The following factors, among others, can be used to weight the quality: Degree of reliability, security, efficiency in terms of time consumption, efficiency in terms of memory consumption, user-friendliness, expandability and transferability.

Thirdly, once again, and even if it sounds obvious, it is emphasised that the user should, above all, choose the right contractor. This includes asking for references or looking at other software that this contractor has produced. It is often advisable for both sides to start with a small order to get to know each other.
 
If you are looking for more information on this topic, you can find it in the book Er ben/Günther, Beschaffung von IT-Leistungen, Vertragsgestaltung für Anwender, SpringerGabler, Heidelberg 2018.