Three years from today all obligations of the EU Cyber Resilience Act (CRA) will be fully applicable, with vulnerability reporting obligations applying already from September 2026. By that time, the CRA—from idea to implementation—will have been high on GitHub’s developer policy agenda for nearly six years.
Together with our partners, GitHub has engaged with EU lawmakers to ensure that the CRA avoids unintended consequences for the open source ecosystem, which forms the backbone of any modern software stack. This joint effort has paid off: while the first draft of the CRA created significant legal uncertainty for open source projects, the end result allocates responsibility for cybersecurity more clearly with those entities that have the resources to act.
As an open source developer, you’re too busy to become a policy wonk in your spare time. That’s why we’re here: to understand the origins and purpose of the CRA and to help you assess whether the CRA applies to you and your project.
Why GitHub got involved
The reasons why the EU decided to start regulating software products are clear: cheap IoT devices that end up being abused in botnets, smartphones that fail to receive security updates just a couple of years after purchase, apps that accidentally leak user data, and more. These are not just a nuisance for the consumers directly affected by them, they can be a starting point for cyberattacks that weaken entire industries and disrupt public services. To address this problem, the CRA creates cybersecurity, maintenance, and vulnerability disclosure requirements for software products on the EU market.
Cybersecurity is just as important for open source as it is for any other software. At the same time, open source has flourished precisely because it has always been offered as-is, free to re-use by anyone, but without any guarantees offered by the community that developed it. Despite their great value to society, open source projects are frequently understaffed and underresourced.
That’s why GitHub has been advocating for a stronger focus on supporting, rather than regulating, open source projects. For example, GitHub supports upscaling public funding programs like Germany’s Sovereign Tech Agency, who is joining us for a GitTogether today to discuss open source sustainability. This approach has also informed the GitHub Secure Open Source Fund, which will help projects improve their cybersecurity posture through funding, education, and free tools. Applications are open until January 7.
What open source developers need to know
The CRA creates obligations for software manufacturers, importers, and distributors. If you contribute to open source in a personal capacity, the most important question will be whether the CRA applies to you at all. In many cases, the answer will be “no,” but some uncertainty remains because the EU is still in the process of developing follow-up legislation and guidance on how the law should be applied. As with any law, courts will have the final word on how the CRA is to be interpreted.
From its inception, the CRA sought to exclude any free and open source software that falls outside of a commercial activity. To protect the open source ecosystem, GitHub has fought for a clear definition of “commercial activity” throughout the legislative process. In the end, the EU legislature has added clarifying language that should help place the principal burden of compliance on companies that benefit from open source, not on the open source projects they are relying on.
In determining whether the CRA applies to your open source project, the key will be whether the open source software is “ma[de] available on the market,” that is, intended for “distribution or use in the course of a commercial activity, whether in return for payment or free of charge.” (Art. 3(22); *see also *Art. 3(1), (22), (48); Recitals 18-19). Generally, as long as it’s not, then the CRA’s provisions won’t apply at all. If you intend to monetize the open source software yourself, then you are likely a manufacturer under the CRA, and subject to its full requirements (Art. 3(13)).
Lighter regulation of open source stewards
If you are part of an organization that supports and maintains open source software that is intended for commercial use by others, that organization may be classified as an “open source software steward” under the CRA (Art. 3(14), Recital 19).
Following conversations with the open source community, EU lawmakers introduced this new category to better reflect the diverse landscape of actors that take responsibility for open source. Examples of stewards include “certain foundations as well as entities that develop and publish free and open-source software in a business context, including not-for-profit entities” (Recital 19). Stewards have limited obligations under the CRA: they have to put in place and document a cybersecurity policy, notify cybersecurity authorities of actively exploited vulnerabilities in their projects that they become aware of, and promote sharing of information on discovered vulnerabilities with the open source community (Art. 24). The details of these obligations will be fleshed out by industry standards over the next few years, but the CRA’s text makes clear a key distinction—that open source stewards should be subjected to a “light-touch . . . regulatory regime” (Recital 19).
Developers should be mindful of some key provisions as they decipher whether they will be deemed manufacturers, stewards, or wholly unaffected by the CRA:
- On donations: “Accepting donations without the intention of making a profit should not be considered to be a commercial activity” (Recital 15). However, in cases “where manufacturers that integrate a component into their own products with digital elements either contribute to the development of that component in a regular manner or provide regular financial assistance to ensure the continuity of a software product” (Recital 19), the recipient of that assistance may qualify as an open source software steward.On distinction between development and supply of software: “[The] provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity.” (Recital 18)On contributions from manufacturers: “[T]he mere fact that an open-source software product with digital elements receives financial support from manufacturers or that manufacturers contribute to the development of such a product should not in itself determine that the activity is of commercial nature.” (Recital 18)On regular releases: “[T]he mere presence of regular releases should not in itself lead to the conclusion that a product with digital elements is supplied in the course of a commercial activity.” (Recital 18)On OSS nonprofits: “[T]he development of products with digital elements qualifying as free and open-source software by not-for-profit organisations should not be considered to be a commercial activity provided that the organisation is set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives.” (Recital 18)On OSS contributors: “This Regulation does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility.” (Recital 18)
Making the rules work for open source in practice
Even with the clarifications added during the legislative process, many open source developers still struggle to make sense of whether they’re covered or not. If you think your open source activities may fall within the scope of the CRA (either as a manufacturer or as a steward), the Eclipse ORC Working Group is a good place to get connected with other open source organizations that are thinking about the CRA and related standardization activities. Linux Foundation is currently co-hosting a workshop for open source stewards and manufacturers to prepare for compliance with OpenSSF, who is publishing resources about the CRA.
While it’s good news that some classes of open source developers will face minimal obligations, that probably won’t stop some companies from contacting projects about their CRA compliance. In the best case, this will lead to constructive conversations with companies taking responsibility for improving the cybersecurity of open source projects they depend upon. The CRA offers opportunities for that: for example, it allows manufacturers to finance a voluntary security attestation of open source software (Art. 25), and it requires manufacturers who have developed a fix for a vulnerability in an open source component to contribute that fix back to the project (Art. 13(6)). In the worst case, companies working on their own CRA compliance will send requests phrased as demands to overworked open source maintainers who will spend hours talking to lawyers just to often find out that they are not legally required to help manufacturers.
To avoid the worst-case scenario and help realize the opportunities of the CRA for open source projects, GitHub’s developer policy team is engaging with the cybersecurity agencies and regulators, such as the European Commission, that are creating guidance on how the rules will work in practice.
Most urgently, we call on the European Commission to issue guidance (required under Art. 26 (2) (a)) that will make it easy for every open source developer to determine whether they face obligations under the CRA or not. We are also giving input to related legislation, such as the NIS2 Directive, which defines supply chain security rules for certain critical services.
Our north star is advocating for rules that support open source projects rather than unduly burden them. We are convinced that this approach will lead to better security outcomes for everyone and a more sustainable open source ecosystem.
The post What the EU’s new software legislation means for developers appeared first on The GitHub Blog.
