Greg Kroah-Hartman explains the Cyber Resilience Act for open source developers
(2025/09/30)
- Reference: 1759218313
- News link: https://www.theregister.co.uk/2025/09/30/cyber_reiliance_act_opinion_column/
- Source link:
Opinion There has been considerable worry about the impact of the European Union's Cyber Resilience Act on open source programmers. Linux stable kernel maintainer Greg Kroah-Hartman says, however, that there won't be much of an impact at all.
The Linux Foundation has to abide by these rules. Mozilla has to abide by these rules. Me and Linus, as individuals working for them, don't have to abide by the rules...
When the news of the EU's [1]Cyber Resilience Act (CRA) first emerged, [2]open source software developers and companies were worried sick . As the Python Software Foundation (PSF) executive director Deb Nicholson said at the time, "Under the current language, [3]the PSF could potentially be financially liable for any product that includes Python code, while never having received any monetary gain from any of these products." Ouch!
Since then, however, the [4]EU has made the CRA more open source friendly . How friendly? Well, according to Greg Kroah-Hartman, a top Linux kernel maintainer and member of the CRA working group of experts, "for open source contributors and maintainers, … [the] CRA is a good thing. I think it's gonna help us.
Speaking in Paris at the [5]Linux Kernel Recipes conference, Kroah-Hartman started by saying, "You never expect to be dealing with lawyers and things like that when you start out programming. But here I am. This is all my personal opinion." But, he believes, the CRA has become "something that's actually palatable and can be used" for open source's benefit.
Kroah-Hartman explained that the CRA introduces a legal requirement for producers of products with digital elements (PDE). This is a broad category that includes nearly all software-driven devices and programs to document, secure, and maintain their software supply chain. This means companies must now generate a Software Bill of Materials (SBOM), tracking vulnerabilities, responding to newly discovered issues, and being transparent about security practices. For open source developers, this means, for the first time, companies must publicly acknowledge and document their open source dependencies. That's a win in Kroah-Hartman's book.
[6]
A fundamental distinction in the revised CRA's approach is how it separates unpaid, hobbyist developers from legal "people" such as foundations, projects, and companies that commercialize open source software. Specifically, non-commercial open source developers can continue publishing software with minimal worry. As long as a project is not organized as a legal or commercial entity, the CRA requires only a basic "readme" with a security contact. There is no legal risk for individual contributors simply sharing code online or in publications, even when they receive payment for writing an article, as long as the software itself is not monetized or organized.
[7]
[8]
That readme must say "who to email for security issues and report security issues" to a security monitoring organization. That's it. That's all. "So don't be afraid of the CRA. These are things you should be doing anyway."
Project stewards, such as legal persons, are another matter. They must provide a security contact and a reporting process. If the organization receives or distributes funding or donations, it falls into this category and must follow the stewardship requirements. "So, he continued, "the Linux Foundation has to abide by these rules. Mozilla has to abide by these rules. Me and Linus, as individuals working for them, don't have to abide by the rules." As far as Kroah-Hartman's concerned, "this is a reasonable baseline most responsible projects already meet."
[9]
What are these rules? Well, the CRA's focus is on commercial manufacturers and distributors. That means businesses that integrate open source code into EU products must fully comply with documentation, incident response, and lifecycle management requirements. This includes publishing Software Bills Of Materials (SBOMs), patching vulnerabilities within regulated timeframes, and responding proactively to security incident reports.
For the purposes of the CRA, consulting operations monetizing open source work could be considered manufacturers, triggering compliance obligations. Independent consultants or tiny firms may need to form a legal entity, but the workload is "not huge if you're already following good development practice," according to Kroah-Hartman.
The regulations are much more stringent for hardware or device vendors using open source code in their products than for pure software consultancies. For decades, hardware vendors have been using open source code without obeying the open source licensing rules, such as [10]Vizio using Linux in its smart TV . Under the CRA, they'll find it much harder to get away with this or [11]deny they're breaching open source software terms in their products, as Cisco did in 2008 with its [12]Linksys routers . (It ultimately settled the case, appointed a free software director, made source code for products available on its website, and made a donation to the FSF.)
Manufacturers are going to care in September of next year. They're going to start panicking in the summer of next year, and things are going to start hitting the fan...
You may think that since the CRA is an EU law, it won't matter to countries outside the EU. You would be wrong. The CRA effectively extends worldwide. If software is accessible "on the market" in the EU, it falls under the law's scope. Thus, US and Japanese vendors, for example, must pay careful attention to compliance if their products are downloadable or operable from within the EU.
For example, manufacturers must act on vulnerabilities, even if the upstream maintainer does not fix the issue. Manufacturers selecting open source code for their products must understand the code, support it, and respond to regulatory reporting requirements. This may, Kroah-Hartman observed, increase pressure on companies to use actively supported open source projects or stick closer to mainstream, well-resourced communities."
[13]
Will this make companies more wary of using open source software? Kroah-Hartman thinks it will have the opposite effect. The CRA also covers proprietary software. Instead of these new requirements creating a "chilling effect" on open source releases by nervous companies or legal departments, he thinks it will actually increase demand for open source, since companies gain more control over code destiny than with closed source vendors.
Businesses that are already using open source code in their programs still haven't realized just what a big deal the CRA will be for them. They will soon enough. Kroah-Hartman predicts, "Companies are coming after you [open source developers]. I will create a little form letter and say, 'Here's what you need to send off.'
"It's going to get worse because it's coming soon for companies. Manufacturers are going to care in September of next year. They're going to start panicking in the summer of next year, and things are going to start hitting the fan."
They'll want developers to shoulder the burden the CRA will place on them. But you don't have to do that. It's their problem, not yours as a programmer.
[14]Strap in, get ready for more Rust drivers in Linux kernel
[15]Linux royalty backs adoption of Rust for kernel code, says its rise is inevitable
[16]Even Linus Torvalds can have trouble with autocycle … autocracy… AUTOCOMPLETE!
[17]Linus Torvalds affirms expulsion of Russian maintainers
Of course, developers are encouraged to adopt best practices - eg, secure reporting, clear SBOMs, supply-chain checks - now. Foundations and large community projects are working with the EU to produce checklists and templates to simplify compliance. Kroah-Hartman reports that much of the ambiguity around commercial versus non-commercial obligations will be clarified in the coming year, with accessible implementation resources for projects.
In a Q&A session afterwards, Kroah-Hartman struck a hopeful note, "The goal here and the intent is not to trip up anybody in this room. The goal and intent are also to hold big companies liable when they release open source software, as part of that, because they want it not to be an end run around the CRA.
"Therefore, merging those two things together created a really wiggly line in the middle. But they are on our side. I've spoken with representatives from the different countries that created this law. They understand open source. They understand how the world runs in open source. They don't want to see it harmed by this at all. So have faith in that." ®
Get our [18]Tech Resources
[1] https://www.european-cyber-resilience-act.com/
[2] https://www.theregister.com/2023/05/12/eu_cyber_resilience_act/
[3] https://www.theregister.com/2023/04/12/python_management_eu/
[4] https://www.theregister.com/2023/12/04/infosec_in_brief/
[5] https://kernel-recipes.org/en/2025/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aNuqM8lzJulPSHxHo--4vwAAAIE&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aNuqM8lzJulPSHxHo--4vwAAAIE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aNuqM8lzJulPSHxHo--4vwAAAIE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aNuqM8lzJulPSHxHo--4vwAAAIE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://www.zdnet.com/article/software-freedom-conservancy-sues-vizio-for-gpl-violations/
[11] https://www.computerworld.com/article/1511569/open-source-isn-t-free-software.html
[12] https://www.theregister.com/2009/05/21/cisco_open_source/
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aNuqM8lzJulPSHxHo--4vwAAAIE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[14] https://www.theregister.com/2025/03/10/rust_drivers_expected_to_become/
[15] https://www.theregister.com/2025/02/21/linux_c_rust_debate_continues/
[16] https://www.theregister.com/2025/02/18/linus_torvalds_autocomplete_mistake/
[17] https://www.theregister.com/2024/10/23/linus_torvalds_affirms_expulsion_of/
[18] https://whitepapers.theregister.com/
The Linux Foundation has to abide by these rules. Mozilla has to abide by these rules. Me and Linus, as individuals working for them, don't have to abide by the rules...
When the news of the EU's [1]Cyber Resilience Act (CRA) first emerged, [2]open source software developers and companies were worried sick . As the Python Software Foundation (PSF) executive director Deb Nicholson said at the time, "Under the current language, [3]the PSF could potentially be financially liable for any product that includes Python code, while never having received any monetary gain from any of these products." Ouch!
Since then, however, the [4]EU has made the CRA more open source friendly . How friendly? Well, according to Greg Kroah-Hartman, a top Linux kernel maintainer and member of the CRA working group of experts, "for open source contributors and maintainers, … [the] CRA is a good thing. I think it's gonna help us.
Speaking in Paris at the [5]Linux Kernel Recipes conference, Kroah-Hartman started by saying, "You never expect to be dealing with lawyers and things like that when you start out programming. But here I am. This is all my personal opinion." But, he believes, the CRA has become "something that's actually palatable and can be used" for open source's benefit.
Kroah-Hartman explained that the CRA introduces a legal requirement for producers of products with digital elements (PDE). This is a broad category that includes nearly all software-driven devices and programs to document, secure, and maintain their software supply chain. This means companies must now generate a Software Bill of Materials (SBOM), tracking vulnerabilities, responding to newly discovered issues, and being transparent about security practices. For open source developers, this means, for the first time, companies must publicly acknowledge and document their open source dependencies. That's a win in Kroah-Hartman's book.
[6]
A fundamental distinction in the revised CRA's approach is how it separates unpaid, hobbyist developers from legal "people" such as foundations, projects, and companies that commercialize open source software. Specifically, non-commercial open source developers can continue publishing software with minimal worry. As long as a project is not organized as a legal or commercial entity, the CRA requires only a basic "readme" with a security contact. There is no legal risk for individual contributors simply sharing code online or in publications, even when they receive payment for writing an article, as long as the software itself is not monetized or organized.
[7]
[8]
That readme must say "who to email for security issues and report security issues" to a security monitoring organization. That's it. That's all. "So don't be afraid of the CRA. These are things you should be doing anyway."
Project stewards, such as legal persons, are another matter. They must provide a security contact and a reporting process. If the organization receives or distributes funding or donations, it falls into this category and must follow the stewardship requirements. "So, he continued, "the Linux Foundation has to abide by these rules. Mozilla has to abide by these rules. Me and Linus, as individuals working for them, don't have to abide by the rules." As far as Kroah-Hartman's concerned, "this is a reasonable baseline most responsible projects already meet."
[9]
What are these rules? Well, the CRA's focus is on commercial manufacturers and distributors. That means businesses that integrate open source code into EU products must fully comply with documentation, incident response, and lifecycle management requirements. This includes publishing Software Bills Of Materials (SBOMs), patching vulnerabilities within regulated timeframes, and responding proactively to security incident reports.
For the purposes of the CRA, consulting operations monetizing open source work could be considered manufacturers, triggering compliance obligations. Independent consultants or tiny firms may need to form a legal entity, but the workload is "not huge if you're already following good development practice," according to Kroah-Hartman.
The regulations are much more stringent for hardware or device vendors using open source code in their products than for pure software consultancies. For decades, hardware vendors have been using open source code without obeying the open source licensing rules, such as [10]Vizio using Linux in its smart TV . Under the CRA, they'll find it much harder to get away with this or [11]deny they're breaching open source software terms in their products, as Cisco did in 2008 with its [12]Linksys routers . (It ultimately settled the case, appointed a free software director, made source code for products available on its website, and made a donation to the FSF.)
Manufacturers are going to care in September of next year. They're going to start panicking in the summer of next year, and things are going to start hitting the fan...
You may think that since the CRA is an EU law, it won't matter to countries outside the EU. You would be wrong. The CRA effectively extends worldwide. If software is accessible "on the market" in the EU, it falls under the law's scope. Thus, US and Japanese vendors, for example, must pay careful attention to compliance if their products are downloadable or operable from within the EU.
For example, manufacturers must act on vulnerabilities, even if the upstream maintainer does not fix the issue. Manufacturers selecting open source code for their products must understand the code, support it, and respond to regulatory reporting requirements. This may, Kroah-Hartman observed, increase pressure on companies to use actively supported open source projects or stick closer to mainstream, well-resourced communities."
[13]
Will this make companies more wary of using open source software? Kroah-Hartman thinks it will have the opposite effect. The CRA also covers proprietary software. Instead of these new requirements creating a "chilling effect" on open source releases by nervous companies or legal departments, he thinks it will actually increase demand for open source, since companies gain more control over code destiny than with closed source vendors.
Businesses that are already using open source code in their programs still haven't realized just what a big deal the CRA will be for them. They will soon enough. Kroah-Hartman predicts, "Companies are coming after you [open source developers]. I will create a little form letter and say, 'Here's what you need to send off.'
"It's going to get worse because it's coming soon for companies. Manufacturers are going to care in September of next year. They're going to start panicking in the summer of next year, and things are going to start hitting the fan."
They'll want developers to shoulder the burden the CRA will place on them. But you don't have to do that. It's their problem, not yours as a programmer.
[14]Strap in, get ready for more Rust drivers in Linux kernel
[15]Linux royalty backs adoption of Rust for kernel code, says its rise is inevitable
[16]Even Linus Torvalds can have trouble with autocycle … autocracy… AUTOCOMPLETE!
[17]Linus Torvalds affirms expulsion of Russian maintainers
Of course, developers are encouraged to adopt best practices - eg, secure reporting, clear SBOMs, supply-chain checks - now. Foundations and large community projects are working with the EU to produce checklists and templates to simplify compliance. Kroah-Hartman reports that much of the ambiguity around commercial versus non-commercial obligations will be clarified in the coming year, with accessible implementation resources for projects.
In a Q&A session afterwards, Kroah-Hartman struck a hopeful note, "The goal here and the intent is not to trip up anybody in this room. The goal and intent are also to hold big companies liable when they release open source software, as part of that, because they want it not to be an end run around the CRA.
"Therefore, merging those two things together created a really wiggly line in the middle. But they are on our side. I've spoken with representatives from the different countries that created this law. They understand open source. They understand how the world runs in open source. They don't want to see it harmed by this at all. So have faith in that." ®
Get our [18]Tech Resources
[1] https://www.european-cyber-resilience-act.com/
[2] https://www.theregister.com/2023/05/12/eu_cyber_resilience_act/
[3] https://www.theregister.com/2023/04/12/python_management_eu/
[4] https://www.theregister.com/2023/12/04/infosec_in_brief/
[5] https://kernel-recipes.org/en/2025/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aNuqM8lzJulPSHxHo--4vwAAAIE&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aNuqM8lzJulPSHxHo--4vwAAAIE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aNuqM8lzJulPSHxHo--4vwAAAIE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aNuqM8lzJulPSHxHo--4vwAAAIE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://www.zdnet.com/article/software-freedom-conservancy-sues-vizio-for-gpl-violations/
[11] https://www.computerworld.com/article/1511569/open-source-isn-t-free-software.html
[12] https://www.theregister.com/2009/05/21/cisco_open_source/
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aNuqM8lzJulPSHxHo--4vwAAAIE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[14] https://www.theregister.com/2025/03/10/rust_drivers_expected_to_become/
[15] https://www.theregister.com/2025/02/21/linux_c_rust_debate_continues/
[16] https://www.theregister.com/2025/02/18/linus_torvalds_autocomplete_mistake/
[17] https://www.theregister.com/2024/10/23/linus_torvalds_affirms_expulsion_of/
[18] https://whitepapers.theregister.com/
Re: I wonder..............
Claude Yeller
"if any of this applies to the good folk "distributing" ransomware?"
Of course, it applies. It just comes on top of all the other criminal charges. Not that anyone thinks this will matter to them.
But think of Al Capone who was being convicted to 11 years in prison for tax fraud. Not for any of his numerous, much more serious crimes including many murders.
Re: I wonder..............
Doctor Syntax
As I keep saying, you do not discourage people intent on breaking laws by providing them with more laws to break. That's despite anyone writing legislation ignoring that simple fact.
Compliance is the same overhead for all producers :(
Peter Prof Fox
Suppose I make a tiny app for smartphones to remind people when it's time for them to face Totnes and worship me. Not only is there a stack that feeds to the source code but then a compile and package stack which is weird blackboxes. Am I supposed to monitor all of that for as long as anybody might be using the program? If so how? A red tape impossibility. When I get an email to 'security@' saying stuff, the obvious action is 'into the spam and blocked'. Different devices will have different stacks. Should I have a single document full of everything possible?
Large outfits have the same overhead as me. Proportionally mine is huge.
The proper approach is to use Product Liability. If I buy a security camera which is compromised (And I find out. How likely is that?) then I sue the seller and they can sue anybody they like upstream. It isn't a matter of what might happen but what has actually happened. Shambolic software is a big problem but the bad and lazy will carry on as before. What happens then?
Re: Compliance is the same overhead for all producers :(
alain williams
The proper approach is to use Product Liability.
Presumably liability is not just about suing people it is also about fixing things. If there is a bug in code the camera manufacturer can get his programmers to fix it or encourage (ie pay) the open source author to do so. What is the cheapest way ? If the code is non trivial prolly paying the author - which also complies with the GPL requirement to make available this code fix.
So this could result in those who use open source code paying the authors - I expect that they will do so begrudgingly and as little as possible.
It will be interesting to see how this plays out.
Theory vs real world
b0llchit
The theory of the arguments, that most FOSS people/projects are in the clear, is not yet tested. The courts will eventually decide the fate of the regulation and the persons/organisations involved.
Let us just hope that some "lone" developer, who made some significant library and received some very small payment for working on it, will not become the focus of lawyers and governments as an "example".
I wonder..............
...........if any of this applies to the good folk "distributing" ransomware?
I guess that the "enforcers" in the EU would have to find them first!!