And I am not alarmed at all BTW. I think this is actually great opportunity for Open Source Foundations and Open Source maintainers, to get really sustainable way of making great engineering to happen while maintaining their independence and “fun” and Open-Source ideals. That’s how I see consequences of those regulations. Yes some smaller projects might die out (but for example “Airflow Beach Cleaning” is all about making sure that all the smaller dependencies fo Airflow are supported by the money tunneled from Commercial Airflow users and Security funds to them - and more importantly to tunnel expertise, time and energy - so that they can thrive as well. But that’s really tangential and off-topic.
I think I understand you.
The legislation will force companies to upgrade as soon as something is out of support. And thus they will start demanding LTS releases, thus allowing them to not upgrade, continuing on as they currently do.
So the net effect of the legislation is more pressure on open source contributors to maintain support for longer. Is that what you’re saying?
Nope. I am saying that I don’t know what will be final effect. But looking at the money that are currently paid for commercial users to make security happen in Open Source (via Alpha-Omega. Sovereign Tech Fund, Sponsorships. Tidelift and many others) - I personally think it’s the opposite. Because commercial players have more responsibility there than “Open Source Stewards” - they will have to put money, not pressure in the system to fuflfill their obligations for the CRA.
That is precisely what the open-source organisation lobbied (and won eventually) when we discussed and debated on it in Brussels. Current “open-source-steward” status is - hopefully - going to drive this dynamics. That’s what many people in OSS foundations believe will happen - and you can also hear about “Open Source Steward” in the talk I linked above
And yes. I quite agree - this might be one more effect of CRA, there will be plenty of business opportunites to build middle-man 3rd-party companies that will be able to get paid by big users and contribute security fixes - and since backporting of security fixes to upstream will be all-but-mandated, it might for example mean that they will take over of LTS releases of python so that Maintainers will not have to do it.
That’s one of the possibilities that CRA will introduce. But we do not know yet enough details and market reaction to see the effect. We only know it will change heavily.
I appreciate your positive outlook, but that just sounds like a very naïve point of view to me. The “responsibility” you mention comes with no enforcement mechanism (beyond having the software they consume up-to-date), so I think it’s much more likely that they’ll spend the absolute minimum (no surprises there), externalise as much as possible (i.e. pressure FOSS projects) and whine to their regulator how impossible the requirements are.
At the same time you say
which seems to be in direct contradiction to “commercial players have more responsibility”? Finally, taking a screenshots from the talk you shared
… it also looks like “OSS stewardship” is going to not apply to many projects (i.e. projects developed for fun/interest or funded with grants and donations probably don’t fall under “development in the course of a commercial activity”). All in all, I don’t see how this legislation will effect a large overhaul of the industry – more likely than not it will shift things only marginally (though happy to be wrong about that!).
I think that sounds like a much more likely scenario. Those companies would probably even be willing to pay for extended long-term support, just because the cost of that will still be lower than the total cost of staying up-to-date (including the risk of breakage and cost of fixing that).
4 Likes
Maybe, but I suspect a lot will just try to apply pressure to volunteers by asking for free LTS support:
The post that started this thread didn’t include any offer of payment, just “hey, you should do this”. If that’s what this legislation will create more of, I can’t see it as a benefit.
1 Like
Oh, and I agree. My point was that if you tell them “sorry, no dice”, they might actually try to arrange paid LTS support, because in all likelihood it’ll still end up cheaper for them than living at HEAD.
4 Likes
Fair. Which means that it is absolutely correct for OSS providers to say “no” to people like the OP.
3 Likes
Yep. This is precisely what “Open Source Steward” status will allow them to do. If they fulfill “minimum requirements” (which will be much more lightweight than for commercial players) OSS Stewards (and projects within them) will be in full right to say “Deal with it” or “Pay for what you need”. Surely there will be pressure initially, but the legal framework set by CRA will - hopefully - make the pressure totally ineffective, as long as we - OSS community - stand firmly, prepare our own standards (we are doing it as we speak) that will be the base of “what OSS Steward should do to be OK with CRA”. So IMHO commercial users will have no options but buy their way out - either by funding OSS security efforts directly, or through 3rd-parties. That’s my assesment.
And yes I am witnessing the pressure already currently as member of the security team and security commitee - where every now and then we got a security report “Here are the 100 issues, fix them ASAP and immediately let us know when this will happen”.
For this we currently nicely reply - “Here is how you can help community, by providing “reproducible report” how this can be exploted, maybe also pay someone to analyse and do such reports if you have no expertise yourself”.
After CRA our response will be:
“Hey it’s you who need to take care of that according to CRA - we are doing our job (HERE LINK TO OUR PROCESS) - or you can put your engineering effort to provide the fixes (which by the way you are obliged to backport to upstream by the law). And BTW here is the list of 3rd-parties we know and funds you can pay to if you want to support efforts of the OSS community on security if you want to have less such problems in the future.”
Yes. My assesment (and again this is a guess) - those who will have no capacity, will not be part of the “Foundations/Stewards” will have hard time to comply and keep up - and either they will join a number of foundations “en-masse” or will be rendered to irrelevance by the market - simply neither commercial users, nor foundation based open source projects will want to use them as dependency and rely on them for security. This is how “whole industry” will be affected.
This is part of my “Airflow Beach Cleaning” project. We are going to eventually review ALL our dependencies - try to talk to every one of them and classify them - whether we want to:
- help the to (F)ix their problems - maybe suggest them to become part of foundations or improve their security processes etc.
- (F)ork and vendor-in relevant part of those if they are not responsive/willing to cooperate
- or (F)orego them - here different F could be used as well - if there is no-one responding, or gone, then we will find a way to replace them
Again my assesment is that similar exercise will be done by many projects and commercial users in the coming 3 years - and that will also reshape the market heavily.
BTW. If you would like to see it as well here is our Keynote with Michael from the Airflow Summit in September, where we explain how and why we do the “Airflow Beach Cleaning” project https://www.youtube.com/watch?v=f6gfoVJXWEE titled - “Security United: ecosystem with Alpha-Omega, PSF & ASF” - it also has a number of interesting observations we have so far.
And really sorry for taking that much of the discussion. I just wanted to say that this discussion might be based on “past” and “soon not relevant” assumptions.
And raising awareness of that is important.
Also the “money” I am talking about is already happening - Alpha-Omega actually pays me to run this project - and gives me even more money I can pay our dependencies to fix their problems - and I can spend a lot of my engineering time on it. This is all financed by the money that they have from Amazon, Google, Microsoft and other commercial players.
So … it’s already happening…
2 Likes
Sidenode
Just to let you know this is no longer the case, they are now indicating that this will only apply if the open-source code is commercial in nature (And even then some cases may not apply). Meaning python won’t be effected but down stream maintainers like Redhat which ship it in their commercial products will be.
Nope. Not really. Smarter people than me who were working in EU in the past (for example ASF VP of public relations - Dirk) participated and read it and discussed the scope of it multiple times and summarized it to all of us involved. It’s enough that you “put the software on a market”. This is actually equivalent to selling shoes or making them available for free. No matter if you get money for it directly or not, if the end user is affected and can use the shoes - both have to have “EU- compliant” label attached.
The regulation introduces however (as explained above) - the “Open Source Steward” entitty which - when it does not take any money, not for support, not for licencing, not for acces, but only gets money “to keep the steward running” will have lighter regime. This is what OSS Foundations lobbied for and this “OSS Steward” definition appeared in CRA merely two weeks before the final text of CRA was agreed (in March or so) - before that some people in some Foundations were really seriously considering running a “black week” in a protest where downloads and website access from EU would be blocked - because they were under same obligations as commercial users.
So no, you are wrong.
Absolutely PSF is going to put Python “on the market” in the EU and it will be following the “Open-Source Steward” part of the regulation, not the “Commercial user”. Details on how the “lighter regime” will look like is something that people in many foundations now scramble to define so that it makes sense.
Well EU might have to speak to all the open source lawyers contradicting them in that case and I’ll have to start pulling all of my open source projects from Github.
The EU managed to make everyone add the stupid cookies for GDPR (which BTW they are working on changing back to make it more reasonable as they learned from their mistakes). And one of the points they considered during the discussion is “who we will lose” and "what will be more costly - to have some projects leave, or to have EU residents more exposed to “log4j” kind of vulnerabilty (which was actually when politicians realised about the problem society has with commercial users not doing enough to protect the end users).
And this is why they added “Open Source Steward” because they realized that loosing all the “Reputable Foundation” managed projects would be more costly than what they want to prevent. So yes, they actually discounted the fact that people like you will pull their projects. And they considered it less costly for general public than introducing CRA.
BTW. Apparently there are still 13% of non-upgraded log4j instances that are vulnerable to the critical, remotely exploitable issue - after almost 2.5 year. Currently there is no regulation to force them to upgrade. When CRA is in place - those 13% of businesses will face financial and criminal penalties (well they won’t because they will actually upgrade faster to avoid it).
The change was to add the need for consent to have the cookies track users. The cookies were already there.
I also do not think it was stupid to give a person control over tracking.
Could the end goal have been achieved with beteer regulation?
I am sure it could have been.
6 Likes
The change was to add the need for consent to have the cookies track users. The cookies were already there.
Oh absolutely. Thanks for correcting my “mental shortcut”. I of course meant “the stupid way people have to confirm their consent”. And yes i agree the goal was great, the execution failed though.
This is also why all the open-source foundations got involved from the very beginning and basically banded together (with the help of Open Forum Europe think-tank) and took active role in defining first the regulations, and now the standards - to make sure what comes out of it is not “stupid”. And EU apparently learned to listen and cooperate with the experts from the field, and what the final text of CRA is actually universally considered as positive by pretty much all the “open source practitioners” who took part in it.
I don’t see two different subjects and objects.
The products and services industry, including the hardware and software sectors, is already subject to stringent regulation, particularly in the European Union (EU).
The security risk assessment has already begun, for example, there were a requirement for an update to Ubuntu 24.04 before its release (despite being unaware of the release delay).
Despite the rigorous regulations in the EU and the ongoing security assessments, it seems like we’re all set—what could possibly go wrong?
Yeah, this will be fun. All the research projects that often release research will be pulled or projects just showing code samples
Only workaround I can see is a big disclaimer saying “you are at risk”
Off topic, but should have been regulated at browser level I.e user should and could have been promoted
1 Like