The CEO of a manufacturing company in Germany receives the contract template from the software vendor she has just selected to build a production planning system. Twenty-four pages, well drafted, with definitions and schedules. Legal has a week to comment and the board wants the project to start next month. On page nineteen there is a sentence: “Upon payment in full, the Client is granted a non-exclusive licence to use the Software for its internal purposes.”
That one sentence means that after paying several hundred thousand euros the company will not control the code, cannot have it developed further by another vendor without the author’s consent, and cannot sell the system along with the business the way the CEO assumed. Nobody is being dishonest. A contract template prepared by the vendor is simply written from the vendor’s perspective: it protects the vendor’s code, limits the vendor’s liability and makes it hard for the client to leave. A template prepared by the client would protect the client in exactly the same way.
This article is for the CEO, procurement director or CTO who has to read that contract before signing. We go through the clauses in a custom software development agreement that decide the client’s risk: IP assignment, acceptance, SLA and warranty, liquidated damages, team protections, exit and handover, and source code escrow. The argument: a good contract does not assume the project will fail, but it makes sure that if something goes wrong, you still control the system. One note up front: this is not legal advice, and the law differs between the UK, Germany and the rest of the EU. Have the contract reviewed by a lawyer who knows IT deals; this article is meant to help you ask them the right questions.
Why does a software vendor’s contract template mainly protect the vendor?
Because a contract is first of all an allocation of risk, and each party allocates it so that as little as possible falls on them. A vendor worries about four things: that the client will not accept the work and will not pay, that it will be liable for losses out of proportion to the contract value, that it will lose the right to reuse its own components, and that the client will change requirements without paying for it. Its template solves those four problems carefully and well.
The client worries about different things: that the system will be late or will not work, that it will not be able to develop the system without this vendor, that key people will leave halfway through and that, if the relationship ends, it will be left with code nobody understands. The vendor’s template usually does not address those worries, or addresses them with a phrase like “the Supplier shall use reasonable endeavours”.
The scale of risk in IT projects is not theoretical. A study published in Harvard Business Review in 2011 by Bent Flyvbjerg and Alexander Budzier, covering 1,471 IT projects, found that one in six had a cost overrun of 200% on average and a schedule overrun of almost 70% (HBR, 2011). A contract does not lower the probability of that scenario, but it decides who bears the consequences and whether you can get out of it.
The practical conclusion is that negotiating the contract is not a tug of war but a rebalancing of perspectives. A credible vendor will accept most client-protecting clauses, because they do not hurt its business if it does the work well. A vendor that refuses IP assignment, repository access and an exit plan is telling you something. That is why the key terms belong in the RFP, as we explain in our article on writing a software development RFP, not only after selection.
IP assignment or licence: what do you actually need?
This is the first and most important decision. In most European jurisdictions, copyright in code written by an independent contractor does not pass to the client simply because the client paid for it. You need the right clause, in the right form.
United Kingdom. Under the Copyright, Designs and Patents Act 1988, copyright in a work made by an employee in the course of employment belongs to the employer (s. 11(2)). A software vendor is not your employee, so its work belongs to it unless it is assigned. And an assignment of copyright is not effective unless it is in writing and signed by or on behalf of the assignor (s. 90(3), CDPA 1988). Without a written assignment, a court may find an implied licence, or in some cases an equitable assignment, but you will be arguing about its scope at exactly the wrong moment.
Germany and Austria. German copyright law takes a different starting point: copyright itself is not transferable (s. 29(1) UrhG). What the client receives is a grant of rights of use, ideally exclusive, unlimited in time, space and content, transferable and sublicensable. Where the types of use are not specifically named, their scope is determined by the purpose both parties envisaged when contracting (s. 31(5) UrhG, see the official English translation). In practice this means a vague clause gives you only what a court thinks the contract was for, which may not include handing the code to another vendor or selling the system as a product. A DACH contract therefore needs an explicit list of permitted uses.
Poland, where many nearshore vendors are based, is similar in spirit: an assignment of economic rights must be in writing on pain of nullity and covers only the fields of exploitation expressly listed in the contract. If your vendor is Polish and the contract is governed by Polish law, those rules apply.
A licence is not bad by nature. It makes sense when the vendor delivers its own product or platform, sold to many clients, and builds modules on top of it for you. Demanding assignment of the whole thing would be unrealistic; a reasonable structure is a licence to the product and assignment of what was built exclusively for you. But in a project where you pay to have a system built from scratch, a non-exclusive licence means the vendor could sell the same code to your competitor, and you cannot freely hand it to a new team.
The contract should contain four elements. First, assignment (or, in Germany, an exclusive grant of rights of use) covering source code, object code, documentation and every other deliverable. Second, the moment the rights pass, ideally on payment for each milestone rather than only on final payment, because if the project stops after milestone three you want the rights to what you have paid for. Third, an explicit right to modify, adapt, extend and combine the code, including through third parties. Fourth, the price of the assignment included in the contract price, so there is no later argument about whether it was paid for.
For a broader introduction to who owns code in different engagement models, see our article on intellectual property in IT. Here we focus on what goes into a contract with a software vendor.
How should permitted uses be listed for software?
Whether you call them fields of exploitation, types of use or licensed purposes, the principle is the same: name the uses that matter to your business rather than relying on general wording. A list for a business system usually covers:
- reproducing source and object code by any means, including on servers and in the cloud;
- loading, running, displaying, transmitting and storing the software;
- translating, adapting, modifying, extending and combining the software with other software, directly or through third parties;
- distributing, including selling, lending and renting copies;
- making the software available to the public so that anyone can access it at a time and place of their choosing, including as SaaS;
- granting licences and sublicences to third parties, including group companies;
- using documentation, designs and content to the same extent.
Two uses are missing from contracts most often and turn out to be needed most often. The first is modification and further development by third parties, without which switching vendors becomes legally awkward. The second is SaaS provision and sublicensing, without which you cannot turn an internal system into a product for customers or make it available to a subsidiary.
Then check the chain of title. Employer-ownership rules (s. 11(2) CDPA in the UK, s. 69b UrhG in Germany, which gives the employer the economic rights in programs written by employees in the course of their duties) only help the vendor if the developers are its employees. Many developers at software vendors work as freelancers or through their own companies, and those rules do not cover them. The vendor can only assign what it owns. Ask for a warranty that every author, including freelancers and subcontractors, has assigned their rights to the vendor at least as broadly as your contract requires, and an indemnity against third-party claims.
What about open source, vendor components and AI-generated code?
No modern system is written entirely from scratch. The vendor’s code will use open source libraries, the vendor’s own internal components and, increasingly, code produced with AI assistants. Each needs its own clause.
Open source. You cannot be assigned rights in libraries written by third parties. The contract should exclude them from the assignment and require the vendor to keep a component register, ideally a software bill of materials (SBOM), with each licence. Add a commitment not to use components under strong copyleft licences without your consent where your distribution model could be affected.
Vendor background components. Many vendors have their own libraries, templates and modules that they reuse across projects. It is reasonable for them to keep ownership, but then you need a licence that is perpetual, irrevocable, royalty-free and covers modification and development by third parties. Otherwise leaving the vendor means part of your system is no longer legally usable. Ask for a list of those components in a schedule.
AI-assisted code. The copyright status of code generated by AI tools without meaningful human creative input is uncertain across Europe, and the prevailing view is that protection requires human creative contribution. For the client this leads to two practical clauses. First, the vendor discloses whether and how it uses AI assistants and is responsible for the code regardless of how it was produced, including licence compliance and freedom from third-party claims. Second, rules on which AI tools may process your code and data, under what terms, and whether anything may be used for model training. We cover the quality issues of AI-assisted code in our article on the AI code audit.
How do you define acceptance so it does not become a battlefield?
Acceptance is the moment on which payment, transfer of rights, the warranty clock and often liquidated damages depend. That is why it is the most common source of disputes. A good acceptance clause answers five questions.
What is being accepted? A specific milestone or increment with a feature list and acceptance criteria agreed before work on it starts. Without criteria, acceptance becomes a debate about expectations.
How long does acceptance testing last? A set number of working days, typically five to ten per milestone, extendable for large releases. The vendor needs certainty it will not wait indefinitely; you need time to test properly.
What is a defect and what is a change? A defect is a deviation from the acceptance criteria. A change is a new expectation. Classifying defects by severity (blocking, major, minor) and accepting despite minor defects, with an obligation to fix them by a set date, avoids many arguments.
What if the client says nothing? Deemed acceptance after the test period expires without a defect report protects the vendor from blocked payments. It is a fair clause, but the period must be realistic for your team.
What if acceptance fails again? After a second or third failed acceptance of the same milestone, you should be entitled to terminate in part, reduce the price or have the fixes done by a third party at the vendor’s cost. Without that clause a failed milestone can drag on for months.
One provision deserves special attention: acceptance should not be a condition of access to the code. Code should land in a repository in your organisation continuously, with every commit, regardless of acceptance and payment. The transfer of rights can be tied to payment, but physical access to the code should never be a hostage in a dispute.
Which SLA and warranty terms make sense after go-live?
Warranty and SLA are two different things that contracts often blur. A warranty covers defects in what the vendor delivered: for a set period the vendor fixes them at no charge. A service level agreement covers maintenance and support: how quickly the vendor responds to incidents and what availability it provides, usually for a fixed fee or subscription.
Warranty. Typical periods run from three to twelve months from acceptance of a milestone or of the whole system. The details matter more than the length: when the period starts (per milestone or at final acceptance), whether it covers defects that appear in production, fix times by severity, and whether the warranty lapses when someone else modifies the system. The last point is fair for the modified parts but should not void the warranty for the entire system.
SLA. A well-written SLA has four elements:
- incident classification with clear definitions (critical: the system or a key process is down; high: an important function fails but a workaround exists; normal; low);
- response times and workaround or resolution times for each class, distinguishing business hours from 24/7 cover;
- measurement: which tool, who reports, when the clock starts and how results are reported each month;
- consequences of a breach, usually service credits against the monthly fee or liquidated damages, and a right to terminate for repeated breaches.
The most common mistake is an SLA that measures only response time. “Ticket acknowledged” within fifteen minutes fixes nothing. What counts is time to restore service, even by a workaround. The second mistake is availability expressed as a percentage without saying what is measured (the whole system or key processes), over what period and whether planned maintenance is excluded. 99.5% a month allows roughly 3.6 hours of downtime; 99.9% allows roughly 43 minutes. The difference in infrastructure and on-call cost is substantial, so pick the level your business actually needs.
How do you set liquidated damages that work rather than just threaten?
Liquidated damages are a pre-agreed sum payable on a specified breach, so you do not have to prove the actual loss. But in IT contracts they are often drafted so that they either do not work or get priced into the bid anyway.
How courts treat them differs. Under English law, following Cavendish Square Holding v Makdessi [2015] UKSC 67, a clause is an unenforceable penalty if it imposes a detriment out of all proportion to the innocent party’s legitimate interest in performance. In several civil-law systems a court can reduce an excessive contractual penalty; in Poland, for example, the debtor may ask for a reduction when the penalty is grossly excessive or the obligation was largely performed (Art. 484(2) of the Civil Code). Either way, an extreme figure buys less protection than it seems.
Five principles help.
Tie damages to a measurable event. A milestone missed for reasons attributable to the vendor, an SLA fix time breached, a confidentiality breach, an unauthorised change of key personnel. Damages for “improper performance” without a definition invite disputes, not better work.
Separate the causes of delay. In IT projects some delays come from missing decisions, data or access on the client side. Damages should apply to delays caused by the vendor, and the contract should move deadlines when the client fails to meet its own obligations. Otherwise the clause is unenforceable in practice.
Set a cap. An overall cap, for example as a percentage of the contract value, is standard. Uncapped damages are a risk a vendor cannot price, so it will either raise the price or refuse to sign.
Be clear about the sole remedy question. Decide whether liquidated damages are your only remedy for that breach or whether you can claim further losses above them. If your real loss could exceed the agreed sum, say so in the contract.
Agree the limitation of liability deliberately. Vendor templates almost always cap liability at the contract value or at fees paid over recent months and exclude loss of profit. That is market practice, but the carve-outs from the cap should include at least wilful misconduct, breach of confidentiality and data protection, and third-party IP infringement claims.
Liquidated damages do not replace good project management. Their role is to set incentives and protect you in extreme cases. If you are calculating damages mid-project, the relationship is usually already in crisis, and at that point the ability to exit matters more than the damages.
How do you protect yourself against key people leaving and hidden subcontractors?
With custom software you are effectively buying the work of specific people. If the architect who designed the system leaves in month three and the replacement needs weeks to get up to speed, you pay for it in delay. The contract can limit that risk.
A key personnel schedule. Named people in key roles (architect, technical lead, project manager) and a commitment that the vendor will not replace them without your consent, except for reasons outside its control such as the person resigning or falling ill.
Replacement and overlap. When a change is unavoidable: a deadline for proposing a comparably qualified candidate, your right to reject the candidate, and an overlap period in which the vendor does not bill for the newcomer or bills at a discount.
Your right to request a change. You should also be able to ask for a team member who does not meet expectations to be replaced, with reasons and within a set timeframe.
Subcontractors. Your consent to subcontracting, the vendor’s liability for subcontractors as for itself, and the same confidentiality, security and IP terms. Ask the question directly, because in many firms part of the team are external freelancers.
Non-solicitation. Vendor templates usually prevent the client from hiring the vendor’s specialists. That is understandable, but negotiate its duration and exceptions, such as the right to hire a person after a set period for an agreed fee. It is often the simplest way to retain knowledge when you bring development in-house.
For comparison, here is how this looks with us. Across the engagement models described on our pricing page, every engagement starts with a two-week satisfaction guarantee with free replacement of a specialist who does not meet expectations, and if a specialist leaves during the engagement we guarantee a replacement within five business days. Contracts can be terminated with 30 days’ notice and there are no termination penalties. Whichever vendor you choose, terms like these are worth having in writing.
How do you design an exit and handover procedure?
The exit clause is the one nobody wants to discuss at the start, and the one that matters most when the relationship ends, well or badly. Its purpose is simple: to let you hand the system to another team without interrupting operations and without renegotiating from the weaker side of the table. For a wider view on avoiding dependence on a single vendor, see our article on vendor lock-in.
A good exit clause has six elements.
Continuous access instead of handover at the end. Code repository, ticketing system, documentation, CI/CD pipeline and cloud accounts in your organisation from day one, with the vendor as a user. If everything sits with you throughout, exit is largely a formality.
A notice period matched to the handover. Too short and an orderly takeover is impossible; too long and you are locked into a relationship that no longer works. Typically one to three months, with a right to terminate immediately for material breach.
A handover list. Source code for every component, configuration, deployment scripts, infrastructure as code, architecture and API documentation, data in an agreed format, access credentials, a list of open tickets and known issues, and the component register with licences.
Knowledge transfer. A fixed number of workshop and consulting hours with the new team, at a rate agreed in advance, during the transition. Without it, knowledge transfer becomes a negotiation at the worst possible moment.
Cooperation with the incoming vendor. An obligation to answer questions and take part in the handover in good faith, even when the new vendor is a competitor.
No right to withhold. The vendor may not hold back code and documentation because of a payment dispute, at least for milestones already paid. Money disputes are resolved separately.
It is also worth reserving the right to commission an independent code review during the project. An audit at the end, or at a turning point, tells you exactly what you are taking over. Our technical due diligence includes a Code Health Audit that takes one to two weeks, has a fixed scope and starts from €4,500, and if the system needs stabilising after a vendor change we can continue under Software Rescue.
When does source code escrow make sense?
Source code escrow is a three-party arrangement: the vendor deposits code with an independent agent, and the agent releases it to the client when a defined event occurs, such as the vendor’s insolvency or the end of support. It is sometimes presented as universal protection, but for custom software it is often unnecessary.
If code lands in a repository in your organisation from day one, the IP is assigned and documentation and infrastructure as code are kept current, escrow adds nothing. You already have everything the agent could release, and in its latest version.
Escrow makes sense in three situations. First, when the vendor licenses you its own product or the platform your system is built on and you do not receive its source. Second, when the system is business-critical and the vendor is a small firm whose continuity is hard to judge. Third, when code is delivered in releases rather than continuously, as in some industrial or embedded systems.
If you opt for escrow, check four things: how often the vendor updates the deposit (a deposit a year old is worth little), whether the agent verifies that a working system can be built from it, which events exactly trigger release and what rights you get to use the released code. Without a licence to modify it, released code is just a file.
What does a clause checklist look like before you sign?
The table gathers the clauses discussed above. The “minimum” column is the level below which it is worth stopping and asking the vendor why. The “warning sign” column shows wording that often appears in vendor templates.
| Area | Minimum for the client | Warning sign in the template |
|---|---|---|
| IP | Written assignment (or exclusive grant of rights of use) on payment for each milestone | Non-exclusive licence, rights pass only on final payment |
| Permitted uses | Listed, including modification by third parties, SaaS and sublicensing | ”All rights” with no list of uses |
| Chain of title | Warranty that all authors, including freelancers, assigned rights to the vendor | Nothing on subcontractors or freelancers |
| Components and open source | Component register with licences, perpetual licence to vendor components | ”Supplier Tools” with no list and no licence |
| Acceptance | Criteria, test period, defect classes, consequences of repeated failure | Acceptance at the vendor’s discretion or with no deadline |
| Warranty and SLA | Fix times by severity, measurement method, consequences of breach | Response time only, availability with no definition |
| Liquidated damages | Tied to measurable events, capped, remedy position clear | None, or token amounts while the client carries heavy penalties |
| Liability | Cap with carve-outs: wilful misconduct, confidentiality, data protection, IP infringement | Cap at one month’s fees with no carve-outs |
| Team | Key personnel schedule, replacement rules, consent to subcontractors | ”Suitably qualified personnel” |
| Code access | Repository owned by the client from day one | Code delivered after final acceptance |
| Exit | Handover list, knowledge-transfer hours at an agreed rate, no right to withhold | No clause, or handover “on terms to be agreed” |
| Escrow | Only for licensed products or critical systems without continuous code access | Escrow instead of assignment on a build-from-scratch project |
If three or more areas in the contract in front of you fall into the right-hand column, do not sign that version. It does not mean the vendor is dishonest. It means the contract is the vendor’s template and has not been negotiated yet.
Which terms should you concede, and which should you fight for?
Negotiation has a cost: time, the relationship and often price. A vendor forced to carry every risk will price it in, exactly as it prices contingency for an unclear scope. We explain how vendors turn risk into price in our article on how software houses price a project. So it pays to know where to give way.
Fight for these to the end: IP assignment with permitted uses covering modification by third parties, repository access from day one, an exit clause with a handover list and no right to withhold, chain of title from freelancers, and carve-outs from the liability cap for IP infringement and data protection. Without these you lose control of the system, and a credible vendor has no reason to refuse them.
Negotiate these sensibly: the level and cap of liquidated damages, warranty length, SLA times, notice period, non-solicitation. Here there is a genuine trade-off: higher damages and shorter fix times mean a higher price, and the vendor has legitimate reasons to push back.
You can concede these: the vendor keeping ownership of its generic components (provided you get a good licence), exclusion of liability for loss of profit, deemed acceptance with a realistic deadline, and a reasonable non-solicitation clause. These protect legitimate vendor interests, and fighting them usually costs more than it gains.
If the project runs on a fixed price, the contract also needs a change procedure: who raises a change, who estimates it, at what rates and how quickly. The engagement model and who pays for uncertainty are covered in team subscription, T&M or fixed price.
What are the key takeaways?
A contract with a software vendor does not protect you from a failed project, but it decides whether after a failed project you still have the system, the code and the ability to move on with someone else. The vendor’s template is the starting point for negotiation, not a document to sign.
Remember six things. First, IP does not pass with payment: you need a written assignment, or in Germany an explicit exclusive grant of rights of use, with the permitted uses listed. Second, check the chain of title, because employer-ownership rules do not cover freelancers. Third, define acceptance with criteria, a test period and consequences for repeated failure, and separate code access from acceptance. Fourth, measure the SLA by time to restore service, not just time to respond. Fifth, tie liquidated damages to measurable events, cap them and keep them proportionate, because extreme figures may not be enforceable. Sixth, design exit so that everything sits with you throughout the project, and use escrow only where you have no continuous access to the code.
If you are preparing a contract for custom software development and want to see how these clauses look with us, or you are taking over a system from a vendor whose contract never planned for exit, book a call. We will tell you plainly which clauses we accept as standard, which are worth discussing and what to do if the code is already outside your control.