17MAY

CRA draft pins open-source liability on publishers

3 min read

14:28UTC

The European Commission published draft Cyber Resilience Act open-source guidance on Tuesday 3 March 2026 with consultation closing on Tuesday 31 March, confirming that responsibility for free and open-source software falls on who publishes and controls, not on contributors with commit access.

← Back to Brussels' 27 May package, two days before G7 Jump to analysis ↓

TechnologyDeveloping

Key takeaway

Maintainer liability is settled at the publisher-control test; donation triggers remain unresolved with the September 2026 reporting clock running.

On Tuesday 3 March 2026, the European Commission published draft implementation guidance for the Cyber Resilience Act (CRA, the EU's binding cybersecurity law covering digital products and software with digital elements) governing how the law applies to free and open-source software ¹. Consultation closed on Tuesday 31 March. The guidance establishes that responsibility under the CRA falls on the entity that publishes and controls the software, not on individual contributors who hold commit access.

The CRA reporting clock starts on Friday 11 September 2026 regardless of whether the Commission publishes final guidance before then. The draft closes the contributor-versus-publisher ambiguity Felix Reda, the German digital rights advocate and former MEP, had flagged repeatedly through 2024 and 2025. Hogan Lovells' published analysis of the draft confirms full compliance applies from Saturday 11 December 2027. OpenForum Europe and other open-source advocacy bodies welcomed the publisher-control test as resolving the most acute exposure for individual maintainers.

The grey area that remains is whether financial donations to a project trigger "placed on market" obligations under the CRA. The draft text suggests donations can trigger those obligations where access to essential functionality is conditional on payment. That conditional clause is the file's unresolved question for maintainers operating donation-funded projects with no separation between freely available and donor-tier functionality. The seven-CEO deregulation letter arrived in the same fortnight; the CRA open-source file was not in scope, but the legislative environment is the same. the Commission has not published the final guidance, and no publication date has been announced as of mid-May 2026.

Deep Analysis

In plain English

The Cyber Resilience Act (CRA) is an EU law that will require software sold in Europe to meet minimum security standards; much like toy safety labels or car crash tests, but for software. The CRA creates a problem for open-source software: code that anyone can download freely and modify, written by volunteers who are not paid. The guidance published in March clarifies two things. First, if you publish and control an open-source project, you are responsible for its security, not every individual who has ever contributed code. Second, if your project receives regular financial donations (through crowdfunding or sponsorship platforms), you may count as a commercial entity and lose some of the open-source exemptions. For software developers in Europe, this means they need to track who funds their projects and whether that funding crosses a compliance threshold.

Deep Analysis

Root Causes

The CRA's open-source liability ambiguity was an unintended product of the legislation's history: the original 2022 Commission proposal focused on IoT hardware and commercial software, and the open-source carve-out was added by the European Parliament during trilogue in 2023 without a detailed definition of who fell within the carve-out.

The carve-out's wording; 'freely available software, not in the course of a commercial activity'; was drafted by MEPs without input from open-source foundations, who only engaged fully after the text was finalised.

Felix Reda, the former MEP and open-source advocate, had flagged the contributor-vs-publisher ambiguity publicly from the first published draft, but his interventions during the passage of the legislation were unsuccessful in securing a clearer text. The March 2026 guidance is the belated administrative response to that unresolved legislative gap.

What could happen next?

Risk
The donation-triggers-liability ambiguity may cause GitHub Sponsors and Open Collective to implement EU geo-restrictions on donation features before 11 September 2026, drying up funding for European open-source maintainers at the moment CRA compliance investment is highest.
Immediate · 0.55
Precedent
The publisher-not-contributor liability rule will become the reference point for all subsequent EU digital product-safety legislation applied to software, including potential extensions of the AI Act to open-weight AI models.
Long term · 0.7
Consequence
The 11 September 2026 CRA reporting deadline applies regardless of whether the Commission publishes final guidance, meaning open-source publishers must begin compliance preparations under the draft guidance framework with no guarantee that the final rules will match.
Immediate · 0.85

Source Landscape

This story draws on neutral-leaning sources

Primary parallel: The EU's Product Liability Directive (PLD), updated in 2024, resolved a comparable publisher-vs-contributor ambiguity in software by adopting a 'placing on market' test: the entity that makes a product commercially available bears liability, not the original developer.

The CRA guidance is applying the same framework, which suggests consistency of EU product-safety doctrine but also that the Commission expects open-source developers to become aware of and manage European PLD obligations, a compliance literacy most open-source maintainers lack.

Counter-parallel: The US Computer Fraud and Abuse Act's liability framework has never applied to open-source contributors for vulnerabilities in their code, because US law treats CFAA liability as requiring intent. The EU's strict-liability product-safety model, applied to open-source via the CRA, is therefore a genuinely novel legal framework with no US analogue; and no established compliance practice that European developers can borrow from.

Consensus view: Hogan Lovells' Brussels technology practice and the Linux Foundation Europe both assess the publisher-not-contributor rule as the most important clarity the guidance provides: the original CRA text left ambiguous whether any person with write access to a repository incurred product liability, which had created a chilling effect on developer participation in European open-source projects.

Counter-view: Open Source Initiative (OSI) director Stefano Maffulli argued in a March 2026 blog post that the donation-triggers-liability provision remains the most commercially damaging ambiguity, because it would classify GitHub Sponsors, Open Collective, and similar developer-funding platforms as potential compliance vectors, with the effect of drying up small-maintainer funding just as the CRA demands more security investment from those same maintainers.

Key tension: Whether the Commission will clarify the donation threshold (a single €1 donation vs a sustained funding relationship) before the 11 September 2026 reporting deadline, or whether the draft guidance becomes de facto final through inaction.

Sources:Sovereign Tech Agency

Mentions:OpenForum Europe →European Commission →Cyber Resilience Act →Felix Reda →Brussels →Linux Foundation Europe →Hogan Lovells →

First Reported In

Update #5 · Brussels' 27 May package, two days before G7

Sovereign Tech Agency· 17 May 2026

Read original →

Different Perspectives

OpenForum Europe / open-source community

The EUR 350m Sovereign Tech Fund has no Commission host, no budget line, and no commissioner's name attached six weeks after the April conference, while Germany is already paying maintainers to staff international standards bodies. The CRA open-source guidance resolves contributor liability but leaves the financial-donations grey area open with the 11 September reporting clock running.

ASML / Christophe Fouquet

ASML's Q2 guidance miss of roughly EUR 300m below consensus reflects DUV revenue compression set by US export controls, not European policy. Fouquet said 2026 guidance accommodates potential outcomes of ongoing US-China trade discussions; a bipartisan US bill to tighten DUV sales further would accelerate the cross-subsidy thinning Chips Act II's equity authority is designed to address.

Anne Le Henanff / French G7 Presidency

Le Henanff chairs the 29 May Bercy ministerial two days after Brussels adopts the Tech Sovereignty Package, making the G7 communique the first international read of the Omnibus enforcement split and CAIDA's scope. France's Cloud au Centre doctrine is already operational via the Scaleway Health Data Hub contract.

German federal government

Berlin operationalises sovereignty through procurement mandates (the ODF requirement and the Sovereign Tech Standards programme) rather than waiting for Commission legislation. The Bundeskartellamt has still not received the Cohere-Aleph Alpha merger filing, leaving Germany's flagship AI champion in structural limbo six weeks after the deal resolved.

US Trade Representative

The USTR Section 301 investigation into EU digital rules closes with a 24 July 2026 final determination. CAIDA's public-sector cloud restriction sits within the criteria that triggered the 2020 Section 301 action against France's digital services tax, and the US has not signalled whether the Thales-Google S3NS arrangement resolves CLOUD Act jurisdiction concerns.

CISPE / Valentina Mingorance

CISPE shipped its own pass-fail sovereignty badge in April to establish an industry-auditable floor the Commission could adopt. Whether CAIDA inherits the CISPE binary or the multi-tier SEAL approach will determine whether certification is enforceable by public contracting authorities or requires Commission discretion.