Securing Open Source Software Act of 2022

This bill was just introduced last week – what do you all think?


There is a lot of very specific language used in the bill. It’s as if they copied material that was submitted to them from earlier hearings. Or from what was given to them from a lobbyist.

1 Like

If someone can get Senator Peters to speak about this bill when CloudNativeCon is in Detroit, that would be a coup.

Thank you, @epicfaace, for posting these! Great coverage of the issue.

@LawrenceHecht, I don’t understand what you’re trying to say in your comments. Of course this is iterative work, and, yes, there are people lobbying on behalf of this bill.

In general: My main questions are - what provisions are there for helping open source projects make SBOMs. I’m not sure they even make sense from a dependency point of view, and they add a ton of work for maintainers. It sounds to me like this is asking for yet more work from OSS maintainers, not less.

I also think that some federal agencies have almost certainly already made studies of the security of their OSS dependencies. Curious to see how those will be worked in on public record.

Cool stuff. Good to see Trey quoted in particular - he’s been doing great work.

I was being reactionary. I mostly want to know who is lobbying for the bill.

I’m also interested in who will co-sponsor the bill next session. I’m assuming this won’t get appended to an omnibus package and will have to be re-introduced next year.

1 Like

These are crucial initiatives; thanks for sharing the links!

I’m curious; did PlainText have any connections with this bill since there was already an OSPO proposal under the incubator program?

Here are some questions/feedback:

As mentioned in the last “Sustain Together” meeting, the bill doesn’t refer to OSI regarding open-source software definition. Is there any specific reason for this, like it’s better to stay generic? And is this a trivial detail?

About the Open Source Risk Assessment Framework, they plan to make the software/algorithm open source and share the results/datasets publicly. Making the entire process open/public would be essential; the community should review which software is/becomes critical under which conditions.

Last, the bill’s primary focus is security again, which can be an easy sell and a good start.

However, these conversations will become more exciting once we acknowledge the economic value of the open-source ecosystem and start addressing our systemic failure of collective investment (giving back the fair share of the value that the ecosystem generated in the economy).

If/once there are national OSPOs, the OSS community could/should use these opportunities and proactively help them expand in such directions.

1 Like

Some additional coverage here:

I agree it is concerning that the authors don’t seem to be making themselves known. I have my hunches…

1 Like

As mentioned in the last “Sustain Together” meeting, the bill doesn’t refer to OSI regarding open-source software definition. Is there any specific reason for this, like it’s better to stay generic? And is this a trivial detail?

I believe this is not a trivial detail.

Working for the OSPO of the French gov, I confirm it is critical to have a definition of FLOSS based on a list of licences.

We explicitely have a consensual and restricted one: (1) FLOSS-for-fr-gov encompasses software published under a license that is approved by both the FSF and the OSI, as per SPDX License List | Software Package Data Exchange (SPDX) and (2) we allow ourselves to decide whether a variant of a license within this list is FLOSS or not.

1 Like

I can not read legalize, so I haven’t read the the text. Two things are concerning me:

  1. Preserve the ability to release the code out of copyright limitations (e.g. public domain). If I remember correctly, the code that is developed by government agencies using public money should be put into public domain, so that everybody could have equal right reusing this code. I believe that’s how OpenStack became possible. Just to remind - SPDX erases the notion of public domain, replacing it with license.

  2. It is so easy to attack individual developers as “insecure” sources of software, by disregarding public review practices and multistage release process, meaning that the Act could do worse by forcing companies to use only OSS from trusted vendors. This will replace Open Source with open core, erase the community, will place restrictions on funding. And as a result we will get less diverse and awesome projects. Not speaking about code that is written by pseudonymous people to avoid them being hired by somebody else, or whatever. Open Source should not only mean “code”, but also preserver developers freedoms to be known, and to communicate freely.

I came across the cost estimate for this bill :point_down:

CBO estimates that implementing the bill would cost $275 million over the 2023-2027 period.

And here are the remarks from Dustin Ingram, one of the board members of PSF:


Thanks for sharing @coni2k, I missed the tweets.


These government Bills aren’t about helping OSS financially. But they’re about how to impose more restrictions on this industry. F.E. the EU version of the OSS is looking for pursuing OSS developers with criminal charges.

In a similar way, the EU act for AI would be disastruous for OSS projects and computer science researchers. It’s about how to preserve monopolies in favor of BigTech corporations

" Under the EU’s draft AI Act, open source developers would have to adhere to guidelines for risk management, data governance, technical documentation and transparency, as well as standards of accuracy and cybersecurity."

1 Like

Thanks for sharing these articles, @nebairevelations!

About the Cyber Resilience Act, here are my quick takes:

The proposal aims to address the growing number of cyberattacks which are getting increasingly costly:

“Hardware and software products are increasingly subject to successful cyberattacks, leading to an estimated global annual cost of cybercrime of €5.5 trillion by 2021.”

Here are the four objectives of the proposal:

  1. Ensure that manufacturers improve the security of products with digital elements since the design and development phase and throughout the whole life cycle;
  2. Ensure a coherent cybersecurity framework, facilitating compliance for hardware and software producers;
  3. Enhance the transparency of security properties of products with digital elements, and
  4. Enable businesses and consumers to use products with digital elements securely.

According to the fact sheet, 90% of the products will fall under the “Default” category (as @osioke pointed out in the other thread).

And there is a specific exception for non-commercial open source software (Page 16 - Recital 10):

“In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation.”

Ensuring we have standard security processes/frameworks throughout the industry would help address the growing cyber threats. So, overall, I see it as a “well-intentioned” initiative.

About adding a burden on the OS initiatives, first of all, it would be great to have a good list of commercial OS initiatives that can fall under the critical category (requires auditing). According to their article, NLnet is one of them, but it may not be a long list.

On the other hand, the proposal is currently open for feedback. Shouldn’t we use this as an opportunity?

Ask the EU to set up a dedicated budget for the (commercial or non-commercial) critical OS initiatives (especially from the EU) to cover the arising auditing expenses from this regulation. Then, we can ensure that the OS solutions are still up to the same security standards while not adding any financial burden.

So, I suggest listing our concerns and improvements and sharing them as our feedback, maybe as the Sustain group? We can organize a meeting to discuss this proposal if you wish.

Here are all the links I found as a quick reference:


At ISC, we are working with NLNET Labs (Maarten Aertsen, the author of the blog linked above) to try to gather together impacted projects (critical, sustained with ‘commercial services’) to see if we can coordinate our comments on the CRA. We haven’t decided yet what sort of relief we might look for, but possibly an exception for small businesses, or non-profit organizations. I haven’t catalogued all the requirements of the CRA, but the requirement that concerns me the most is the requirement to hire an external auditor. For a small organization even engaging with an auditor is going to be onerous, let alone paying them.


“given enough eyeballs, all bugs are shallow” (c) Linus's law - Wikipedia

if all you have is a hammer, everything looks like a nail” (c) Law of the instrument - Wikipedia

I assume lawyers and legislators practicing the latter while being unaware of the former. The cause of security problems is that Open Source people are losing grounds to review each other’s code. Outsourcing management practices alone perfected selling people time too well to squeeze every hour and ensure they won’t have anything left to work in public. Add here non-compete, NDA, and other papers. People don’t have much time anymore. They can’t enjoy (I can’t enjoy) working on my things when I know that my basic needs are no closed.

How can legislation reduce the stress, the dependency, get more money to OSS folks? In my opinion it can not. At least I don’t see any generic solution written on paper that can not be hacked by guys who are hunting for money. It can only be done by open, transparent support network.

Do we really need government oversight on programmers activity ? Remember the inventor of the PGP algorithm, (that one that you’re using in your email application and powered internet protocols) ? Zimmermann was prosecuted by the U.S. government because military agencies felt threatened about commoners obtaining the same cybernetic superpowers as them?

Remember, that Free Open Source Software movement is all about FREEDOM!!

This is a bold assertion. Could you please provide secondary sources about it?

That’s just obvious for anybody in the scene. Take a look at how many people maintained OpenSSL before HeartBleed. 💔What is the Heartbleed Vulnerability? Or what GraphicsMagick maintainer says in the latest News:

GraphicsMagick really does need some additional productive volunteers. For several years now, the burden has entirely been on me (Bob Friesenhahn). I have been sheparding the project for 20 years already (and contributed to ImageMagick and GraphicsMagick combined for 26 years already). It is not reasonable to expect someone with a full time job (and expecting to retire in a few years) to do all of the work.

I personally filled a story with critical flaw in Python’s zipfile library that prevents one of the top voted feature for Python Package Index to be implemented. And there are no people to even say if I am right or wrong Zip Bomb protection for wheels · Issue #10504 · pypi/warehouse · GitHub No responses from security teams either. What all these people are doing if they have the time?

Sounds great; I’d love to see that list, and I’d be happy to help if there’s anything I can do.

Loved the article/video and will watch the rest! :100:

I understand the distrust, but that’s quite a stretch. There is a valid issue here, and the proposal aims to address it. There might be side effects to the open source ecosystem, but let’s focus on improving it and sharing our feedback.

I will join this week’s Sustain call. If it’s okay for everyone, we can discuss this proposal again.

Plus, OpenForum Europe is also organizing a special meeting for this proposal next week on the 6th:

Next week, 6 December, we are hosting an extra long OFE Community Call focusing on the Cyber Resilience Act (CRA) (17:00-18:00 CET).

We have invited a number of representatives from organisations working on the CRA who will share their thoughts on the proposed law. The particular focus is Recital 10 attempting to exclude certain modes of OSS from the scope of the law.

  • 17:00-17:30: Invited speakers share their views
  • 17:30-18:00: Open discussions on CRA implications and paths forward