I worked at a place that had a formally verified application running on some mainframe. It was wonderful, except that the process was excruciating and maintaining that validation prevented any changes. Every code change cost a minimum of $25,000 2002 dollars.
It was dumb. They would have been better off with a paper process and army of clerks.
As for the rest of the open source ecosystem that goes into Linux (the operating system), it would probably be abandoned.
NotPetya which took down Maersk and did $300Mn of damages was apparently spread (through their Windows AD) by compromised admin accounts which they were lax at managing[1] rather than kernel exploits. The SolarWinds Orion security flaws were blamed on weak passwords, not OS kernel exploits. And if getting inside, something like last month's SystemD/polkit exploit[2] shows that attacking the kernel isn't always necessary for privilege escalation.
Linux the kernel is important but it's the heart inside the ribcage, not the first or last line of defense, or the main thing to target.
[1] https://gvnshtn.com/maersk-me-notpetya/
[2] https://github.blog/2021-06-10-privilege-escalation-polkit-r...
I imagine it would depend heavily on how large the liability was. I expect individual components would begin being replaced with "certified" commercial alternatives. If not existing ones, definitely new ones. Remember that they make money by selling to customers who would also be subject to the same rules. Look at healthcare, aviation, and finance for concrete examples of the effects (both negative and positive) that red tape has on software and IT policies.
There's an entire FOSS ecosystem and the vast majority of it is composed of small-ish slow moving projects. The tech industry is also an entire ecosystem full of small and medium sized players. Even if behemoths such as mainline Linux and AWS somehow survived unchanged I would expect a much greater chilling effect on smaller players that couldn't afford to take on such risks. New companies and software projects would become very difficult to get off the ground (healthcare is a good example here). With few to no new entrants forward progress would slow to an absolute crawl.
All of this has downstream effects. Fewer consumer devices running Linux would mean even less hardware support. Security related liabilities would almost certainly mean more vendor locked hardware. Would companies like Purism remain viable (or even legal)? The steady stream of new FOSS users and contributors would almost certainly dwindle.
Depending on how such regulation was written, could open source contributors themselves become liable for a freely provided product?
That assumption is deeply flawed. We do not hold toy car manufacturers to the same standards as actual car manufacturers. We do not hold every manufacturer of screws to the same standards as the manufacturers of screws on airplanes. Or rather, we do hold them to the same standards, just we know that certain use cases basically can not cause too much harm in the event of failure and thus in practice the standards needed to mitigate the worst case are much lower.
Software liability does not mean that everybody suddenly needs to take the same care as safety-critical industries. It only means that if you are making safety-critical software and you are incapable of separating the safety of the critical components from the non-critical components. What it really means is the repudiation of the one-size-fits-all lowest common denominator expectation of quality.