Legal pitfalls in software contracts

Work contracts and service contracts differ in terms of what is owed: a finished result in the case of a work contract, the service itself in the case of a service contract. Agile software contracts are often considered contracts for work in court because the backlog defines the work. A few targeted contractual clauses prevent liability risks that can drive companies into bankruptcy.

Key Takeaways

• Agile developed software is almost always considered a contract for work in court, even if the contract is called a “service contract”, because courts evaluate the intention of both parties and not the title.
• Freelancers are liable for errors in their work for up to two years without being paid additionally, unless a contractual clause to the contrary has been agreed.
• Anyone who does not fulfill a warning and notification obligation in the contract and does not inform the client of unavoidable software errors risks having to refund the entire fee already paid.
• The state of the art applies at the time of product handover, not at the time of commissioning, which has considerable technical and legal consequences for long projects.
• AI-supported test methods do not currently correspond to the state of the art because scientific studies on their effectiveness are still lacking.

Self-employed people owe a success, not an effort

Anyone who works as a freelancer owes something fundamentally different in legal terms than an employee. A self-employed person owes success, not just the effort expended. It is not enough to have put many hours into a project. The project must have been a success.

This is just as true for a computer scientist as it is for a tiler or carpenter. If the tiler lays the tiles in five hours and something breaks, he must rectify the fault without additional payment. Applied to software, this means that a freelancer who introduces bugs into software is not legally entitled to be paid for fixing them.

In practice, things work differently. Freelancers are usually also paid to fix their own bugs. However, this entitlement only exists if it is stipulated in the contract. Without a corresponding clause, the correction of errors falls under the warranty and is therefore at the freelancer’s own expense.

How do you protect yourself as a freelancer in the contract?

Write in the contract that error-free software is not technically possible and that the correction of errors is not covered by the warranty, but will be billed as a normal service. This one sentence shifts the logic in your favor.

This applies equally to developers and testers. A customer who books a tester expects the tester to find the bugs. If the tester only finds 4520 of 4521 errors, the question of liability arises, especially if this results in damage. Here, too, it is helpful to clarify that no human being can find all errors.

A practical piece of advice: Never promise in your advertising that you will find all the errors. Such superlatives will later work against you in court.

You can differentiate in terms of liability. You cannot exclude gross negligence. On the other hand, you can contractually exclude slight negligence, i.e. the everyday mistakes that happen to everyone.

How long are you liable if nothing has been agreed?

Unless otherwise agreed, a warranty period of two years applies in Germany and Austria. In the B2B sector, this period can be shortened, but not to less than six or twelve months.

Attempts to reduce the warranty below this or to exclude gross negligence will fail. If you only write a three-month warranty and an exclusion for gross negligence in the contract, for example, the judge will reject this passage. It then applies as if it were not there, and the two years continue to apply.

Liability extends beyond the warranty. It concerns not only the rectification of an error, but also the costs of the damage incurred. In the case of large software, this can drive a freelancer into bankruptcy faster than the mere rectification of a defect.

Duty to warn and notify: no money without a warning

If a freelancer fails to comply with their duty to warn and inform, this can cost them their entire fee claim. If you fail to point out to a customer that software may contain errors, this defect can be used against you later, even if the work has been completed.

The client can then argue that they were never informed that the software could contain errors and demand a full refund. A single warning point in the contract is enough to prevent this.

How strictly the duty to warn applies depends on the buyer’s experience. If the customer has an IT background, a different standard applies than for a customer who has never had software developed before. The decisive factor is what the buyer can expect. Everyone expects from a carpenter that the table will not collapse when you step on it.

In practice, this rarely hits freelancers hard because they are usually not the first in a well-established project. It gets tricky with small projects for customers with no IT experience. Here, the warning must be included in the contract.

How to get a contract amendment through easily

Intermediaries often present freelancers with ready-made contracts without knowing the underlying legal intricacies. They just pass the documents on. This makes things easier than many people think.

Instead of discussing individual passages, amend the contract yourself, add your own passage and send it back signed. Experience has shown that a signed document goes through more smoothly than an open negotiation about individual clauses.

Agile contracts: why the title doesn’t matter

The most dangerous mistake in agile projects concerns the distinction between a contract for work and a contract for services. Essentially, there are only these two types of contract. In a contract for work, you owe a finished work, previously defined by a specification. In a service contract, you owe the service itself.

With agile custom software, it is not clear at the beginning what the software should be able to do in the end. This is precisely what makes contractual classification difficult. Many contracts bear the heading “service contract” and charge by the hour, on the assumption that this settles the matter.

That doesn’t count in court. Neither the heading nor billing by the hour define a service contract. If the contract states that specific software is to be developed, it is a contract for work. The decisive factor is the intention of the contract, as interpreted by a non-expert client. They typically understand an agile software contract as a contract for work.

The backlog becomes the service owed

If an agile contract is considered a contract for work, you owe the defined content in full. And the only thing that defines what the software should be able to do in an agile project is the backlog.

This leads to an unpleasant logic: the software is only considered finished when the entire backlog has been implemented. This also includes the stories and features that the product owner wrote in just two days ago. And in many projects, the product owner is the customer.

It is legally permissible for the project content to only emerge over time. However, it is precisely this mechanism that turns a project into a contract for work and services, where you owe the whole thing.

A specific case shows the explosive nature of this. A client was constantly adding new features to the backlog in the agile sense. At some point, he stopped making payments and sued for the reversal of all payments, arguing that the backlog was still full and the software was therefore not finished. Several million euros were at stake. For a small company, such a judgment means bankruptcy.

These sentences turn the contract for work into a contract for services

A few precise formulations decide whether a court considers a contract to be a service contract or a contract for work. These points should be included:

• The subject matter of the contract is not clearly stated at the beginning.
• The client works together on the project and reprioritizes the features at any time.
• The client is decisively involved in the process and issues instructions.
• The focus is on the provision of the service, not the finished software product.
• The contractor is not responsible for the success of the project, but for the quality of the service provided.

The point about instructions is tricky because it touches on the issue of bogus self-employment. Two legal logics collide here, and this requires careful formulation.

These passages are basically the written version of the agile idea. They state that you do not owe the success of the project, but the joint work on the product.

What “state of the art” in the contract really means

Almost no contract states what technical quality actually means. Often there is only the phrase “corresponds to the state of the art”. In the event of a dispute, an expert clarifies what is meant by this, and his judgment depends heavily on the contractual situation.

Be careful with superlatives. If it says “best quality” somewhere, a court will read this as “no defects”. Such formulations increase your liability instead of limiting it.

Instead of nailing down the state of the art in detail, agree on a process. Write it into the contract that a decision will be made together with the client during the course of the project according to defined rules as to what corresponds to the state of the art. Then the expert, judge and opposing lawyer have an agreed process in their hands that they only need to check for plausibility.

If you define in this process, for example, that a test coverage of 30 percent is sufficient, this is binding. Without such a definition, an expert comes along and demands 80 percent coverage, a figure that is questionable anyway.

How an expert assesses the state of the art

An individual technology is considered to be state of the art if the scientific literature supports it. The assessment is carried out in stages. First, the question of whether there is any literature at all on a technology. Then, whether this literature proves that the technology is more efficient and effective than existing alternatives.

The example of mob programming versus pair programming shows the benchmark. There are scientific studies on pair programming that prove that it is more efficient and effective than solo programming. For mob programming, on the other hand, there is no clear scientific evidence of higher efficiency or effectiveness.

One method remains permissible, even without studies. However, anyone who wants to use mob programming should gain experience that goes beyond gut feeling: Measure times, compare two teams on the same task. Documented decisions, for example in Architecture Decision Records, provide a comprehensible justification for every technique used.

Residual error rate instead of code coverage

When it comes to determining whether an end product is usable, it is not the code coverage of the automated tests that counts, but the residual error rate. The client is rarely interested in whether he has paid too much. He is interested in whether he can use the software at all.

The residual error rate can be calculated. If it is above 0.5 bugs per 1000 lines of code, the software is considered unfinished. For large software, the absolute figure is naturally higher than for small software.

The reality is sobering. According to the literature, the average residual error rate is significantly higher, at 20 to 30 bugs per 1000 lines of code. This means that most of the software used does not correspond to the state of the art in terms of its residual error rate.

When does a project end up with the question of technology?

The techniques of a project are usually only examined secondarily. First, a reviewer clarifies whether the software is ready for acceptance. Only if it is not is the question of blame addressed: was it due to poor techniques in the test or in the code?

What then counts is whether everything was put on one card. In testing, relying solely on end-to-end testing is a bad idea. Different techniques side by side speak for clean work, a single approach against it.

AI in testing: currently thin legal ice

Anyone who has software tested by artificial intelligence is on uncertain legal ground. There are virtually no scientific studies on whether AI in software development and testing is state of the art.

The argument “good coverage through AI-generated tests” is therefore of no help. As long as there are no studies, the use of AI cannot be proven to be state of the art.

State of the art and science are related, but they are not the same thing. As long as the science on a new method is vague, the old state of the art continues to apply. Only when studies prove that a method is at least as good in terms of quality and productivity does it automatically become the new state of the art.

This benchmark is constantly shifting. What is state of the art at the start of a project may no longer be so at the end. The decisive factor is the state of the art at the time the product is handed over, not at the time the order is placed. This can make a difference for long projects.

Contracts are written for the enemy, not for the friend

A contract is not used to record how you work together. It serves the case of damage.

You always write a contract for your opponent. So always keep this in mind: The contract is not written for a friend, but for an enemy.

Sebastian Dietrich

Even if the other party is a nice person today, a new lawyer could come into the company tomorrow and completely change the situation. This perspective changes what you pay attention to when reading a contract.

The cost of protection is low in relation to the risk. In a specific case in which the existence of a company is hanging by a thread, two sentences in a contract with hundreds of sentences would have been enough. There were many pages about how good Agile software development is. The crucial passages were missing.