RISCV is an open architecture. If a manufacturer does that, simply don't buy the processor from that manufacturer and buy it from another. All your software will still be compatible since it's the same architecture.
Otherwise with x86 is more complex: you can choose between Intel and AMD (that has bought the license for the x86 instruction set - not something cheap to get), and both of them had their backdoor processor inside the computer (at least on Intel there are ways to disable it, as far as I know with AMD is more difficult if not impossible to do).
Assuming that the software is all available from source and can be recompiled.
Only the base RISC V is guaranteed thanks extensions.
Also you are forgetting that just like Android and ARM, there are other forces at play that don't make it as easy in practice as FOSS advocates wish for.
> Assuming that the software is all available from source and can be recompiled.
I remembered hearing that same line when I bought a Raspberry Pi in 2012. "It's useless! You can't run x86 software on it, so what's the point?"
Flash-forwards a decade and now Graviton instances are blowing up like nothing else in the industry. RISC-V is in a very similar position to ARM 10 years ago; the groundwork has been laid, standards have been ratified and base packages/several kernels work perfectly fine on it. The only difference is that ARM is more expensive to license and is less flexible.
> Only the base RISC V is guaranteed thanks extensions.
Yeah. Is that a problem? The situation on ARM is equally bad if not worse (frequent iterations end up throwing even relatively recent CPU models under the bus), and the reason why RISC-V divided itself into extensions is so that you didn't have to start from scratch when John RISC decides to add in 3 new floating point instructions. It's a pretty damn good compromise if you ask me, and it certainly doesn't have any bearing on software availability; RISC-V programs run on RISC-V processors. ARM does not have that same liberty.
There are plenty of genuine constraints for RISC-V (the majority of them in the manufacturing/mass production side of things, now), but the majority of these software issues have been solved and taped out years ago.
With emulation one can always run one archicture in another one, there is nothing scientific about it, provided there is enough knowledge about the source architecture.
I'm a little baffled how "licenses" for instruction sets became a thing. Old CPUs, anyone could clone them or write emulators for them. There's nothing particularly novel about an instruction set encoding, even if you have defined thousands of instructions, and the idea that they're worthy of patent protection (or whatever) is absurd.
Otherwise with x86 is more complex: you can choose between Intel and AMD (that has bought the license for the x86 instruction set - not something cheap to get), and both of them had their backdoor processor inside the computer (at least on Intel there are ways to disable it, as far as I know with AMD is more difficult if not impossible to do).