Open source after the EU Open Source Strategy

The legal framework

Status and the texts

The EU Open Source Strategy is part of a Commission Communication of 3 June 2026: COM(2026) 503 final, "on European Tech Sovereignty, accompanied by an EU Open Source Strategy". A Communication is a policy document. It creates no rights or obligations for companies. It announces actions, some of which may later lead to legislation or funding calls.

The binding rules on open source sit in other texts:

• the Cyber Resilience Act, Regulation (EU) 2024/2847 of 23 October 2024, in force since 10 December 2024 and applicable from 11 December 2027, with Article 14 (reporting) applying from 11 September 2026 (Article 71);
• the Interoperable Europe Act, Regulation (EU) 2024/903, applicable since 12 July 2024;
• the proposed Cloud and AI Development Act, COM(2026) 502, procedure 2026/0138(COD), which is not law yet.

What the Strategy says

The Strategy sets four objectives: leverage open source for technological sovereignty; strengthen and promote a vibrant open source ecosystem; promote open and interoperable digital ecosystems for public administrations; and reinforce digital standards and international outreach (section 4). It describes open source by reference to the Open Source Initiative's definition and to OSI-approved licences, naming GPL, Apache-2.0, MIT, MPL-2.0, EPL-2.0 and the EU's own EUPL.

Among the announced measures:

• Supply side. Scaling up the Open Internet Stack as a catalogue and one-stop shop of open source building blocks; open source business accelerators offering, among other things, legal and licensing consulting; a "stewardship toolkit" for setting up foundations in the EU; a feasibility study on an EU-level framework for foundations; and an "Open Source Maintenance Instrument" to support maintenance and security of essential components (sections 4.1 and 4.2).
• Security. Speeding up voluntary security-attestation programmes under Article 25 of the Cyber Resilience Act, a voluntary EU assessment framework for open source, and a list, with ENISA, of the most exposed open source dependencies (section 4.2).
• Public sector. Guidelines for software tenders that let open source compete with proprietary solutions, for evaluating open source bids, and for innovation partnerships; an "open source first" principle is discussed for public procurement (section 4.3).
• Standards. In the revision of the Standardisation Regulation, measures to bring open source communities into standard setting (section 4.4).
• Monitoring. Annual discussion with Member States in the Digital Decade Board and a report to Parliament every three years (section 4.5; key indicators in Annex I).

Because these are announcements, we do not treat them as obligations. Watch for the calls and proposals that follow.

Who is concerned by the binding rules

• Manufacturers that integrate open source components into products with digital elements sold in the EU (Cyber Resilience Act).
• Open-source software stewards: legal persons, other than manufacturers, that systematically provide sustained support for the development of free and open-source products intended for commercial activities, and ensure their viability (Article 3, point (14)). Recital 19 mentions certain foundations and entities that develop and publish open source in a business context, including not-for-profits.
• Suppliers to public bodies, through the Interoperable Europe Act and, if adopted, the Cloud and AI Development Act.
• Developers who publish code without monetising it, who are in principle outside the Cyber Resilience Act (recital 18).

Example: a Ghent software company builds an industrial gateway on an open source operating system and three open source libraries. It is a manufacturer under the Cyber Resilience Act and must exercise due diligence on those components. The foundation that maintains one of the libraries, with paid staff and regular releases used by companies, may be an open-source software steward.

The duties, article by article

Free and open-source software (Article 3, point (48)). Software whose source code is openly shared and made available under a free and open-source licence granting all rights to make it freely accessible, usable, modifiable and redistributable.

Manufacturers' due diligence (Article 13(5)). Manufacturers must exercise due diligence when integrating third-party components so that they do not compromise cybersecurity. That expressly includes free and open-source components that were not made available on the market in the course of a commercial activity.

Reporting upstream (Article 13(6)). A manufacturer that finds a vulnerability in an integrated component, including an open source component, must report it to the person or entity maintaining the component and remediate it. If it develops a fix, it shares the relevant code or documentation with the maintainer, where appropriate.

Stewards (Article 24). Stewards have a light regime (more in Cyber Resilience Act III). They must:

1. put in place and document a cybersecurity policy that fosters secure development, effective vulnerability handling and voluntary reporting of vulnerabilities, and sharing of vulnerability information within the community (Article 24(1));
2. cooperate with market surveillance authorities on request, and provide the policy documentation on a reasoned request (Article 24(2));
3. comply with the reporting duty of Article 14(1) to the extent they are involved in development, and with Article 14(3) and (8) for severe incidents affecting the systems they provide for development (Article 24(3)).

Administrative fines under Article 64 do not apply to stewards (Article 64(10)(b)).

Security attestation (Article 25). The Commission may set up voluntary security attestation programmes for free and open-source products, to help manufacturers meet their due diligence duty. The Strategy says it will speed these up.

Public bodies and open licensing (Article 4(6) of Regulation 2024/903). When choosing interoperability solutions, public bodies prioritise solutions without restrictive licensing terms, such as open source, where they are equivalent on objective criteria. We explain this in Interoperable Europe.

Proposed: open source chapter of the Cloud and AI Development Act (Articles 41 to 44 of COM(2026) 502). As proposed, the Union and Member States would encourage public bodies to use open standards and open source components. Software they release under an open source licence would be published through a catalogue connected to the EU Open Source Solutions Catalogue on the Interoperable Europe portal, and a network of Open Source Programme Offices would be set up. See the Cloud and AI Development Act.

In practice

Know your components. Keep a software bill of materials and know the licence of every component. The Cyber Resilience Act's due diligence duty and the sovereignty criteria in the Cloud and AI Development Act proposal both assume you can show where your code comes from.

Check licence compatibility. Copyleft licences such as GPL can require you to release source code of derived works on distribution. Permissive licences such as MIT or Apache-2.0 do not, but carry notice and, for Apache-2.0, patent terms. The EUPL has its own compatibility clause. Map the obligations before you ship.

Decide your contribution policy. Under Article 13(6), if you fix a vulnerability in a component you must share the fix with the maintainer where appropriate. Align that with your IP policy: who may contribute, under which contributor agreement, and how you protect what is proprietary. Our article on protecting software explains what copyright and patents cover in software.

If you steward a project. A foundation or company that supports an open source project for commercial use should check whether it meets the steward definition. If so, write and document the cybersecurity policy now, before 11 December 2027, and set up the reporting channel that Article 14 requires.

When selling to the public sector. Expect tender documents to ask about licensing, reuse and open standards. Consider dual licensing or a public licence for the interoperability layer. See licensing agreements for licence structures.

A worked example: a Belgian SaaS provider wants to bid on a regional e-government platform. It offers its core under a commercial licence and publishes its connectors under the EUPL. In the bid it documents its components, their licences and its vulnerability handling. That positions it well under Article 4(6) of the Interoperable Europe Act and meets the Cyber Resilience Act expectations once those apply.

Frequently asked questions

Is the EU Open Source Strategy binding?

No. It is part of a Commission Communication. It announces measures and funding priorities. Binding rules on open source are in the Cyber Resilience Act and the Interoperable Europe Act, and are proposed in the Cloud and AI Development Act.

Does the Cyber Resilience Act apply to developers who publish code for free?

In principle not, if the software is not made available on the market in the course of a commercial activity (recital 18). Manufacturers who integrate that code into their own products remain responsible for due diligence (Article 13(5)).

What is an open-source software steward, and can it be fined?

A legal person, not a manufacturer, that systematically supports the development of open source products intended for commercial activities and ensures their viability (Article 3, point (14)). It has light obligations under Article 24, and Article 64(10)(b) excludes administrative fines for its infringements.

Must public bodies buy open source?

Not as a rule. The Interoperable Europe Act asks them to prioritise solutions without restrictive licensing terms where solutions are equivalent. The proposed Cloud and AI Development Act would encourage open source use. The Strategy discusses an "open source first" principle but does not impose it.

How this connects

We review open source licence obligations and draft contributor, licence and supply terms through our patent and technology licensing and commercial contracts and transactions services, using Document Studio, our proprietary document analysis and development system, and the clause library and risk review for incoming terms.

Cited provisions: Communication COM(2026) 503, section 4 and Annex I; Regulation (EU) 2024/2847, Articles 3 (points (14) and (48)), 13(5) and (6), 14, 24, 25, 64(10) and 71 and recitals 18 and 19; Regulation (EU) 2024/903, Article 4(6); proposal COM(2026) 502, Articles 41 to 44.

Key dates:

• 12 July 2024: Interoperable Europe Act applies
• 10 December 2024: Cyber Resilience Act in force
• 3 June 2026: EU Open Source Strategy and Cloud and AI Development Act proposal published
• 11 September 2026: Cyber Resilience Act reporting duties (Article 14) apply
• 11 December 2027: Cyber Resilience Act applies in full, including Article 24

Related reading: Cyber Resilience Act III: importers, distributors, open source and contracts, Interoperable Europe, the Cloud and AI Development Act, protecting software and licensing agreements.