Among the unresolved questions in crypto regulation, few are more consequential than this: what are developers of open source code actually responsible for?
Our belief is that Europe is not missing an answer to the above question, as it has already written a good one. The Cyber Resilience Act (CRA) draws the boundary in the right place: responsibility follows commercial placing-on-the-market, not authorship. The incoherence this article describes is based on diverging views that almost every adjacent regime brings: product liability, anti-money-laundering, the Data Act, and criminal enforcement, either blur that boundary or refuse to honour it. The practical consequence is the discouragement of open source development in Europe and the gradual relocation of the developers, contributors, and projects to jurisdictions that offer greater legal certainty or less regulatory constraints.
The CRA designates the manufacturer as the primary responsible party. That is any natural or legal person who develops a product with digital elements and places it on the EU market under their own name or trademark, "whether for payment, monetisation, or free of charge." The Regulation demands that manufacturers do some heavy-lifting: secure-by-design development, vulnerability handling across a declared support period, technical documentation, conformity assessment, and, where applicable, CE marking.
A contributor who develops, publishes, or maintains free and open source software is not, by default, a manufacturer. The Regulation carves them out because publishing source code openly, without placing a product on the EU market in the course of a commercial activity, is not what the CRA regulates. The Ethereum protocol itself, its client developers, and the authors of open source smart contracts, therefore, sit outside the manufacturer category.
The element doing the work in this distinction is the commercial one. The CRA does not exempt OSS as a category; it exempts OSS developed or supplied outside the course of a commercial activity. To put it plainly, once the company integrates such code into a product placed on the EU market for commercial purposes (e.g. a wallet, a custodial service, a hardware device), that company becomes the manufacturer and inherits responsibility for every component in the product, including the open source ones it did not write.
While it may seem straightforward, in permissionless blockchain ecosystems, the boundary between stewardship, participation, and commercial exploitation is rarely clean. Ethereum clients such as Geth, Nethermind, Besu, Lighthouse, and Prysm are maintained through contributions from nonprofits, commercial entities, independent developers, and volunteers. Does running a validator that earns protocol rewards count as commercial exploitation? Does issuing a governance token? What about retroactive funding? These are hard cases at the edge of an otherwise sound test, not evidence that the test itself is wrong. The task is to answer them in the CRA's own terms, and our view is that protocol rewards, token allocations, and retroactive grants belong on the non-commercial side of the line.
Moreover, the new Product Liability Directive treats software as a product and creates strict liability for defects, with Member States required to transpose it by 9 December 2026. It borrows the CRA's exact language, carving out free and open source software "developed or supplied outside the course of a commercial activity", and then weakens it to a large extent. Under recital 14, that exemption falls away not just for paid software but for software supplied in exchange for personal data, reviving the "product" character of code the CRA would leave alone, and leaving contributors to guess where the commercial boundary actually runs.
It is with other regulations that the problem clearly appears. Both MiCA and the AML regime assume the existence of an operator. A "crypto-asset service provider" is a legal or natural person who provides services to clients. Where there is no service, no client, and no operator, only deployed bytecode running on permissionless infrastructure, there is no CASP, and MiCA's Recital 22 acknowledges this. But the AMLR review provisions and the FATF debate around DeFi push the other way: if no obligated entity is visible, find one, and the developer is the path of least resistance.
The underlying challenge remains: when regulation encounters autonomous software without a clear intermediary, responsibility migrates toward those closest to the code.
This problem becomes acute when criminal liability and sanctions are involved. The Dutch prosecution of Alexey Pertsev for money laundering linked to the Tornado Cash smart contracts produced a conviction in 2024; his appeal turns on the two questions at the heart of this article: whether a developer can be criminally liable for third-party misuse, and whether a deployed contract can meaningfully be controlled at all. While the judgment also considered the ongoing control, governance, and coordinated business endeavour, the case reinforced the perception that open source developers can face criminal liability. The chilling effect across European Ethereum builders is real and rational. Until European regulation, national laws and court interpretations speak clearly on the boundary between authorship of permissionless code and complicity in its later misuse, every contributor working on privacy, mixing, or any other contested primitive is making that calculation alone.
Europe has already shown it can correct courses here. Article 36 of the Data Act placed responsibility for compliance with smart-contract requirements on developers "in the absence of a vendor", with the boundary slipping in precisely the direction the CRA avoids. The provision drew sustained criticism, and the Commission has proposed deleting it outright through the Digital Omnibus on the grounds that it is inconsistent with the initiative's innovation-oriented direction. That repeal is the right call and the clearest proof that the CRA's allocation can be considered from a more generalised rather than contradictory perspective.
A second under-examined question is when responsibility ends. The CRA assumes a support period during which the manufacturer maintains the product. A truly immutable smart contract has no support period, because no party can patch it. An upgradeable contract has a support period that ends when admin keys are burned or transferred to a DAO. Each of these design choices presents a different distribution of responsibility and does not map cleanly onto a regime built around a continuous "manufacturer" or "operator." European law should therefore extend the CRA's logic by recognising that surrendering control is itself a legal act and distinguish an ongoing operator from a deployer who has demonstrably relinquished the ability to act.
The constructive position is not that developers should bear no responsibility. It is that they should answer for what they actually did: operating a service, exercising control, capturing commercial value, and never for the bare act of publishing code, nor for control they have demonstrably given up. Europe has already drawn that line once, with care, in the Cyber Resilience Act, and it should firmly stick to it. The incoherence lies everywhere the rest of the acquis declines to follow it. Europe's leadership in open source infrastructure now depends on the discipline to apply the boundary it has already drawn, between publishing code and operating systems, and the misuse of either, consistently and in advance, rather than leaving each contributor to discover it from whichever prosecutor or regulator reaches them first.
About the Author’s Organisation
European Ethereum Institute is a non-profit advocacy organisation based in Brussels, Belgium. It aims to shape EU regulation to favour open, permissionless, decentralised applications leveraging blockchain technology while advocating for an innovative EU environment, supporting Ethereum as a core layer of public infrastructure for institutions across the EU and UK.