>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 b

>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.