The Cyber Resilience Act’s Open Source Problem

GitHub has been collaborating with EU policymakers on the Cyber Resilience Act (CRA), a regulation intended to improve the security of digital products — including the 96 percent that incorporate open source — by imposing strict requirements and fines up to €15 million or 2.5% of global revenue on vendors in the single market. The intent is sound: security is too often an afterthought. But the current Parliament text, set for a July 19 industry (ITRE) committee vote, threatens open source sustainability without delivering the resilience it promises.

The CRA includes exemptions for open source developed outside commercial activity, but the scope definitions have drawn significant community concern. Three specific problems stand out in the text headed for the ITRE vote. Unless objections are raised, this text may become Parliament’s final position without a plenary vote.

Donations Could Bring Compliance Burdens

Open source sustainability is an ongoing challenge: maintainers of widely used projects often face burnout from the volume of issues and pull requests. Donations have become a practical support mechanism, offered by governments, foundations, companies, and individuals. Under recent CRA drafts, however, accepting donations could pull a project into a compliance regime with potential penalties.

The draft recitals state that accepting donations without profit intent should not count as commercial activity — unless the donations come from commercial entities and are recurring. For maintainers who rely on corporate sponsorship, this creates uncertainty: receiving support could mean taking on regulatory obligations they never sought. The result would be fewer resources flowing to already under-resourced projects.

Corporate Contributors Put Projects in Scope

Open source is typically multi-stakeholder: contributors include individual developers, foundation volunteers, and employees of companies both large and small. The current draft would regulate any project unless it has “a fully decentralised development model.” Recital 10a suggests that a project where commercial entities employ main contributors and exercise control over accepted modifications should generally be considered commercial.

This formulation effectively penalizes the most common development model. A project with any corporate employee holding commit rights would need to meet CRA obligations. The perverse incentives are clear: projects may bar maintainers or contributors affiliated with companies, and companies may prohibit employees from participating in open source entirely. That outcome would make the ecosystem less innovative and less secure.

Vulnerability Disclosure Rules Cut Against Patch Coordination

The CRA targets a real issue: upstream projects issue fixes, but downstream products are slow to adopt them. However, the Parliament text’s reporting requirements could undermine coordinated vulnerability disclosure itself.

Under the draft, any manufacturer must notify ENISA of actively exploited vulnerabilities within 24 hours, with a fuller notification in 72 hours. For unpatched vulnerabilities, this timeline conflicts with established practice where disclosures are limited to parties who can help fix the issue. Broad early notification of unpatched flaws does not make the ecosystem more resilient — it invites further exploitation.

What Happens Next

The ITRE Committee vote is July 19. If the text passes without objections, it becomes Parliament’s position. The final CRA will then be negotiated among Parliament, Council, and Commission. The Council’s text better reflects how open source is actually built and maintained; those negotiations could still yield an effective regulation even if the Parliament text is flawed.

Maintainers and other technical stakeholders should consider how this regulation could affect their projects and their users — and communicate those concerns to their elected MEPs before the vote.