yeah they'd need to innovate to mitigate their risk.

example: you are a car manufacturer. you have a legal responsibility for the street safety of your car, a responsibility for the functional safety of your product.

now a car crashes, badly, killing people, and blame is put onto the internal software of some on board "electronic control unit", ecu.

how can you ensure the software was not tampered with?

lock it down, secure boot?

then you can't have any gpl3 component on there.

so to allow for personal software modifications you'd need to innovate some mechanism which reliably flags unsigned software changes to the ecu. they need to be reliable enough that even after a crash you can still check if the ecu was running vendor software or some modified version. just like you can check if the brakes or the steering was intact or tampered with.

such legal liability is at the heart of rejecting gpl3 for many devices.

ps: for infotainment it's not about human life but about profit, content tax, a different story.

It's perfectly okay for you to put GPLv3 software in ROM that nobody can ever modify and then sell me the hardware. What's not okay is selling me hardware where you can modify the software after the fact, but I can't. And it's also okay for your hardware to detect if I modified the software. It just can't refuse to work if I did.

And this is where the FSF makes the weird trade off that they prefer to not have security updates as that's more "free" than being able to get security updates from the manufacturer. Either way you can't update it, but at least in the scenario the FSF opposes the users are able to be more secure.

True. FSF doesn't support taking the freedom away from users in the name of security.

> at least in the scenario the FSF opposes the users are able to be more secure

That's quite questionable. What if someone steals the manufacturer keys? Then people with unmodifyable devices would be more secure.

But anyway that's besides the point since FSF is against taking the freedom away from the users under the veil of "security" anyway.

this has nothing to do with security updates. any vendor is free to ship security updates however vendors often decide to refuse updates to "tainted" devices.

That's not what the FSF meant the exception to be used for. That's basically the manufacturers abusing a loophole.

that scenario doesn't exist, non-flashable rom.

only. the other scenario, "vendor can update I can't" is relevant.

and that detection mechanism is called "secure boot".

> that scenario doesn't exist, non-flashable rom.

Of course they do. One example is pressed DVDs.

You absolutely can put GPLv3 on there, check out this presentation:

https://events19.linuxfoundation.org/wp-content/uploads/2017...

...and put your device in "dev board mode", which loses all homologation and puts the vehicle into safe space.

and as per the slide deck this may be a one way operation, creating a brick in the driveway.

I know the slide deck. I've asked automotive oems to think about a dev mode which does drive, but puts the whole car into a dev mode and makes this obvious. too expensive. just kick out gpl3 from anything relevant to homologation.

It means they have to make any locked-down devices they sell not-locked-down due to the anti-tivoization part of the GPLv3

GPLv3 also has extra patent clauses

GPLv2 also as those provisions:

https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t...

In addition, even the GPLv3 allows what Tivo did (break proprietary software when GPL software is updated:

https://events19.linuxfoundation.org/wp-content/uploads/2017...