I dunno, I'm pretty big on FOSS but I don't think you would need that to improve. Requiring that the firmware have its source code available to audit doesn't mean that users can replace it. AFAIK you could, today, with no legal changes, have a vendor release 100% of the code under eg. a MIT license while also making the device refuse to run firmware not signed with their keys. Researchers could poke at it to find bugs, and FCC regulations wouldn't be touched. (Note: IANAL, so feel free to point out if I'm wrong about that)

(To be clear, I don't think that's good enough; at a minimum I think there should be a wifi card that does refuse modifications and a main application processor that is 100% user controlled so that they can actually fix problems without needing the vendor to help, but I think it's useful to point out that auditing code doesn't require being able to install it)

▲

kogepathic 5 hours ago | parent [-]

> AFAIK you could, today, with no legal changes, have a vendor release 100% of the code under eg. a MIT license while also making the device refuse to run firmware not signed with their keys.

This is already the case today with many embedded devices. They have secure boot enabled so even if the vendor releases the GPL source code (big if), you can't do anything because the device will only boot the vendor's signed firmware.

> at a minimum I think there should be a wifi card that does refuse modifications and a main application processor that is 100% user controlled so that they can actually fix problems without needing the vendor to help

This is already possible. The RF components frequently have a signed firmware blob that is verified on load. There is no reason but planned obsolescence and greed keeping the application processor locked to running the vendor's signed code.

▲

pabs3 3 hours ago | parent [-]

> the device will only boot the vendor's signed firmware

That sounds like what Software Freedom Conservancy would call a GPL violation:

https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...

	▲	kogepathic 3 hours ago \| parent [-]
		> That sounds like what Software Freedom Conservancy would call a GPL violation Sure, it is. So what? Have you got 200k for lawyers and years of your life to spend in court fighting over it? I have personally contacted the SFC with ample evidence of deliberate and wilful GPL violations, such as providing a written offer for source code and then ignoring or flat out refusing requests for the source code. The SFC has acknowledged the vendors are violating the spirit and letter of the GPL. Nothing happens. The SFC is one organisation with limited resources, FOSS developers don't want to spend their time in court, they'd rather develop software. Vendors know 9 times out of 10 they will get away with the GPL violation scot-free. It's fine to put on your rose colored glasses and pretend GPL forces companies to release source code. Reality is, the vendors have a larger marketing budget than the entire SFC endowment and the vendor's legal team is happy to tar-pit requests ad infinitum.