The conversation about open source security has shifted dramatically since 2020. Executive orders, regulatory proposals, and industry standards now reference open source software explicitly. SBOMs are becoming mandatory. Vulnerability disclosure is being regulated. Supply chain security requirements are cascading down to every software producer.
This is, broadly, a good thing. The software industry needed more accountability for supply chain security. But there is a problem with how these requirements are being implemented: they are landing on people who never signed up for them.
Open source maintainers are volunteers. They wrote software and shared it. They did not agree to SLAs, compliance obligations, or regulatory reporting requirements. Yet the new wave of supply chain security regulation treats them as if they did.
The tension between legitimate security demands and the reality of open source maintenance has generated a growing conversation about maintainer rights. Call it the open source software bill of rights.
The Demands
The demands on open source maintainers have escalated rapidly:
SBOM generation. The US Executive Order on Improving the Nation's Cybersecurity (EO 14028) and subsequent NIST guidance require software producers to provide SBOMs. For commercial software that includes open source components, this means someone needs to produce accurate component inventories. That burden often falls upstream to open source projects.
Vulnerability disclosure compliance. The EU Cyber Resilience Act (CRA) initially proposed requirements that would have applied directly to open source developers. After community pushback, the scope was narrowed, but the regulatory direction is clear: vulnerability handling is being formalized and mandated.
Security attestations. Some frameworks require attestations about software development practices: code review policies, build integrity, dependency management. These attestations take time to produce and maintain.
Timely patching. Enterprise consumers increasingly expect rapid patches for security vulnerabilities, with turnaround times measured in days rather than weeks. This expectation exists regardless of the project's funding status.
Each of these demands, taken individually, is reasonable. Collectively, they represent a massive increase in the work required to maintain an open source project, imposed without any corresponding increase in resources.
The Rights
In response, the open source community has begun articulating a set of principles that should govern how these demands are applied:
The right to volunteer. Open source maintenance is voluntary. Maintainers should not be treated as unpaid contractors with obligations they never agreed to. Using open source software does not create a vendor-customer relationship.
The right to step away. Maintainers should be able to reduce their involvement or leave a project without being shamed, threatened, or held legally liable. Burnout is real, and the threat of regulatory liability accelerates it.
The right to set boundaries. Maintainers should be able to define the scope of their responsibilities and communicate them clearly. "I maintain this library. I do not provide 24/7 security response for your product" is a legitimate boundary.
The right to funding before demands. Organizations that want enterprise-grade security practices from open source projects should fund those practices. Demanding compliance without providing resources is extractive.
The right to recognition. Maintainers' contributions to the digital infrastructure should be recognized and valued. This includes recognition in regulatory frameworks, which should distinguish between commercial software producers and volunteer open source developers.
The right to participate in policy. When regulations affect open source development, maintainers should have a voice in the policy process. The initial EU CRA draft was widely criticized because it was developed without meaningful input from the open source community.
The CRA Negotiation
The EU Cyber Resilience Act provides the most concrete example of these tensions playing out in policy.
The initial CRA proposal would have applied security requirements to all software placed on the EU market, with limited exceptions for open source. The open source community raised alarms. The Eclipse Foundation, the Linux Foundation, the Python Software Foundation, and individual maintainers submitted comments arguing that applying commercial software obligations to volunteer-maintained open source would be counterproductive.
The key arguments were:
- Maintainers cannot comply with requirements that assume funded development teams
- Imposing liability would cause maintainers to stop distributing software in the EU
- The people who profit from open source (commercial redistributors) should bear the compliance burden, not the volunteers who create it
The final CRA text, adopted in late 2023, narrowed the scope to commercial activity. Open source software developed and distributed on a non-commercial basis was excluded from most requirements. "Open source stewards" (foundations that facilitate development) received lighter obligations than commercial entities.
This was a reasonable outcome, but it required sustained advocacy from the open source community. Without organized pushback, the regulations would have landed squarely on volunteers.
The Sustainability Connection
Maintainer rights and project sustainability are inseparable. You cannot demand enterprise security practices from a project that runs on zero dollars and volunteer time. The demands are legitimate. The funding model is not.
Several initiatives attempt to bridge this gap:
The Sovereign Tech Fund in Germany provides government funding to open source projects that constitute digital infrastructure. This model treats open source as public goods and funds them accordingly.
Tidelift's maintainer model pays maintainers to meet enterprise security requirements (security policies, timely patching, signed releases). This aligns incentives by paying for the work that enterprises demand.
OpenSSF's Alpha-Omega project funds security improvements in critical open source projects, including security audits, vulnerability response, and tooling improvements.
These are positive developments, but they cover a tiny fraction of the open source ecosystem. Most projects receive no external funding and are expected to meet rising security demands on their own.
What Consumers Owe
Organizations that consume open source software have obligations that they frequently ignore:
Contribute financially. If your product depends on an open source library, contribute to its maintenance. The amount does not need to be large. Even small contributions help, and they signal that the work is valued.
Contribute engineering time. Allow your developers to contribute fixes, reviews, and improvements to the projects you depend on. This is more valuable than money for many projects.
Respect maintainer boundaries. Do not file hostile issues demanding immediate fixes. Do not threaten legal action over unpatched vulnerabilities in free software. Do not treat volunteers like vendors.
Advocate for good policy. When regulations affecting open source are proposed, engage in the policy process. Support frameworks that distinguish between commercial and volunteer activity.
Invest in your own security. Do not outsource your security to upstream maintainers. Maintain your own SBOM, run your own vulnerability scans, and have your own incident response capability. You are responsible for the security of your product, not the maintainer of a library you chose to use.
How Safeguard.sh Helps
Safeguard.sh helps organizations meet their supply chain security obligations without pushing that burden onto upstream maintainers. Our platform generates SBOMs, tracks vulnerabilities, and provides security attestation data from your own infrastructure, independent of what upstream projects provide. When regulatory requirements demand supply chain visibility, Safeguard.sh delivers it from the consumer side, where the resources and the obligations properly reside. We believe in supporting open source sustainability, which means building tools that help consumers meet their responsibilities rather than tools that create new demands on volunteers.