No, there are plenty of circumstances where there laws and/or contractual obligations other than software licenses become involved in software development which can conflict. See healthcare, government, finance, regulated industries, etc.
I've worked in several of those industries. Oddly enough, open source was always easier there. I'd challenge you to find a regulation which prevents open source in any of those industries.
I think the one exception -- and this was an extreme example -- was the firmware of a medical device which could endanger human lives if modified. Things were locked down.
But generically? I'm batting maybe 75% with open source in highly-regulated industries.
ITAR? Any contract work under an NDA? Sensitive government work? Any code that implements trade secrets? Any custom enterprise software with hard-coded exceptions for controlled data?
You can certainly use open source in regulated industries -- the question is, can they risk the legal possibility of being forced to open source the rest of their stack if the a court determines AGPL requires it.
I'm not saying everything done is open source. I'm saying it's less common in regulated industries.
NDA / sensitive government work -> FOIA makes restrictions tough. I can request government source code.
Trade secrets -> The government can't really keep trade secrets. I guess if I were working with classified code?
Hard-coded exceptions -> Not specific to regulated industries but bad design.
Legal possibility -> This is not a legal possibility. A legal possibility is paying damages. It's the same if I break a proprietary license too (for example, accidentally ship out a copy of a library I paid for just one license with my product).
FOIA has a substantial list of exemptions, and many of them would apply to a lot of code that the government uses.
Above, I was referring to trade secrets in the private sector, but actually, that is one of the FOIA exemptions too.
Also, a lot of code running in production is poorly designed. I'd bet the vast majority of it is poorly designed.
Damages are one part of it, but you also have to return to compliance, which means you either have to follow the license or stop using the code. Given that the AGPL doesn't have linking exceptions, the concern is that might be all of an organization's code.
That's not to say that you can't use open source in industries where these might be concerns -- almost all other common open source licenses don't have this problem.
I think you'll find few people who are willing to make changes to those things just to implement an AGPL library --- and even fewer who would call it a "simple solution".
I don't disagree with that. My point is that historically, it's been their choice and as a result it's been mostly their loss. When there is will to use the software, but they refuse to take the time to understand the licensing or dismiss it as not being simple enough, the other corporate entities behind it will gladly overcharge them for some kind of proprietary license or legal consultancy scheme.
Proprietary licenses aren't the only alternative to the risk of the AGPL (whether real or perceived). For example: I've never heard of a corporate lawyer having finding issue with an MIT or Apache license.
I've run into lots of libraries over my career with vague, conflicting, or otherwise questionable licenses. So far, 100% of the time I've been able to easily find an alternative open source project with a better, more clear, license. If both get the job done, I'll pick the one that doesn't keep me up at night every time.
