As part of Maintainer Month—a time to recognize and support the open source maintainers who keep our digital infrastructure running—Open Regulatory Compliance (ORC) is hosting a special panel on 27 May. Among the featured speakers is Felix Reda, who will share insights in the session titled, “The Cyber Resilience Act and Open Source: What Maintainers Really Need to Know.”
Felix (he/they) is the Director of Developer Policy at GitHub. He has been shaping digital policy for over ten years, including serving as a Member of the European Parliament from 2014 to 2019. His areas of interest encompass copyright, freedom of expression, and the sustainability of the open source ecosystem. Felix serves on the board of the Open Knowledge Foundation Germany. He holds an M.A. in Political Science and Communications Science from the University of Mainz, Germany.
We asked Felix a couple of questions so that attendees could learn a bit more about his work and his thoughts on the Cyber Resilience Act in advance of the session later this month.
Can you tell us a bit about your background, including your work with cybersecurity and/or the Cyber Resilience Act (CRA)?
I am a former Member of the European Parliament. When I got elected in 2014, open source was not a subject of EU laws and rarely featured in policy discussions. I managed to convince the European Commission to start spending part of the EU budget on the security of open source software after the Heartbleed vulnerability (EU-FOSSA pilot project) and included an early mention of free and open source software in the 2019 Digital Content Directive. Just like with the CRA, my objective back then was to ensure that regulation would support open source developers rather than burdening them with regulations that fail to consider their contributions to the public interest. I think the negotiations on the Cyber Resilience Act has shown that the EU legislator has been willing to learn about open source, but we will have to continue to work together across government, industry, and the open source community to get the details of the legislation right.
How would you describe the CRA to someone who doesn’t understand it? Why should we care?
The CRA has a noble goal: To protect consumers of software products from all kinds of cyber threats. Nobody wants their smart fridge to become part of a botnet or their smartphone to stop receiving security updates just a couple of years after purchase. The CRA makes software manufacturers responsible for the security of their offerings. Where it gets tricky is when trying to assign that responsibility in complex supply chains that include a lot of under-resourced, critical open source components. The CRA generally puts the responsibility on those commercialising the software, but the devil lies in the details. We want to balance the laudable goal of increased software security with keeping the barriers of entry to open source development low and making sure that open source maintainers are supported in their hard work for the public good.
How do you see the CRA impacting open source projects and the people who maintain them?
I think the software industry will adapt to tighter cybersecurity legislation, but making sure that solo maintainers or small projects that don’t have the resources to hire a lawyer know exactly what to do will be the greatest challenge. That’s why we are working with the European Commission and the open source community on guidance that should bring greater clarity about which open source projects fall under the CRA and which do not. GitHub has published a blog post that summarises key passages of the law, but open questions remain that should be answered in the guidance.
What advice would you give to maintainers of open source software right now? What steps should they be taking, if any?
If you receive a scary-looking letter full of legalese from a company demanding that you demonstrate your compliance with the Cyber Resilience Act, don’t panic! The reason the company is contacting you is most likely that the company is legally required to ensure its open source dependencies are secure - that doesn’t automatically mean that any legal obligations fall on you. In the best case, the company will offer to help you invest in security and contribute its own vulnerability fixes back to the project. That can even end up benefiting your project and its users. GitHub offers security resources such as the GitHub Secure Open Source Fund, or our Open Source Guide: Security Best Practices for Your Project.
Add it to your calendar to join.
Participate with the ORC
- Follow us on social: BlueSky, LinkedIn, and YouTube
- Learn
- Contribute
- Join the Working Group
