zlacker

>>diyftw+(OP)
Small businesses and solo-entrepreneurs have to deal with liability and permits all the time in other fields, even actual street bazaars for that matter, exception being when there is some "flexibility" between the laws and how they happen to be applied.

>>pjmlp+Cm
I’m curious what the liability and permits being discussed are here. Because the permit required to prevent some Joe Schmoe from selling me a tainted brownie off a street cart feels a little bit different and perhaps difficult to compare to software

>>SOLAR_+Jn
What’s different between a baker liable for flour content and an SDE liable for packaged library vulnerabilities?

>>zmgsab+jp
Standardized food safety practices, pre-approved and comparatively trivial recipes, state/county inspections, etc. None of which apply to software. One is fairly trivial and standardized. The other is massively complex, rapidly changing, and unable to be boiled down to a standard set of trivial procedures.

And to answer your question more directly, the flour itself causes the damage. The vulnerability is only damaging if a malicious actor takes advantage of it.

>>giantg+1q
> Standardized food safety practices

Food safety practices only became standardized after regulation was enacted.

> pre-approved and comparatively trivial recipes

That sounds like most software development.

I think you are unwittingly making the case that software development is a lot like food production. Software development is only beginning to get regulated because it is only now reaching the level where it is hazardous to public safety, unlike food production which reached that a long time ago.

>>beedee+It
"Food safety practices only became standardized after regulation was enacted."

Because you actually can standardize them. Software isn't so simple.

"> pre-approved and comparatively trivial recipes

That sounds like most software development."

Lol no that does not. Why wouldn't high school graduates or drop outs work in software instead of at fast food? The number of languages, frameworks, patterns, etc are much more complex than basic sanitation and time/temp/acidity.

>>giantg+Qy
> Because you actually can standardize them. Software isn't so simple.

It isn't simple due to choice, not due to the nature of software. Software is relatively simple compared to other meat-space engineering disciplines. Software engineering is an relatively immature engineering discipline, but it is implicated in enough safety critical systems these days that it is about time to start maturing.

It will be painful but I welcome more software regulatory standards, because it is necessary for our trade to mature.

>>kube-s+5B
It’s probable to make the case that some forms of software are simple enough to regulate. How many Supabase style crud apps have been made in our lifetimes (not shading Supabase, they’re just automating the commonalities here)

>>SOLAR_+mF
All software is simple enough to regulate. You don't have to micromanage every single line someone writes to regulate something. The way most professional regulations work is that someone writes down the safety practices that should be done, and then the law requires people to do those things.

For example, one might require some software to undergo various degrees of planning, testing, analysis, support, documentation, etc.

Right now, the amount of planning, testing, analysis, support, and documentation required by law is generally zero. This might be fine for someone's hobby project, but it is not okay for software that human lives depend on.

>>kube-s+sG
> ...for software that human lives depend on.

who decides, and how?

>>jocoda+p21
For every other technology regulated this way, this is determined at the end application.

How does someone know that a particular application is something lives depend on? Either your lawyer, insurance company, or regulator explicitly tells you.

>>kube-s+IT1
> How does someone know that a particular application is something lives depend on? Either your lawyer, insurance company, or regulator explicitly tells you.

To make an analogy to the physical world. We have a company, B, that makes bolts, they publishes the characteristics of that bolt but do not certify it for any particular use.

Company C makes cars and decides to use bolts form company B. It turns out that is not a good choice since company B bolts do not have the characteristics that are need to use in a car.

The CRA from the a simple reading used in the discussions here[1], holds company B responsible for company C using the bolts in a way where peoples lives depend on it.

This sort of reuse can be much more common in software than it is bolts for example and just like company B did not control how company C used their product after buying it open source developers do not control how others use there software but CRA might make them liable for it.

This does not make sense to me, company C should be liable for their choice of bolt, company B should be liable for any false or incorrect claims for the characteristics of their bolt. Company B should not be held liable for the misuse of their bolt by company C which is what the CRA seems to do.

[1] >>38788919