A collaboration agreement under Dutch law between a developer and a contractor is a contract that settles four things before the work starts: what exactly is to be delivered, who owns the result, when and how payment falls due, and what happens if the project changes or goes wrong. Dutch law does not fill those gaps in the way most parties expect. Intellectual property stays with the maker unless it is transferred by a written deed, and the rules on extra work and on defects after delivery apply whether or not the contract mentions them.
This article sets out the legal framework that governs such agreements in the Netherlands: the two contract types the Civil Code recognises, the ownership rules in the Auteurswet and the other intellectual property statutes, the treatment of extra work, and the liability regime that applies after delivery. It is written for commissioning parties, software developers, design agencies and building contractors working on Dutch projects.
Which contract are you actually signing

Dutch law knows two contract types for commissioned work, and the difference decides several questions the parties rarely discuss. An overeenkomst van opdracht (contract for services, article 7:400 of the Burgerlijk Wetboek) covers work that consists of services: development capacity, advice, design hours. Aanneming van werk (contract for work, article 7:750 BW) covers the creation of a work of a material nature for a price, which is the standard form for construction and for fixed-price delivery of a defined result.
The consequences are practical. Under article 7:408 BW the client may terminate an opdracht at any time; under article 7:764 BW the principal may likewise terminate a contract for work at any time, but then owes the full agreed price less the savings the contractor makes as a result. If no price has been agreed, article 7:752 BW imposes a reasonable price, which in a dispute means an expert argument rather than a clear answer. Article 7:754 BW obliges the contractor to warn the client about inaccuracies in the assignment and about defects in materials or plans supplied by the client, and that duty applies even where the contract is silent.
Naming the contract correctly in the first article, and stating whether it is a fixed price or a rate-based engagement, therefore does real work. Our overview of the types of commercial agreement under Dutch law shows where each form fits.
Who owns the result: intellectual property under Dutch law

The default rule is the one that surprises clients most often: the person who creates a work holds the copyright, and paying for the work does not change that. Under article 2 of the Auteurswet (Copyright Act) copyright can be transferred, and both a transfer and an exclusive licence require a deed, meaning a signed written document intended for that purpose. A purchase order, an invoice marked paid in full or an email confirming the fee does not transfer anything.
There is one important exception and one near miss. Article 7 Auteurswet treats the employer as the maker of works created by an employee in the performance of the employment contract, so code written by staff belongs to the company automatically. That article does not extend to freelancers, contractors or agencies, which is precisely the relationship this kind of agreement covers. Article 8 Auteurswet treats a legal person as the maker where it publishes a work as its own without naming a natural person, but relying on that instead of a proper transfer clause is a poor substitute.
Moral rights (persoonlijkheidsrechten, article 25 Auteurswet) sit apart from all of this. They cannot be transferred; a maker may waive some of them in writing, such as the right to be named, but not the right to oppose a distortion of the work that harms his reputation. A well-drafted clause therefore transfers the exploitation rights, records which moral rights are waived, and settles whether the developer may name the project in a portfolio.
Other rights follow their own statutes. Patents for technical inventions are granted under the Rijksoctrooiwet 1995 and administered by Octrooicentrum Nederland at RVO; trademarks and design rights in the Netherlands run through the Benelux Convention on Intellectual Property or the corresponding EU registrations; and structured data sets can attract a separate sui generis right under the Databankenwet. Our guide to intellectual property law in the Netherlands explains how these regimes interact, and RVO offers a free IP scan for businesses mapping their position.
Software: source code, licences and the rights the user keeps anyway
Software development agreements need one decision made explicitly: does the client acquire the copyright in the code, or a licence to use it. Both are defensible, and the price should reflect the choice, but leaving it open means the developer keeps the rights and the client is left with an implied licence of uncertain scope.
Even where the developer retains ownership, Dutch law gives the lawful user a floor that a contract cannot fully remove. Article 45j Auteurswet allows the person entitled to use a computer program to make the reproductions necessary for its intended use, including correcting errors, and the statute limits how far that can be contracted away. Related provisions permit a back-up copy and, on strict conditions, decompilation to achieve interoperability with other systems. A clause that purports to forbid all of this is not enforceable in full.
Three further points belong in the drafting. First, third-party and open-source components: the developer should warrant which licences are used, because a copyleft component in a delivered product can oblige the client to publish its own source code. Second, escrow: where the client depends on software it does not own, a source code escrow arrangement with release conditions is the standard answer to the risk of the developer disappearing. Third, maintenance and support belong in a separate schedule with response times, not in a single sentence about reasonable efforts. Our articles on how software licensing works and on the IT services agreement deal with these clauses in detail.
Changes to the work and the price of extra work

Almost every project changes, and Dutch law regulates what that costs. Article 7:755 BW is the key provision: where the client requires additions or changes to the agreed work, the contractor may claim an increase in price only if he has warned the client in good time about the need for that increase, unless the client should have understood the need without being told. Contractors who carry out extra work on a verbal instruction and invoice it afterwards regularly lose that argument.
Article 7:753 BW deals with the reverse situation: cost-increasing circumstances that arise after the contract was made and are not attributable to the contractor may justify an adjustment of the price by the court, again subject to a duty to warn. The workable answer for both parties is a written change procedure: every variation recorded in a short order stating scope, price effect and new deadline, signed before the work is done. That single habit prevents more disputes than any other clause in the contract.
Delivery, defects and liability after the work is finished
Delivery (oplevering) is the moment the risk shifts, and it deserves a clause of its own: who inspects, within what period, on what criteria, and what counts as acceptance if the client says nothing. For contracts for work the Civil Code sets the framework in article 7:758 BW. The rule changed with the Wet kwaliteitsborging voor het bouwen: for construction contracts entered into on or after 1 January 2024, article 7:758 paragraph 4 BW makes the contractor liable for defects that were not discovered at delivery, unless those defects cannot be attributed to him. Departure from that rule is possible with a professional client only if it is expressly agreed in the contract, and not at all with a consumer client.
After delivery, time matters. A client who discovers a defect must complain within a reasonable period under article 6:89 BW, and a claim in respect of a defect in the delivered work is subject to a short limitation period running from that protest, so a complaint parked in a drawer can extinguish an otherwise sound claim. Where the work is defective, the ordinary remedies of Book 6 apply: damages for non-performance under article 6:74 BW, usually after a notice of default, and dissolution of the contract under article 6:265 BW where the breach is serious enough. What your options are when work is delivered badly is set out in our article on what to do when a contractor delivers poor work.
Liability itself is usually capped by contract. Dutch courts accept limitation and exclusion clauses in commercial relationships, but they will set one aside where relying on it is unacceptable by standards of reasonableness and fairness, and typically where the damage was caused deliberately or by conscious recklessness on the part of management. A cap tied to the contract value, combined with an exclusion of indirect loss and a matching insurance policy, is more robust than a blanket exclusion of all liability. Where the terms are used repeatedly, they are general terms and conditions and must be handed over before or at the moment the contract is concluded, or the other party can annul them.
The clauses a collaboration agreement should contain

Beyond the statutory framework, a workable agreement settles a fixed set of questions. The scope of work belongs in an annex written in the language of the project, not in a marketing summary, and should state what is expressly excluded. Milestones and deadlines need a consequence attached to them, whether a penalty, a right to suspend payment or nothing at all, because a deadline without a consequence is a plan rather than an obligation. Payment terms should say when an invoice becomes due, what the interest is on late payment, and whether the final instalment is released only on acceptance.
Confidentiality should cover what is shared in both directions and survive the end of the project. Termination deserves two regimes: termination for convenience with a notice period and a settlement of work in progress, and termination for cause on defined grounds. Personnel clauses, such as a prohibition on hiring each other staff, must be limited in time and scope to stand up. And where the parties are in different countries, the contract should state the applicable law and the competent court or arbitral institute; without a choice, the applicable law follows the Rome I Regulation and jurisdiction the Brussels I bis Regulation, which rarely produces the forum either party would have picked.
Signing can be done electronically. Article 3:15a BW gives an electronic signature the same effect as a handwritten one where the method used is sufficiently reliable for the purpose, and the eIDAS Regulation defines the advanced and qualified variants that carry the strongest evidential position. For a transfer of copyright, which requires a deed, use a signature method whose reliability you can demonstrate later rather than a scanned image pasted into a document.
Mistakes that cost the most
The recurring failures in these projects are few and predictable. Assuming that payment buys ownership is the first: without a deed, the developer keeps the copyright and the client holds an implied licence at best. Assuming article 7 Auteurswet applies to a freelancer is the second, and it is the same mistake wearing different clothes. The third is carrying out extra work on a verbal request without a written variation, which under article 7:755 BW puts the contractor at risk of doing the work for nothing.
Then come the procedural ones: no acceptance criteria, so the parties argue about whether the work was ever delivered; a complaint made months after a defect surfaced, which weakens or extinguishes the claim; and general terms that were never handed over and can therefore be annulled. None of these are difficult to prevent, but each is expensive to litigate afterwards.
How Law and More can help
Law and More B.V. drafts and reviews collaboration agreements for software developers, design agencies, contractors and the businesses that engage them, and acts in the disputes that arise when a project runs off course. We work in Dutch and in English and can be reached through the Law and More website. If you would like a contract checked before it is signed, or an existing project assessed, please contact us.
Frequently asked questions
Who owns the intellectual property in a collaboration between a developer and a contractor?
Under Dutch law, if the contract does not clearly transfer the rights, the creator keeps the copyright even after being paid for the work. This is a common source of disputes, so a contract should explicitly state the transfer of rights to avoid confusion about who owns the finished work.
What key elements should a collaboration agreement between developers and contractors include?
Every contract should clearly define the scope of work, set deadlines and milestones, spell out who owns the work once it is completed and how it may be used, and cover payment terms. In the Netherlands, the transfer of intellectual property rights must be stated explicitly, since it does not happen automatically.
How should a contract handle changes to the project scope during the work?
Since projects rarely go exactly as planned, the contract should explain how change requests will be handled, including how new prices and deadlines are set, and address what happens if the project slows down or speeds up unexpectedly. Being clear about this upfront helps avoid disputes over extra work and additional costs later.
What Dutch laws govern collaboration agreements between developers and contractors?
The Dutch Civil Code (Burgerlijk Wetboek), particularly Books 6 and 7, sets out the general rules for these contracts, alongside relevant intellectual property legislation and European regulations, all designed to protect both the creator and the party who hires them.
What practical steps help keep a developer-contractor collaboration running smoothly?
Beyond a solid contract, clear communication and careful project management make a significant difference. Regular check-ins, honest discussions, and using project tracking tools help ensure everyone understands what is expected from the start, reducing the likelihood of disputes.


