Open source software licences under Dutch and EU law

Almost every commercial software product contains open source components, usually hundreds, chosen by developers rather than lawyers. That becomes a problem when nobody can say which licences apply, what they require, and whether the product complies. This article explains how open source licences work under Dutch and EU law, where the risk sits, and what to have in place.

What an open source licence is, in legal terms

An open source licence is a copyright licence granted subject to conditions. It is not a waiver, not a dedication to the public domain, not an abandonment of rights. The author retains copyright under art. 1 Aw and art. 10 Aw, which protects computer programs as works, and the licence permits acts that would otherwise infringe the exclusive rights under art. 12 Aw and art. 13 Aw.

The consequence matters more than the definition. Comply, and your copying and distribution are lawful. Fail to comply, and the permission does not cover what you did: your use is copyright infringement, not breach of contract. Most copyleft licences reinforce this by terminating automatically on breach — GPLv2 without any cure period, while GPLv3 and AGPLv3 reinstate rights if the breach is cured within a defined window after notice.

Dutch courts apply this reasoning. In Rb. Amsterdam 22 September 2020, ECLI:NL:RBAMS:2020:4717, a distributor that removed the licence text and copyright notice from a forked codebase was held to have lost its permission and to be infringing. Adding a large volume of new code did not create an independent work: the original remained recognisably present, so the obligations travelled with it.

The two families: permissive and copyleft

Permissive licences — MIT, the BSD licences, Apache 2.0 — allow use, modification and redistribution, including inside closed-source products, provided you preserve copyright notices and licence text.

Copyleft licences require that when you distribute the software, or something built on it, you do so under the same licence and make corresponding source available. They differ in reach.

The copyleft trigger and the linking question

Copyleft obligations bite on distribution, not on use. A company running GPL software internally, however heavily modified, distributes nothing and owes nothing. “Have we distributed?” is always the first question, and it is why containers, appliances, firmware and SDKs matter more than internal tooling.

The second question is harder. The GPL speaks of a “work based on the Program”, borrowing the American concept of a derivative work. Dutch law has no such term: the analysis runs through the reproduction and adaptation rights, asking whether protected expression from the original has been reproduced.

The practical case is linking. Whether linking a proprietary module to a GPL library creates one work subject to copyleft has never been decided by a Dutch court, and there is no binding EU authority. The Free Software Foundation’s view that linking creates a combined work is the licence steward’s interpretation, not law, and the opposing view is equally untested. The internet’s favourite answer — dynamic linking safe, static linking not — has no basis in Dutch copyright law, which does not ask how a compiler behaves. A more defensible analysis asks how intimately the components are combined: do they share an address space and data structures, is the combination shipped as one product, could either function alone, does the proprietary side reproduce headers, macros or inline code from the copyleft side? Those questions usually resolve the risk. Where they do not, isolate the component behind a process boundary, replace it, or take a commercial licence.

AGPL and network use

The AGPL exists because copyleft is triggered by distribution and SaaS providers do not distribute. Its network clause requires that if you modify the software and make it available to users interacting with it remotely, you offer them the corresponding source of your modified version.

Three points are commonly missed. The obligation runs to users of the service, which in an open-signup product is little comfort. It is triggered by modification, so an unmodified component does not engage it but a patched build may. And it raises the same combined-work question as the GPL for the rest of your stack — which is why many companies prohibit AGPL in production code.

Licence compatibility

Compatibility is the problem of combining components whose licences impose obligations that cannot both be met in one distribution: permissive licences are compatible with nearly everything, copyleft licences only with what their own terms allow. The standard case is Apache 2.0 and GPLv2. The Apache Software Foundation and the Free Software Foundation agree the combination is not permitted, because Apache 2.0’s patent termination and indemnification provisions are additional restrictions GPLv2 does not allow. GPLv3 was drafted to accept them. Compatibility is also directional: Apache code can be absorbed into a GPLv3 project, but not the reverse. One GPL component in the wrong place can force a choice between relicensing, re-engineering or removal — far cheaper before release than after.

Attribution and notice obligations

The most frequently breached obligations are the least dramatic: reproducing copyright notices, licence texts, disclaimers and, under Apache 2.0, NOTICE contents in the materials accompanying the distribution. Every family imposes them, MIT and BSD included. They are breached because nobody owns them, and are easiest to fix — usually a generated attribution file shipped with the product. The Dutch case above turned on exactly this failure.

Patent grants and patent retaliation

MIT and BSD say nothing about patents, and whether a patent licence can be implied is unsettled. Apache 2.0 added an express, royalty-free patent licence from each contributor, paired with a retaliation clause: bring patent litigation alleging that the work infringes and your patent licence terminates. GPLv3 contains a comparable grant and its own patent provisions.

Two implications for companies with patent portfolios. If your engineers contribute to Apache- or GPLv3-licensed projects, you are granting licences under your own patents. And if you ever assert patents against a company depending on the same Apache-licensed components you use, retaliation may cost you a licence you rely on.

The EUPL and the Dutch public sector

The European Union Public Licence version 1.2, approved by the European Commission by implementing decision in May 2017, is an OSI-approved copyleft licence with three distinguishing features.

• Language. It exists in the official EU languages, all approved versions having identical value, so a Dutch authority can contract in Dutch.
• Compatibility. An appendix lists compatible licences — GPLv2 and v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL and CeCILL among them — and allows a derivative work combining EUPL code with code under a listed licence to be distributed under that licence instead.
• Reach. Its definition of distribution covers making the work available online or offline or providing access to its essential functionalities, and art. 5 EUPL carries the copyleft obligation through to remote interaction in which that same functionality is offered. It therefore reaches software delivered as a service, in a way the GPL does not.

A Dutch public-sector customer may require the EUPL as a matter of policy rather than statute. The Interoperable Europe Act, Regulation (EU) 2024/903, directs public sector bodies to prioritise interoperability solutions without restrictive licensing terms, such as open source, where equivalent; nationally, the principle of open source, tenzij rests on cabinet decisions and policy lines, not on statute: the Wet digitale overheid facilitates the digital identity infrastructure but imposes no enforceable obligation to publish all source code. Read the tender documents: an EUPL requirement binds your deliverable and may be incompatible with proprietary code you intended to reuse.

Enforcement in practice

Who can sue. The rightholder — individual contributors, or the foundation or company holding assigned copyright. Fragmented authorship is the practical brake: a claimant must prove ownership of the code at issue. That defeated the best-known European GPL case, where a kernel developer’s claim against a virtualisation vendor failed for want of proof of authorship (LG Hamburg 8 July 2016, 310 O 89/15; upheld OLG Hamburg 28 February 2019, 5 U 146/16).

What the case law establishes. German courts have repeatedly accepted that open source licences are valid and that breach makes distribution unlawful, beginning with the first GPL injunction (LG München I 19 May 2004, 21 O 6123/04). The US Federal Circuit reached the same conclusion in Jacobsen v Katzer, 535 F.3d 1373 (Fed. Cir. 2008): licence terms are conditions on the scope of the grant, not mere covenants, so breach supports a copyright claim and injunctive relief. US litigation is exploring whether a downstream recipient can enforce the GPL as third-party beneficiary. That is the central question in Software Freedom Conservancy v Vizio before the California Superior Court: whether consumers, as third-party beneficiaries, can demand release of the source code under GPLv2. A substantive final ruling is expected only after the jury trial in 2026, so the point is not yet decided.

How a Dutch court would approach it. As copyright infringement under the Auteurswet: the claimant proves ownership and reproduction or communication; the defendant raises the licence; the claimant answers that its conditions were not met, so the defence fails. Contractual remedies under art. 6:265 BW run in parallel, but copyright is the stronger route.

Remedies. An injunction under art. 3:296 BW, typically with a penalty payment and available in summary proceedings; damages under art. 27 Aw and an account of profits under art. 27a Aw; recall, surrender or destruction under art. 28 Aw; and full recovery of reasonable and proportionate legal costs under art. 1019h Rv. Where software was distributed free of charge, loss is hard to quantify, and a German appellate court declined to award damages while upholding the injunction (OLG Hamm 13 June 2017, 4 U 72/16). What bites is rarely damages: it is the injunction, the recall, the costs order, and having to publish source you never meant to publish.

When you discover a compliance problem

Discovery usually comes from a customer’s security questionnaire, a scan during due diligence, or a letter from a rightholder. Remediation then runs as follows. Halt distribution of the affected build if the exposure is serious. Establish which component, which version, which licence, which products and releases, over what period. Work out what the licence actually requires — often an attribution file rather than a source release. Prepare the artefacts: notices, licence texts, complete corresponding source including build scripts, and a written offer where used. Ship a compliant release, then tell the rightholder what you have done rather than arguing about whether you had to.

Under GPLv3 and AGPLv3 the cure window gives speed legal value; under GPLv2 there is no cure right, which is why most enforcement ends in a negotiated compliance undertaking. Note also that privilege attaches to advice from your lawyer, not to an internal engineering report.

Open source in M&A and due diligence

In a software acquisition, open source is a standard diligence workstream, and an undisclosed copyleft component in the core product is one of the few findings that genuinely moves a deal: if the product cannot be distributed without releasing its source, the buyer is acquiring a different asset from the one priced.

Expect a codebase scan, a component inventory with licences, and questions about contributor and contractor arrangements. Typical outcomes are a specific indemnity, a retention pending remediation, a condition precedent requiring removal, or a bespoke open source warranty. Sellers should scan first: findings you disclose are a negotiation, findings the buyer’s adviser makes are leverage. Buyers should seek not “the company owns its IP” but a representation that no product incorporates open source requiring disclosure of proprietary source code.

The bill of materials, scanning and the Cyber Resilience Act

A software bill of materials is an inventory of a product’s components, with versions and licences. Until recently purely contractual, it is now regulatory too.

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024 and phases in. The reporting obligations for actively exploited vulnerabilities and severe incidents in art. 14 CRA apply from 11 September 2026; the provisions on notification of conformity assessment bodies from 11 June 2026; the Regulation in full from 11 December 2027 (art. 71 CRA). Annex I CRA requires manufacturers to identify and document the components in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies. It need not be published; market surveillance authorities may request it.

Free and open source software supplied outside a commercial activity falls outside the CRA. The Regulation introduces the open-source software steward — a legal person giving sustained support to the development of open source software intended for commercial activities — with lighter obligations in art. 24 CRA: a documented cybersecurity policy, cooperation with market surveillance authorities, and reporting. If you commercialise open source, or fund a project others commercialise, establish which role you occupy. The Commission adopted its first guidance on 27 July 2026: the Commission guidance on the application of the Cyber Resilience Act (CRA), annexed to communication C(2026) 5252, which addresses among other things when free and open source software falls within scope. No implementing act prescribing a format for the software bill of materials has been adopted, so the Regulation’s own standard — a commonly used, machine-readable format — remains the measure for the time being.

Software composition analysis run in CI generates the inventory serving compliance, licence review and diligence at once. Such tools miss vendored code, misidentify dual-licensed projects and cannot read a licence’s conditions: treat the output as the start of the review, not the review.

If you publish your own code: CLAs and the DCO

A company that releases code and accepts outside contributions must know it has the rights to what it merges. A contributor licence agreement is a contract between project and contributor, typically granting a broad copyright licence and an express patent licence, with warranties as to originality and authority. It is what lets a company relicense its project later, or offer commercial licences alongside an open source one. Its cost is friction.

The Developer Certificate of Origin, used by the Linux kernel and many other projects, is not a licence grant but a lightweight attestation, added as a sign-off line to each commit, that the contributor may submit the code under the project’s licence. Less burdensome, and less protective: no patent licence, no relicensing.

If dual licensing or a future relicence is plausible, use a CLA; if the project is a genuine commons, the DCO is usually enough. Either way, make sure your employment and contractor agreements assign copyright in the code your people write.

A practical policy checklist

• Generate a component inventory per product and release in the build pipeline, not by hand.
• Publish an internal policy: a permitted list, a prohibited list and an approval route for everything else.
• Define in writing what counts as distribution — on-premise installs, appliances, containers, SDKs, mobile apps, firmware.
• Ship a generated attribution file with every product.
• Approve licence choices at design time, when a component is selected, not at release.
• Decide whether contributions to external projects need approval, given the patent grants involved, and choose a CLA or a DCO before the first outside contribution.
• Align IP warranties, indemnities and escrow terms with the open source actually in the product.
• Run the review before a fundraising or sale process, not during one.