This is very good that we have so many experts/vendors expressing their opinion (read: fears on how it will affect them).

However, I welcome everyone to read https://digital-strategy.ec.europa.eu/en/policies/cyber-resi... and understand why CRA was created, what it tries to solve, and most importantly, why EU legislators INTENTIONALLY decided to make open-source part of the regulation.

Regarding the OSS more specifically: most EU businesses rely on open-source software in prod (Linux, Nginx, OpenJDK etc.). Vulns in the software including those in OSS amount to 5.5 trillion EUR losses every year [1] (edit: quite a wild projection, disputed, see the thread below). CRA wants to ensure that if a business (especially an SME w/o a dedicated itsec team) sees software online, which looks usable "in the course of a commercial activity" and receives regular releases, that its last release is reasonably free from known significant vulnerabilities.

Please note that https://pyfound.blogspot.com/2023/04/the-eus-proposed-cra-la... is no longer valid as amendments were made to specifically exclude PyPi, Git and other hosting platforms from any liability.

I also expect a positive outcome from all this. Companies (at least, in EU) will begin requiring their dependencies to be CRA-compliant some time in the future and it will open up a path for devs to get paid for the extra burden.

Finally, this is a wake-up call for all software developers to consider what needs to be changed in development practices before we can proudly call ourselves software ENGINEERS.

[1]: https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-...

> it will open up a path for devs to get paid for the extra burden.

The thing is, being paid for an extra burden doesn't make it any less of an imposition on devs limited energy.

Basically, if you want to accept donations so people can show their appreciation for what you share freely with the world, you open yourself up to demands that you do work that you don't enjoy on a hobby. That's really shit.

I don't think this legislation will affect hobby projects. The problem is that whether the project is hobby or not is judged from the side of the consumer, i.e. if the software is usable "in the course of a commercial activity" (for the user). I agree that this creates a certain amount of stress, esp. for individual devs, but I think it was necessary to make sure that projects like k8s, kafka, and other OSS projects consistently relied on by businesses cannot claim that the OSS version is not for commercial use. And with that run-around statement, be done with CRA "compliance".

Do you know if the requirement is:

* that a project is developed AND supplied commercially?

* or rather that a project is developed OR supplied commercially?

For example if I write an experimental project at work which might have vulnerabilities (developed commercially), which my employer has no intention of selling yet (not supplied commercially), should I still follow the CRA processes in case someone reports a vulnerability? What if someone else decides to take my toy project and put it into their product?

Here is a snippet from the EU Blue Guide linked the from the Eclipse blog post:

"Commercial activity is understood as providing goods in a business related context. Non-profit organisations may be considered as carrying out commercial activities if they operate in such a context. This can only be appreciated on a case by case basis taking into account the regularity of the supplies, the characteristics of the product, the intentions of the supplier, etc. In principle, occasional supplies by charities or hobbyists should not be considered as taking place in a business related context."

I would consider GCC or React to fit this definition, while a hobby project like https://github.com/rui314/chibicc not to fit it.

Edit: I don't think you would have any obligations under CRA unless you make a project release available, whether commercially or on Github. The 3-part test I mentioned above only kicks in when there is a release of some sort in the first place.