Software licensing is the contractual mechanism by which the holder of the copyright in a program permits someone else to use it. Under Dutch law a computer program is a protected work in its own right under article 10, first paragraph, point 12 of the Auteurswet (Copyright Act), so every act of loading, copying or adapting it requires either permission or a statutory exception. A licence is that permission, and its scope, duration and conditions are set by the agreement, subject to a small core of rights the licensee cannot be made to give up.
That framework explains almost everything organisations get wrong about software licensing: they treat the licence as a receipt rather than a contract, they assume rights the licence never granted, and they discover the gap during a vendor audit or a migration. This article sets out what Dutch and European law actually give you, what the licence adds or takes away, and which clauses decide your exposure.
What you acquire when you license software
You do not buy software. You acquire a right to use a copy, on the terms of the licence, while the copyright stays with the rights holder. That distinction has practical consequences: you cannot assume you may install the program on a second server, run it for a group company, let a contractor use your account, or keep using it after the agreement ends, unless the licence says so.
Dutch law does not treat every acquisition of software as a pure licence, however. In the De Beeldbrigade judgment of 27 April 2012 (ECLI:NL:HR:2012:BV1301) the Hoge Raad held that the rules on sale in Book 7 of the Civil Code apply to the acquisition of standard software supplied for an indefinite period against a one-off payment, even though software is not a tangible object. The practical effect is that the conformity requirement of the law of sale applies: the software must possess the qualities the buyer was entitled to expect. That is a meaningfully stronger position than a bare contractual warranty, and it is one reason vendors prefer subscription and cloud models, which are services rather than sales.
Where the customer is a consumer, a further layer applies. Book 7 of the Civil Code has contained a separate set of rules on contracts for the supply of digital content and digital services since 1 January 2022, implementing the European directive on that subject. Those rules impose conformity requirements, an update obligation for as long as the consumer may reasonably expect updates, and remedies that cannot be excluded to the consumer disadvantage. Business to business licences are largely left to freedom of contract, which is precisely why the negotiation matters more in that setting.
Who owns software written for you is a separate question that catches many organisations out. Copyright in a program written by an employee in the performance of their duties vests in the employer under article 7 of the Auteurswet. Copyright in a program written by a freelancer or a development agency stays with that party unless it is transferred by a written deed. A commissioning client without a written assignment ends up with an implied licence of uncertain scope, which is discovered at the moment it needs to sell the business or change supplier. Our article on proprietær programvarelisensiering looks at that relationship in more detail.
The rights the law gives you whatever the licence says
European software law reserves a small number of rights to the lawful acquirer, and a clause purporting to exclude them is void. Knowing them changes the balance in a dispute.
Article 45j of the Auteurswet permits the lawful acquirer of a copy to make the reproductions necessary for the intended use of the program. The parties may vary that in the contract, with one exception which cannot be varied: reproduction that takes place in the course of loading the program, displaying it, or correcting errors in it may not be prohibited by agreement. A licence that forbids you from fixing a fault that prevents the software from working as intended is, to that extent, unenforceable.
Article 45k of the Auteurswet allows the lawful user to make a back-up copy where that is necessary for the intended use, and this right too cannot be contracted away. Article 45m permits decompilation, but only under strict conditions: it must be indispensable to obtain the information needed to achieve interoperability with an independently created program, it must be carried out by a lawful acquirer, the information must not already be readily available, and it must be limited to the parts of the program that are necessary for that purpose. Decompiling in order to build a competing product falls outside the exception. The Court of Justice confirmed in Top System (C-13/20, 6 October 2021) that a lawful acquirer may also decompile in order to correct errors that affect the functioning of the program.
One further principle limits what a licence can monopolise. In SAS Institute (C-406/10, 2 May 2012) the Court of Justice held that neither the functionality of a computer program, nor the programming language, nor the format of data files used by it are protected by copyright in the program. What is protected is the expression: the source and object code. Our veiledning i immaterialrett i Nederland places software copyright alongside the other rights a technology business relies on. A competitor who studies what your software does and writes their own implementation is not infringing your copyright, however unwelcome that is.
Proprietary, open source and copyleft licences
Licences fall into three families, and the difference between them is not ideological but operational: it determines what you must disclose and what you may charge for.
Proprietary licences
A proprietary licence keeps the source code closed and grants a defined, usually non-exclusive and non-transferable, right of use. The restrictions are the substance of the agreement: a maximum number of named users or devices, a permitted environment, a prohibition on sublicensing, and a prohibition on reverse engineering that is only effective to the extent it does not collide with the statutory rights described above. The vendor controls updates, support and pricing, and the customer bears the migration cost if the product is discontinued or the terms change. That dependency is a contractual risk, and it is managed by negotiating notice periods, price-increase caps, continuity arrangements and, for business-critical systems, a source code escrow.
Permissive open source licences
Open source licences are copyright licences, not a waiver of copyright, and they are enforceable in the same way as any other licence: breach the conditions and you lose the permission, leaving you infringing.
Permissive licences such as MIT, BSD and Apache 2.0 impose few obligations. You may incorporate the code in a commercial product, including one you distribute in binary form only, provided you reproduce the copyright notice, the licence text and the disclaimers. Apache 2.0 adds an express patent licence and a requirement to state that you changed the files. These obligations are easy to satisfy and easy to overlook, and an omitted notice file is the most common open source compliance failure in practice.
Opphavsrettslisenser
Copyleft licences, of which the GNU General Public License is the best known, attach a condition to distribution: whoever receives the binary must also be able to obtain the corresponding source, under the same licence. If you modify GPL code and distribute the result, the copyleft obligation extends to the work as a whole, which can mean disclosing code you intended to keep proprietary. Using GPL software internally, without distributing it, does not trigger the obligation, but the Affero variant of the GPL treats making the software available over a network as equivalent to distribution, which is precisely the situation of a SaaS provider.
The Lesser GPL occupies a middle ground: you may link proprietary code to an LGPL library without opening your own code, provided the user can replace the library with a modified version. Whether static linking satisfies that condition is a question that deserves advice before, not after, the release.
For a company that ships software, the practical answer is a written open source policy, an inventory of every component and its licence, and an automated check in the build pipeline. The inventory is also what an acquirer will ask for during due diligence, and its absence reliably reduces the purchase price.
Licensing models and what they mean legally
The licence type says what you may do with the code. The licensing model says how you pay and how usage is measured, and it determines where the compliance risk sits.
A named-user or per-seat licence is tied to an identified individual. Sharing a named account between two employees is a breach even where the two never work at the same time, and it is the violation vendors detect most easily. A concurrent or floating licence limits the number of simultaneous users and is enforced by a licence server; here the risk is not sharing but exceeding the peak. A per-device or per-core licence is measured against hardware, and virtualisation is where it goes wrong: running a licensed instance on a cluster can, under the metrics of some vendors, be treated as licensing every physical core in that cluster. Read the metric definition, not the price list.
The choice between a perpetual licence and a subscription is legal as well as financial. A perpetual licence gives an indefinite right to use a specific version; support and new versions come from a separate vedlikeholdsavtale, and letting that agreement lapse does not remove the right to keep using what you have. A subscription grants use only for as long as you pay, so the end of the contract is the end of your access; the questions to settle in advance are what happens to your data, in what format it is returned, and for how long the vendor will assist with the exit.
Cloud and on-premises deployment raise different issues again. With software running on the vendor infrastructure you are buying a service, and the agreement should address availability, support response times, subcontractors, the location of the data and the consequences of termination. Where personal data is processed you also need a data processing agreement meeting the requirements of article 28 of the GDPR; a licence agreement does not do that job. Our article on the skykontrakt i Nederland sets out what that contract must cover.
Can you resell or transfer a software licence
Sometimes, and the answer follows a clear European line. In UsedSoft (C-128/11, 3 July 2012) the Court of Justice held that where a rights holder makes a copy of a program available for download and grants, against payment of a fee, a right to use that copy for an unlimited period, it has sold that copy. The distribution right in that copy is then exhausted, and the rights holder cannot oppose its resale, even though the copy was never on a disc. The first acquirer must make its own copy unusable at the moment of resale, and a licence for a defined number of users may not be split up and sold in parts.
The limits matter as much as the rule. Exhaustion applies to a perpetual licence sold for a lump sum, not to a subscription or a service. The Court confirmed in Tom Kabinet (C-263/18, 19 December 2019) that the supply of an e-book by download for permanent use is a communication to the public rather than a distribution, so no exhaustion arises; the software judgment rests on the specific provisions of the Software Directive and does not extend to other digital works. Maintenance and support contracts do not transfer with the licence unless the vendor agrees.
In practice a licence that has been sold on this basis is transferable notwithstanding a contractual prohibition, but everything around it is negotiable. Before buying second-hand licences, ask for the chain of title, the original invoice, and a written confirmation from the seller that its copies have been deleted.
Vendor audits and what a Dutch company has to accept
Most enterprise agreements contain an audit clause, and vendors use them. The clause is what gives the vendor its rights, so it is the first document to read when a notification arrives.
A typical audit begins with a letter announcing an audit and asking for deployment data, purchase records and system reports within a set period. You are bound by what the clause provides and no more. A well-drafted clause limits audits to once a year, requires reasonable notice, restricts the exercise to normal business hours, obliges the auditor to sign a confidentiality undertaking, provides that the vendor bears the cost unless a material shortfall is found, and confines the scope to the products actually licensed. Where the clause is silent, the requirements of reasonableness and fairness under article 6:248 of the Civil Code fill the gap, and they do not entitle a vendor to unrestricted access to your systems.
Three practical rules apply. Do not hand over raw data before you have run the measurement yourself; the discussion is almost always about how usage is counted rather than about what is installed. Route all communication through one person and confirm every agreement in writing. And keep the exercise within the contract: an auditor asking for access to systems outside the licensed products, or for personal data of employees, is asking for something the clause does not give, and the GDPR applies to that request as much as to any other.
Where a shortfall is genuine, the claim of the vendor is a contractual one for the licences that should have been bought, and there is usually room to negotiate: a forward-looking purchase instead of retroactive fees, waiver of penalties in exchange for a longer term, or a migration to a different metric. Where the vendor threatens copyright proceedings, it must prove infringement of specific rights, and the remedies available to it are those of the Auteurswet, including the possibility of recovering the full legal costs of intellectual property proceedings. Our article on enforcing intellectual property rights in the Netherlands describes that route, and a dispute of this kind often starts with a opphør og avstå brev.
The violations that appear in audit reports are consistent: installations that grew after the original deployment without matching purchases, accounts of departed employees left active, named-user licences shared between people, upgrades installed without upgrade rights, production use of a development or test licence, and virtual environments counted differently from what the customer assumed. Each of them is preventable by an accurate register of entitlements and deployments, reconciled at least annually. Keeping that register is also part of general lovlig overholdelse innenfor organisasjonen.
The clauses that decide your risk
Most software licences are presented as non-negotiable. For an off-the-shelf tool that is usually true and usually acceptable. For anything the business depends on, five clauses deserve real attention.
The scope of the grant comes first. It should state who may use the software, including group companies, contractors and outsourcing providers; on which environments, including test, disaster recovery and backup instances; and in which territories. A grant that is narrower than the way you actually operate is a shortfall waiting to be discovered.
The second is the limitation of liability. Under Dutch law such a clause is valid in a business relationship, but it can be set aside where reliance on it would be unacceptable according to the standards of reasonableness and fairness, and it will not protect a party whose own intent or deliberate recklessness caused the damage. What matters is the fit: a cap set at the annual fee is defensible for a low-value tool and indefensible for a system whose failure stops production. Look separately at whether indirect and consequential loss is excluded, because that exclusion often removes the loss that would actually hurt.
The third is the intellectual property indemnity. If a third party claims that the software infringes its rights, the customer is the one being sued for using it. A proper indemnity obliges the vendor to defend the claim and to pay the resulting damages and costs, and gives it the option to procure a licence, modify the software or refund a proportionate part of the fee. Watch for indemnities that are capped at the same low figure as the general liability clause, which makes them close to worthless.
The fourth is continuity. What happens if the vendor stops supporting the product, is taken over, or becomes insolvent? A source code escrow with a clear release trigger is the usual answer for on-premises software, and for cloud services the equivalents are an exit plan, agreed data formats and a defined transition period. Insolvency deserves attention because the position of a licensee in a Dutch bankruptcy is not straightforward: the trustee is not obliged to continue performing, and the more the service depends on the vendor doing something rather than merely tolerating your use, the more exposed you are.
The fifth is the change clause. Vendors routinely reserve the right to amend product terms, metrics or documentation unilaterally. Accepting that without limits means accepting a price and a scope you have not yet seen. A workable compromise ties changes to a notice period and gives the customer a right to terminate without penalty if the change is materially adverse. General guidance on negotiating these documents is set out in our article on kontrakter og avtaler.
What to do before you sign, and what to do every year
Before signing, map the way the software will actually be used against the words of the grant, and settle the difference in the contract rather than in an email from a sales representative. Establish which metric applies and how it is measured, in writing, with a worked example for your own environment. Confirm whether the arrangement is a perpetual licence or a subscription, and what you keep at the end. Check the audit clause, the liability cap, the indemnity and the change clause against the value of the system to the business.
After signing, the work is administrative and it is what prevents disputes. Keep a single register of entitlements: contracts, order forms, invoices, licence keys, metrics and renewal dates. Reconcile it against actual deployments at least once a year, and always after a reorganisation, an acquisition or a migration to virtual or cloud infrastructure, because those are the events that create shortfalls. Remove the accounts of people who have left. Keep the open source inventory current alongside it. None of this is difficult, and all of it is far cheaper than the alternative.
Law & More advises businesses in the Netherlands on software licensing, development and SaaS agreements, open source compliance, and disputes with software vendors, including audits and infringement claims. We review and negotiate licence terms, assess your position when a vendor makes a claim, and act in proceedings where a settlement is not available. If you would like your software contracts reviewed, please contact our lawyers.
