The better alternative would to be to completely rework the software developing discipline to be as rigorous as civil engineering from the top down. Requiring proper licensing, and security clearances for accessing U.S. customer data.
The better alternative would to be to completely rework the software developing discipline to be as rigorous as civil engineering from the top down. Requiring proper licensing, and security clearances for accessing U.S. customer data.
Edit: I suspect any reasonable law would account for that, and these are the folks who do the Lawfare podcast, right? It is pretty good. I haven’t finished the paper yet but I’d be surprised if they missed this.
That said, there's a state of tension on this topic right now. The European Union's draft Cyber Resilience Act has included language across multiple versions that would in at least some cases assign liability to producers of open source software. They've tried to modify the language to exclude non-commercial open source projects, but there's been a lot of wrangling over the exact definition of "commercial."
I’m quite glad they aren’t ignoring the complexity.
That's disturbing since the definition should be trivial!
If I publish a library (whether open source or not, doesn't really matter) and charge you money to use it in your product, that's commercial. I'm happy to take the liability (and will of course charge you enough money to make it worth it to me).
If I throw out some code on github but you're not paying me, that's obviously not commercial.
It used to be this way (at least in the companies I was involved in back then). In the 90s there was plenty of open source but it was generally a huge no-no to use it in commercial software (even when the license was permissible).
Incorporating an open source library (just one!) to our product in the 90s meant months and months of meeting with company lawyers to get that approved. And it meant we (the team developing the product) were 100% on the hook for all fixes.
While I'll admit it was a pain, in hindsight there was a lot of benefit from that approach. It discouraged importing random libraries unless there was a lot of value in them, so we had to be selective. It made it crystal clear that open source is not free, there's a lot of cost and liability.
While it's convenient today to import a library that brings in 700 other libraries, none of them vetted, any one of which might be full of malware, maybe that's actually not so smart.
I increasingly feel we need to go back to explicitly admitting that we (the company) are 100% responsible and liable for the code we ship. If we import it from open source, no matter, we're still on the hook.
Yep, and they had a podcast episode with the author of this paper: https://www.lawfaremedia.org/article/the-lawfare-podcast-jim...
My POV it's better than pretending certain segments of the economy are special and can completely avoid all liability.
People really hate the idea of slip and fall cases until their grandmother slips and falls.
> The better alternative would to be to completely rework the software developing discipline to be as rigorous as civil engineering from the top down. Requiring proper licensing, and security clearances for accessing U.S. customer data.
Yeah, maybe. It's kind of incredible this kind of seat of the pants engineering has lasted as long as it has.
Which is why it is a lawyers dream unless it is completely reworked.
I'm really not sure this is case. I'm sure there are plenty of people who would have argued medical practice is more of an art, than a science, before the introduction of strong med mal regimes. Everyone tends to think their field is special!
If we go down this path then we need proper licensing, certifications, and changes should be as well tested as the fda process. Aka releasing software is as rigorous as releasing a new drug.