This seems like a good thing? Making software makers have liability for a shifty product should have happened a long time ago.
Could high risk be the ability to monitor heart rate, or control motors? Could it be example code for those abilities that make them liable?
If RaspberryPi or Alphabet releases an educational board for experimenters but has features that could be used in a way that is considered high risk and if they are considered market powers, should they keep it from interested people because they can't fully disclaim liability?
How much should they reduce their feature set so that it doesn't tangentially run into this law. Can they just disable that part of the code, or would they run into the same problem as the GTA Hot Coffee case if it isn't gutted enough.
While it has good intentions, it will likely backfire some way as the lists of prohibited things grow or the market power clauses are reinterpreted to be applied to a wider range and smaller targets.
Windows, back in the day, was both buggy and full of security holes. It was also $99, and enabled an inexpensive computer to do near-workstation feats. If it cost, say, three times as much, that would have changed the market dynamic quite a bit. Fewer of us would have been able to afford computers with Windows, and few of us wanted bare-metal computers.
Well, you say, that's just fine, we could have put Linux on it, and the world would have been a better place. Well, could you have put Linux on it? Can Linux survive in this regulatory environment? Can it survive as open as it is, as modifiable as it is, as free as it is? What about the rest of free software, that doesn't necessarily have a large company behind it?
The second-order effects of this could completely change the software landscape. We may not like the results.
Given that everything's getting either a WiFi or bluetooth chip in it, could we see coffee makers that are not approved for use in a commercial, health-care, industrial, or business setting?
You just can't certify your way to resilient software.
People are smart, they would have figured out really solid mechanisms that gave you great software that’s actually safe. Look at any of the fields that deserve to use the word engineering for examples.
The "private sector" here will be FAANG and other huge tech cos. They will argue for massive liability. Congress will agree because it makes them look tough and decisive. They know that only they can afford such liability. Smaller companies will be crushed by the liability insurance they need to cover these requirements.
It's interesting that they use both the phrases "manufacturers" and "software publishers".
Obviously Microsoft, Oracle, etc are both manufacturers and software publishers but what about that random open source project? At minimum, they're "software publishers".
The "with market power" clause might seem like a protection but it's trivially easy to see many major open source packages with huge market share as having "market power". In that case, it's less about revenue and more about adoption and interop.
Frankly, this is the nightmare scenario that I thought Microsoft, et al would use to kill Open Source ~20 years ago. If the Feds demand liability, that kills OSS both from a “no company” standpoint and from a licensing “as is” standpoint.
Even if they don't outright BAN it, they could just make it painful to get approved, which is nearly the same result but lets everyone keep their hands clean.
Concrete example: I wrote a cryptographic library, which I give away for free. No guarantee, no liability, if I make a mistake the only thing you can take away is my reputation. But what if you want to use my library, and don’t want to be liable for it? There are two alternatives: you can approach me and pay me for me to accept liability… or you can approach a reputable audit company, and have them accept liability for a given version.
Legislate like that, and I’ll still be able to contribute potentially critical code for free.
And yes it is a risk. And yes I had one critical bug in 6 years, the horror. I did it anyway because it was pushing the Pareto envelope (speed/size mostly). And of course I knew what I was getting into, which is why it is not a weekend project, but a professional grade library. More explanations on my choices here: https://monocypher.org/why/
And by the way, Monocypher is currently being used to operate the TKey from Tillitis. https://tillitis.se/products/tkey/ Good luck porting libsodium there.
---
You do have a point however: actively distributed critical software with no one being liable is an anti-pattern. Though strictly speaking, my code is only critical when it starts being used, so… we’re going back to the place of amateur work: if you want to use my code, you can pay me to get a license that does not waive my liability, or you can pay someone else to audit my library, or you can be liable yourself. And if I sell my code, I should indeed be automatically liable.
The point with my example is that with proper legislation, even cryptographic libraries can continue being open source.
“Professional grade library” is an interesting choice of words in a thread about how we need to have liability for software, especially for software that is today in use exclusively licensed under no-liability licensing. If anything, all of the words on your site make it worse. A reasonable person, upon reading those fancy words, would be lead to the conclusion that this is Serious Software and thus safe to use.
Are you liable under the license they’re using? Their site has a lot of “trust me bro” security words on it, which is a great illustration of my point. You wrote it, you chose of your own free will to make it available, you’re responsible if it gets people hurt.
> The people who wrote OpenSSL thought they knew what they were doing.
The people who wrote OpenSSL had a much harder job, and my epistemic position is a lot better: I have over 20 years worth of additional collective wisdom to draw from, the primitives I implement are much* easier to deal with, and the problem I set out to solve is at least one order of magnitude easier.
> Are you liable under the license they’re using?
I’m not. And to be honest I’m on the fence on whether I should be. Nobody paid me for this work after all. On the other hand, if a law made me liable I wouldn’t complain too much to be honest.
If it’s regulation more than liability, I already followed most, if not all, the procedures outlined in the upcoming EU law on software resilience. I should have little problem going all the way to full compliance there (except perhaps if they ask for third party audits, I’m not paying 6.000€ per release).
> you’re responsible if it gets people hurt.
Believe me, I know. Thankfully so far nobody reported being hurt in any way — even from the sevcrit. And I continue making sure it stays that way.
---
By the way, I’m planning to work on an FPGA RISC-V core soon. I’m pretty sure nobody will give me any flak for this. And yet when you look at it, this is even more critical than a cryptographic library.
You seem to have totally missed the point of this thread. That’s not the best you can do, it’s merely the best you’re willing to do. You’re so convinced that the internet should trust your code? Put that into the license. You have the directionality wrong; nobody asked you to release dangerous code while disclaiming all liability. You decided to do that.
OpenSSL or log4j would like a word about how shallow bugs are in popular software.