0
0
was successfully added to your cart.

Cart

Individual Custom Software and German Law

How not to become really unhappy with your custom software “Made in Germany”

Checklist of Legal Issues around creating Custom Software in Germany

If you are planning to have custom software created for your company in Germany, you should first consider a few important things. Here’s a checklist from the perspective of German IT law expert Stephan Hendel:

What is individual or custom software?

Individual or custom software is software that has been created for the special purpose of a particular user and is then permanently handed over to this user. For example, this may be software that has been specifically designed to meet the needs of a purchaser for handling its warehousing and ordering operations. The creation of individual software is, according to the prevailing opinion, a contract for work according to §§ 631 ff. BGB  (German Civil Code) because here the achievement of a certain success is owed (BGH BauR 2004,337; CR 2002,93; NJW 2001,1718).

What do I have to consider when creating individual software?

In contrast to standard software, individual software is characterized by the fact that it will (in most cases) only exist once. In this respect, the so-called specifications play an important role. The features of the software to be created agreed between the customer and the contractor shall be specifically summarized. This specification sheet plays such an important role because it provides information in future disputes about the scope of the software or any defects that may occur. In addition, it is advisable to set out the purpose of the individual software in as much detail as possible in a preamble to the contract, in addition to the specifications.

Documentation

Good individual software always includes reasonable documentation. Any software, however good it may be, is worth nothing or little without documentation about the source code, its applicability, administration, etc. to give you the information you need.

What types of documentation are there?

A primary distinction is made here between administration, installation and operational documentation, program and source code documentation, training documents, project management documentation and test documentation. This list is not exhaustive and can be extended on a case-by-case basis. However, the previous types of documentation have proven themselves in the creation of most individual software. It is therefore advisable to contractually agree at least these types of documentation.

Source code of the program

It is strongly recommended that a contractual agreement be made as to who becomes the owner of the source code. If this has not been contractually agreed, it must be assessed on the basis of the circumstances of the individual case. Features such as the amount of the agreed compensation for work are of great importance here, as is whether the program is to be used for marketing by the customer and whether the customer could also require the source code for the maintenance and further development of the program. Here, too, there is great potential for dispute.

As you can see from this, the transfer of the source code is not necessarily due. In this respect, you should consider carefully whether you might not need it at some point in the future. Then it would be a gross mistake not to include the transfer of the source code in the contract.

What happens if contractual regulations are missing?

Should the parties subsequently discover any shortcomings in the contract, the contract concluded shall be interpreted. That this is not necessarily advantageous for both sides is obvious. If, for example, it has not been agreed in detail (buzzword: obligations or specifications) what the program to be created has to perform, the contractor shall only owe software which, taking into account the contractual (basic) purpose, corresponds to the current state of the art with an average execution standard (BGH MMR 2004,356). In case of doubt, such problems must be dealt with in court by an expensive expert.

What happens if the individual software created is defective?

Since, as already mentioned above, the creation of individual software is primarily governed by the law on contracts for work and services (§§ 631 et seq. German Civil Code), these standards must be applied. Accordingly, one of the most important obligations of the manufacturer of the work is that he must procure the work free of material defects and defects of title (§ 633 Para. 1 German Civil Code). The standard is to be assessed in accordance with § 633 Para. 2 German Civil Code. Consequently, the work is free of defects if it has the agreed quality. The agreed quality shall be specified in the contract. Here you can see once again that the design of a contract in the software area is very important. For example, the following shortcomings could occur (depending on the content of the contract):

  • Lack of development speed (BGH CR199 6.667)
  • Missing possibility of data backup (BGH NJW 199 6,2924)
  • Virus infestation caused by the contractor (Schneider/Günter CR199 7,389)
  • A faulty, hardly understandable or even missing documentation (BGH NJW 2001,1718)
  • Missing plausibility check of user entries (LG Heilbronn CR198 9,603)

What can I do if there are deficiencies?

Since the warranty rights are governed by the general law on contracts for work and services, the means listed here must also be used.

Until acceptance, the software customer may refuse acceptance of the software due to a defect, unless the defect of the software is insignificant according to § 640 Para. 1 S. 2 BGB (German Civil Code) – which the factory entrepreneur has to explain on the complaint of the factory customer. This can open up a large spectrum of deficiencies in individual software. However, only if the contracts are sufficiently and reasonably written according to the respective purpose of the contract. Otherwise, it is to be expected that the contractual relationship will be disrupted and that the creation of the desired software will be delayed or will no longer take place. That is at least our practical experience in this area.

After acceptance, the software purchaser’s defect rights pursuant to § 634 No. 1 to 4 BGB (German Civil Code) may be considered. In this case, the previous position applies to an even greater extent. Because now it is the software customer who has to prove any defects. The requirements for this are quite high.

Conclusion:

If you are planning to create individual software, you should always include a budget for the creation of contracts.

As a rule of thumb, the costs incurred retrospectively due to inadequate contracts in the event of defects quickly amount to three times the total order volume. This is due to the fact that incorrect rights allocations (e.g. copyright) require the purchase of software that is no longer suitable for the actual, intended use. Nor should the costs of legal proceedings be disregarded. Because hardly any judge in Germany will dare to check complex individual software on the basis of the source code or the functionalities from his own knowledge. The absolute rule is that a court will call in a specialist IT expert. Depending on the scope of the expert opinion, its costs can easily be between € 5,000 and € 20,000. The costs can also become more expensive. This is due to the complexity of the report.

– – –

If you have any questions about IT law, data protection, online commerce or other internet related legal issues, do not hesitate to contact German lawyer and IT law expert Stephan Hendel. Having a Canadian family background, Stephan is fluent in English and is well aware of the different business mentalities of Anglo-American as well as German entrepreneurs. Our German and international clients appreciate Stephan’s pragmatic hands on approach. Within the Cross-Channel-Lawyer network, Stephan is the expert for all legal matters surrounding IT, cyber law, data protection issues and compliance with German law.

For more on German IT, business and corporate law see these posts:

Tags: