It's especially interesting that the author has open source experience, and decides to put a company that went through a ransomware attack as a way of discussin

It's especially interesting that the author has open source experience, and decides to put a company that went through a ransomware attack as a way of discussing liability. Imagine for a second that the ransomware attack comes via an attack vector because, say, there's a security bug in Spring, giant Java library/ecosystem, that almost everyone pays zero for. Then imagine that this is in a world where the engineer is liable. How does this play out? First, you could claim that the bug is in OSS Spring, and that they can't waive liability. In that circumstance, I'd be surprised if OSS continued existing: You get very little for your contribution in comparison to the liability risk. It's the same for corporate sponsored OSS: Imagine telling your company's counsel that you want to open source a library that is unrelated to the core of your business. Never. So this either has cataclysmic consequences to OSS, or we get to say that anyone making OSS's legal disclaimers are legally binding. So what happens instead? Anyone building applications for a company is responsible for all the bugs in the libraries they chose. OSS will still be mostly poisoned by this. Imagine the fun of taking liability, as some kind of signing engineer, for a half a million lines. And those lines are almost sure to have some vulnerabilities: It's just that we don't know of them yet, and you need patching forever, just like you do today. And along with the patch, we'll have great discussions about who brought in the patch that introduced the vulnerability. Note that this is especially fun in a world where security is covered by this. It's one thing to assume that ones code to control a car will not accelerate without bounds, risking deaths to the passenger. Then your design is narrow, and can have a semblance of good testing. Testing that your code cannot be used as part of a security vulnerability is testing a far wider field of possible inputs. Either way we slice this, all I see is the world building a whole lot less software, because the dangers of writing it make all kinds of products dangerous. We either move to a world where a lot of code is shared and owned by a few companies that take all the liability, and hit major trouble whenever they have a vulnerability, because suddenly they are to blame for possibly millions of breaches, or a world where we share very little code, we evaluate it more thoroughly, and we hope nobody pays attention. I bet my libraries to handle certificates would be worse than the ones experts built today, but I could hope nobody examines them. But yes, as others say, the world could do this right now: We can hire a firm to build something and take the liability for us. It's just that, in general, we don't, because they don't give us anything more secure, or better: mostly more expensive. Instead we might just buy insurance, and hope we don't have too much of a counter-party risk. If we cut security vulnerabilities out of the equation, maybe there is a good defense that the world the author describes might be different, but not worse than the one we live in today. But with security? Tough.