2 ms·

This has nothing to do with patches. The problem is that when someone from EU intends to use the software of the dev from Nebraska, the dev from Nebraska may be

This has nothing to do with patches. The problem is that when someone from EU intends to use the software of the dev from Nebraska, the dev from Nebraska may be contacted to provide a proof that their software meets certain requirements. The dev from Nebraska may don’t care, I would not… but the EU-based dev cannot use that bit of software in a bigger commercial part, even if the license allows it. The EU-based dev may opt for doing their own certification of that component. It’s gate-keeping at its best. This is a blow to SMEs and a protectionist move on behalf of large enterprises. In my head, the reasoning is the following: certification will be another bureaucratic process to follow. It will cost money, it will require human resources on both sides, it will feed some companies who don’t have to do shit to turn profit—companies started to feed on others as those who “certify”, it will most likely imply that someone from the bureaucratic machine will look into your source code -> trade secrets, anyone? Big players (not going to name them here) like companies like SA…, De… Te… have enough resources and financial backing to push through that. The point is, they cannot compete with OSS on dev pace, they found a workaround - kill OSS and impact SMEs by putting a legal barrier to entry. On a personal note, as an EU-based person, I start getting fed up with this shit.

captainmuon 3y ago
That's great, the company who wants to sell stuff in the EU pays for the audit and the bugfixes, and it benefits all. As a PM in a previous position, I would have loved to fix known bugs, contribute back to open source, audit things properly. But when there was no legal pressure to do so, my bosses (understandably) said: great, that software is for free, take it, don't put to much work into it, ship it. Like it or not, open source software is part of our supply chains, and if there is no incentive to maintain it properly then that's a big problem.
- rad_gruchalski 3y ago
  You assume that companies will share audits they conducted for free with everyone as a public service. Edit: there the other side of the coin. A single dev who wants to enter the market has an uphill battle. He is required to certify their own work, and provide audits of all dependencies. Good luck starting a business from your bedroom un such climate. If this is what people in the EU want, paraphrasing: I don’t want to live on this continent anymore.
  - xoa 3y ago
    >You assume that companies will share audits they conducted for free with everyone as a public service. It depends, but in general there is significant, straightforward incentives to upstream most stuff. It makes things a lot cheaper over the long term for all involved, and particularly with security/stability and basic code hygiene there is basically never going to be any "special sauce" there where the company is getting some major additional value. It's all cost centers. So if an EU-based company audits and then needs to make some changes to a non-EU-based project, I'd assume by default they'd want all those changes upstreamed and made permanent since it'd reduce the burden going forward. Though again this is all highly speculative based on how it actually works. Also >A single dev who wants to enter the market has an uphill battle. He is required to certify their own work, and provide audits of all dependencies. Good luck starting a business from your bedroom in such climate. It is true I'm thinking of it from a non-European point of view, where it's not starting from scratch and by default it's not my problem. I'm not trying to downplay possible disincentives in those in the EU starting projects de novo. I just don't know enough about it.
    - rad_gruchalski 3y ago
      > So if an EU-based company audits and then needs to make some changes to a non-EU-based project, I'd assume by default they'd want all those changes upstreamed and made permanent since it'd reduce the burden going forward. Humans aren’t behaving logically. If a company A audited their dependencies, it doesn’t benefit them at all to “upstream” their audits because: 1) dependencies are already audited for that company and only new version has to be audited in the future, 2) holding an audit will be a competitive advantage because everyone else has to consume their resources to get audits in place, 3) “my people on my salary got those audits for me so if I had to pay for it, the others have to pay, why should I share that when I paid for it, it cost money and sweat, nobody’s getting it for free”.
xoa 3y ago
>This has nothing to do with patches. The problem is that when someone from EU intends to use the software of the dev from Nebraska, the dev from Nebraska may be contacted to provide a proof that their software meets certain requirements. I guess it depends on what counts as "proof", is that clear yet? I was thinking that if certain code practices and such were enough, then maybe an EU-based dev would then contribute the changes necessary to meet that should the original maintainer(s) not be interested, or fork it to do so. The details really matter, there are certain best practices that are a perfectly good idea anyway and also don't hurt future maintainability or the like at all, so the ideal would be something that encourages making such changes and then effectively "goes away" as a concern. Removing old ciphers/hash functions completely for new products for example, government might usefully provide industry a kick in the butt there, but once someone has moved on from MD5 it's not like they'd need to think about it again. As you say though if it instead turns into an expensive bureaucratic mess, or as bad or arguably even worse pushes anti-maintainability/security practices (which has happened! in the US there was a long period of awful anti-security password policy stuff floating around that came from outdated "best practices" reqs), then that'd be a major issue. And regulatory capture is indeed always a concern with new acts like this too.
- rad_gruchalski 3y ago
  > I guess it depends on what counts as "proof", is that clear yet? Audits are discussed everywhere.

captainmuon 3y ago

That's great, the company who wants to sell stuff in the EU pays for the audit and the bugfixes, and it benefits all. As a PM in a previous position, I would have loved to fix known bugs, contribute back to open source, audit things properly. But when there was no legal pressure to do so, my bosses (understandably) said: great, that software is for free, take it, don't put to much work into it, ship it. Like it or not, open source software is part of our supply chains, and if there is no incentive to maintain it properly then that's a big problem.

rad_gruchalski 3y ago
You assume that companies will share audits they conducted for free with everyone as a public service. Edit: there the other side of the coin. A single dev who wants to enter the market has an uphill battle. He is required to certify their own work, and provide audits of all dependencies. Good luck starting a business from your bedroom un such climate. If this is what people in the EU want, paraphrasing: I don’t want to live on this continent anymore.
- xoa 3y ago
  >You assume that companies will share audits they conducted for free with everyone as a public service. It depends, but in general there is significant, straightforward incentives to upstream most stuff. It makes things a lot cheaper over the long term for all involved, and particularly with security/stability and basic code hygiene there is basically never going to be any "special sauce" there where the company is getting some major additional value. It's all cost centers. So if an EU-based company audits and then needs to make some changes to a non-EU-based project, I'd assume by default they'd want all those changes upstreamed and made permanent since it'd reduce the burden going forward. Though again this is all highly speculative based on how it actually works. Also >A single dev who wants to enter the market has an uphill battle. He is required to certify their own work, and provide audits of all dependencies. Good luck starting a business from your bedroom in such climate. It is true I'm thinking of it from a non-European point of view, where it's not starting from scratch and by default it's not my problem. I'm not trying to downplay possible disincentives in those in the EU starting projects de novo. I just don't know enough about it.
  - rad_gruchalski 3y ago
    > So if an EU-based company audits and then needs to make some changes to a non-EU-based project, I'd assume by default they'd want all those changes upstreamed and made permanent since it'd reduce the burden going forward. Humans aren’t behaving logically. If a company A audited their dependencies, it doesn’t benefit them at all to “upstream” their audits because: 1) dependencies are already audited for that company and only new version has to be audited in the future, 2) holding an audit will be a competitive advantage because everyone else has to consume their resources to get audits in place, 3) “my people on my salary got those audits for me so if I had to pay for it, the others have to pay, why should I share that when I paid for it, it cost money and sweat, nobody’s getting it for free”.

xoa 3y ago

>This has nothing to do with patches. The problem is that when someone from EU intends to use the software of the dev from Nebraska, the dev from Nebraska may be contacted to provide a proof that their software meets certain requirements. I guess it depends on what counts as "proof", is that clear yet? I was thinking that if certain code practices and such were enough, then maybe an EU-based dev would then contribute the changes necessary to meet that should the original maintainer(s) not be interested, or fork it to do so. The details really matter, there are certain best practices that are a perfectly good idea anyway and also don't hurt future maintainability or the like at all, so the ideal would be something that encourages making such changes and then effectively "goes away" as a concern. Removing old ciphers/hash functions completely for new products for example, government might usefully provide industry a kick in the butt there, but once someone has moved on from MD5 it's not like they'd need to think about it again. As you say though if it instead turns into an expensive bureaucratic mess, or as bad or arguably even worse pushes anti-maintainability/security practices (which has happened! in the US there was a long period of awful anti-security password policy stuff floating around that came from outdated "best practices" reqs), then that'd be a major issue. And regulatory capture is indeed always a concern with new acts like this too.

rad_gruchalski 3y ago
> I guess it depends on what counts as "proof", is that clear yet? Audits are discussed everywhere.