An open source licence is a copyright licence with conditions: under the Dutch Copyright Act (Auteurswet, Aw) you may copy, modify and distribute the software only as long as you comply with those conditions. If you do not comply, your use falls outside the licence and is copyright infringement, which can lead to an injunction, a recall and an order to pay the other side’s full legal costs.
Almost every commercial software product contains hundreds of open source components, usually chosen by developers rather than lawyers. The risk lies in copyleft licences (such as the GPL and AGPL), which can require you to release your own source code when you distribute the software, and in the basic attribution duties that every licence imposes. This article explains how these licences work under Dutch and EU law, and what to have in place.
Table of contents
What is an open source licence in legal terms?
It is a non-exclusive licence under Article 2(2) of the Copyright Act: the author keeps the copyright and gives you permission subject to conditions. Computer programs are protected as works under Article 10(1)(12°) Aw, and the licence permits acts that would otherwise infringe the exclusive rights to publish and reproduce (Articles 12 and 13 Aw), see also our article on software licences under Dutch law.
No signature is needed. Article 2(3) Aw only requires a written agreement for a transfer of copyright or an exclusive licence, so a non-exclusive open source licence is accepted by using the software. Most copyleft licences end automatically on breach: GPLv2 has no cure period, while GPLv3 and AGPLv3 restore your rights if you cure the breach within a set period after notice.
Dutch courts follow this reasoning. In interim relief proceedings, the Amsterdam District Court held that a company that removed the licence text and copyright notice from a forked codebase had lost its permission and was likely infringing copyright. Adding some 400,000 lines of code did not by itself create a new, independent work (Rechtbank Amsterdam 22 September 2020, ECLI:NL:RBAMS:2020:4717).
What is the difference between permissive and copyleft licences?
Permissive licences let you use the code in closed-source products as long as you keep the notices; copyleft licences require you to distribute derived software under the same licence, with source code. The table shows the four main families.
| Family | Typical licences | Core obligation | Triggered by | Combine with proprietary code? |
|---|---|---|---|---|
| Permissive | MIT, BSD-2/3, Apache 2.0 | Keep copyright notices, licence text and disclaimers; Apache also requires change notices | Distribution in source or binary form | Yes |
| Weak copyleft | MPL 2.0, LGPL 2.1/3, EPL 2.0 | Source of the covered files or library; LGPL also requires that the library can be replaced | Distribution of the covered files or library | Yes, with care at the boundary |
| Strong copyleft | GPLv2, GPLv3, EUPL 1.2 | Same licence for the whole combined work; complete corresponding source | Distribution; for the EUPL also providing access to essential functionalities | No, unless genuinely separate |
| Network copyleft | AGPLv3 | As GPLv3, plus source for remote users over a network | Distribution, or offering a modified version as a service | No |
When does copyleft apply, and what about linking?
Copyleft applies when you distribute the software, not when you use it. A company running GPL software internally, however heavily modified, distributes nothing and owes nothing; containers, appliances, firmware, mobile apps and SDKs supplied to customers are distribution.
The harder question is when your own code becomes part of the copyleft work. The GPL uses the American concept of a “work based on the Program”. Dutch law has no such term: it asks whether protected expression from the original has been reproduced or adapted (Article 13 Aw).
No Dutch court has decided whether linking a proprietary module to a GPL library creates one combined work, and there is no binding EU ruling on the point. The popular rule that dynamic linking is safe and static linking is not has no basis in Dutch copyright law. A more defensible test asks how closely the components are combined: do they share memory and data structures, are they shipped as one product, can either work alone, and does your code copy headers or inline code from the copyleft side? Where the answer is unclear, isolate the component behind a process boundary, replace it, or buy a commercial licence.
How does the AGPL affect SaaS?
The AGPL closes the gap for software offered as a service. If you modify AGPL software and let users interact with it remotely, you must offer those users the source code of your modified version.
Three points are often missed. The obligation runs to every user of the service, which in an open-signup product means anyone. It is triggered by modification, so a patched build can engage it while an unmodified one does not. And it raises the same combined-work question as the GPL for the rest of your stack, which is why many companies prohibit AGPL code in production.
Which licences can be combined?
Permissive licences are compatible with nearly everything; copyleft licences only with what their own terms allow. The standard example is Apache 2.0 and GPLv2: the Apache Software Foundation and the Free Software Foundation both take the view that they cannot be combined, because Apache’s patent clauses are additional restrictions that GPLv2 does not allow.
GPLv3 was written to accept them, but compatibility only works one way: Apache code can go into a GPLv3 project, not the other way round. One GPL component in the wrong place can force you to relicense, re-engineer or remove it, which is much cheaper before release than after.
What are the attribution and patent obligations?
Every licence family, including MIT and BSD, requires you to reproduce the copyright notices, licence texts and disclaimers in the materials that come with the distribution; Apache 2.0 also requires the contents of the NOTICE file. These are the most frequently breached obligations, and the Amsterdam case above turned on exactly this failure. The usual fix is a generated attribution file shipped with every product.
MIT and BSD say nothing about patents. Apache 2.0 and GPLv3 contain an express patent licence from each contributor, combined with a retaliation clause: if you start patent litigation claiming the software infringes your patent, your licence ends. For companies with patents, this means your engineers’ contributions grant licences under your patents, and asserting patents against users of the same software can cost you a licence you rely on.
What does the EUPL mean for public-sector work?
The European Union Public Licence (EUPL) version 1.2, adopted by the European Commission in 2017, is a copyleft licence designed for public authorities. It has three distinctive features:
- Language: it exists in all official EU languages, all with equal value, so a Dutch authority can use the Dutch text.
- Compatibility: an appendix lists compatible licences, including GPLv2 and v3, AGPLv3, LGPL and MPL 2.0, and allows a combined work to be distributed under that other licence.
- Reach: its definition of distribution includes providing access to the software’s essential functionalities, so it also covers software offered as a service.
Dutch government policy favours open source (“open, tenzij”), but this rests on cabinet policy rather than a statutory duty. If a tender requires the EUPL, that requirement binds your deliverable and may be incompatible with proprietary code you planned to reuse, so read the tender documents before you bid.
How is an open source licence enforced in the Netherlands?
A Dutch court treats it as a copyright case: the rightholder proves ownership and copying, you rely on the licence, and the rightholder shows that you did not meet its conditions. Contractual claims can run in parallel, but copyright is the stronger route.
Only the rightholder can sue: the individual contributor, or the foundation or company that holds the copyright. Fragmented authorship is a practical obstacle, because the claimant must prove ownership of the specific code at issue; in the Amsterdam case above, the court left the size of the claimant’s share for the main proceedings.
The remedies are considerable:
- an injunction under Article 3:296 of the Dutch Civil Code (BW), usually with a penalty payment and available in summary proceedings (kort geding);
- damages under Article 27 Aw and surrender of profits under Article 27a Aw;
- recall, surrender or destruction of infringing copies under Article 28 Aw;
- an order to pay the winning party’s reasonable and proportionate legal costs under Article 1019h of the Code of Civil Procedure (Rv).
Where software was distributed free of charge, damages are hard to quantify. What usually hurts is the injunction, the recall, the costs order and having to publish source code you never meant to publish.
What do you do when you find a compliance problem?
Problems usually surface through a customer’s security questionnaire, a scan during due diligence or a letter from a rightholder. Act in this order:
- Stop distributing the affected build if the exposure is serious.
- Establish which component, version and licence is involved, and in which products and releases.
- Work out what the licence actually requires: often an attribution file, not a source release.
- Prepare the notices, licence texts and, where needed, the complete corresponding source code including build scripts.
- Ship a compliant release and inform the rightholder of what you have done.
Under GPLv3 and AGPLv3 the cure period makes speed legally valuable; under GPLv2 there is no cure right, so most cases end in a negotiated compliance undertaking. Legal privilege covers advice from your lawyer (advocaat), not an internal engineering report.
Why does open source matter in M&A and due diligence?
An undisclosed copyleft component in the core product is one of the few findings that genuinely changes a deal: if the product cannot be distributed without releasing its source, the buyer is acquiring a different asset from the one it priced.
Expect a code scan, a component inventory with licences, and questions about contributor and contractor agreements. Typical outcomes are a specific indemnity, a retention until remediation, a condition precedent requiring removal, or a specific open source warranty. Sellers should scan first: findings you disclose are a negotiation point, findings the buyer makes are leverage.
What does the Cyber Resilience Act require?
The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024 and applies in phases. The duty for manufacturers to report actively exploited vulnerabilities and severe incidents (Article 14) applies from 11 September 2026; the rest of the Regulation applies from 11 December 2027 (Article 71(2)).
Manufacturers must draw up a software bill of materials (SBOM): an inventory of the components in the product. It does not have to be published, but market surveillance authorities can request it. The Regulation sits alongside the Dutch Cybersecurity Act, which addresses organisations rather than products.
Free and open source software supplied outside a commercial activity falls outside the CRA. Organisations that systematically support open source intended for commercial use (open-source software stewards) have a lighter regime, and under Article 64(10) no fines can be imposed on them. If you commercialise open source or fund a project that others commercialise, establish which role you have. Software composition analysis tools help build the inventory, but they miss copied-in code and misread dual licences, so treat their output as the start of the review.
Do you need a CLA or a DCO for your own project?
If you publish your own code and accept outside contributions, you must be sure you have the rights to what you merge. A contributor licence agreement (CLA) gives the project a broad copyright and patent licence, which allows later relicensing or dual licensing; a Developer Certificate of Origin (DCO) is only a sign-off confirming the contributor may submit the code under the project’s licence.
If dual licensing or a future change of licence is plausible, use a CLA; for a genuine community project, the DCO is usually enough. Either way, make sure your employment and contractor agreements transfer the copyright in code your people write: a transfer of copyright must be in writing under Article 2(3) Aw.
What should you check as a company that uses open source?
As a company that builds products on open source, check these points:
- Does your build pipeline generate a component inventory per product and release?
- Do you have an internal policy with permitted and prohibited licences and an approval route?
- Have you defined in writing what counts as distribution: installs, appliances, containers, SDKs, apps, firmware?
- Does every product ship with a complete attribution file?
- Is any AGPL or GPL code combined with proprietary code you do not intend to release?
- Do your customer contracts’ IP warranties match the open source actually in the product?
What should you check as a company that publishes open source?
As a company that publishes its own code under an open source licence, check these points:
- Do you hold the copyright, through written transfers from employees and contractors?
- Have you chosen a CLA or DCO before the first outside contribution?
- Does your chosen licence fit your business model, including any future dual licensing?
- Have you approved contributions to external projects, given the patent licences they grant?
- Are you a manufacturer or an open-source software steward under the Cyber Resilience Act?
What can we do for you with open source licences?
Our IT lawyers advise software companies and their investors on open source compliance and disputes.
- We review your component inventory and identify the licences that create copyleft or attribution obligations.
- We draft your internal open source policy and your CLA or contributor terms.
- We review IP warranties, indemnities and escrow terms in customer and supplier contracts.
- We run the open source workstream in due diligence for a sale, acquisition or investment round.
- We respond to a rightholder’s claim and negotiate a compliance undertaking, or act in summary proceedings.
Summary
- An open source licence is a non-exclusive copyright licence; breaching its conditions is copyright infringement under the Auteurswet.
- Copyleft obligations are triggered by distribution, and under the AGPL also by offering modified software as a service.
- Attribution duties apply to every licence and are the most frequently breached.
- Remedies include an injunction, recall under Article 28 Aw and full legal costs under Article 1019h Rv.
- The Cyber Resilience Act requires an SBOM; its reporting duty applies from 11 September 2026 and the rest from 11 December 2027.
Frequently asked questions
Does using open source software mean we have to publish our own source code?
Only if a copyleft licence applies and you trigger it. Permissive licences such as MIT and Apache 2.0 never require it. Copyleft licences require it when you distribute a work containing the copyleft code; the AGPL also when you offer modified software as a network service. Internal use without distribution creates no obligation.
Is the MIT licence enforceable in the Netherlands without a signature?
Yes. It is a non-exclusive copyright licence, and Article 2(3) of the Copyright Act only requires writing for a transfer or an exclusive licence. If you do not meet its conditions, your use falls outside the permission and is copyright infringement.
We are a SaaS business: can we ignore copyleft?
Not entirely. Hosting is not distribution, so most GPL obligations do not apply. But the AGPL covers modified software made available to remote users, the EUPL covers access to essential functionalities, and any downloadable client or on-premise agent is distribution.
Does the Cyber Resilience Act require us to publish our SBOM?
No. Manufacturers must draw up a software bill of materials, and market surveillance authorities can request it, but there is no duty to publish it. The reporting duty applies from 11 September 2026 and the rest of the Regulation from 11 December 2027.
