I think the real answer is: time, place, design set. In another time and place, we'd might be using LEON/SPARC. We don't get to choose our time, though.
In particular, LEON is just about the only SPARC implementation I'm aware of whenever it's brought up, while RISC-V already has at least 3-or-4 implementations that have gone to fabrication in the past few years. It has toolchain support and stuff, at least. Oracle being the steward of the latest 10yrs of SPARC design probably has not helped, though, especially wrt IP concerns. LEON is still 32-bit only apparently from a quick search?
OR1k has realistically never really had support in almost anything, it seems, other than some binutils/Linux forks and an implementation or two. But it also differs architecturally: delay slots, no 2008 IEEE754, no 64-bit address space OR1k availability at the time of beginning. (Does modern SPARC still have delay slots? That's also a major core change, still.) So if you're going to fix those things, you might as well just start from scratch really, it seems.
I've literally never even heard of LM32, despite owning a Lattice FPGA on my desk and it having GCC support, apparently. It's a Harvard design though, and there is no 64-bit support in the chip, so those are two major things that would have to be fixed, and you're still on the hook for e.g. fixing the toolchain for this. So, it's still not free. Also while the core is free, does it really have no IP claims by Lattice?
Ultimately RISC-V just had the right support, at the right time (the last ~5 years), and has the right set of features that make it a lot more appealing architecturally. It has an open toolchain that will be (finally!) going upstream in major open source compilers (e.g. no official OR1k/LM32 support in LLVM, LM32 in GCC though), multiple implementations that are size-optimized (picorv32) and speed-optimized (Rocket) and can be openly synthesized/developed, 32/64bit support, needed things like modern upcoming SIMD ISA designs, multiple large and small supporters, compatible chips are beginning to roll out, etc. The ISA design IMO (the chained encoding) makes the instruction set fairly simple and straightforward to write tools for. If you look at all of these efforts, RISC-V is simply a juggernaut in comparison to any other.
I do think there is hope out there for more open cores to thrive e.g. due to licensing concerns and cost margins, esp in the embedded space. RISC-V does not have to be the "only" alternative or winner. It's just a very good alternative that has a very "wide reaching" design, with modern niceties (64-bit, SIMD, etc).
If I had to pick anything else, I'd probably pick the J-core revival of the SuperH CPU. It's somewhat dated, but the patents/IP have all expired, it's a very dense encoding, a proven architecture (20+ years!), has existing toolchain support (upstream Linux/GCC ports), and in theory can be taped out etc. I've been writing some RISC-V code lately and I'd be interested to see the density vs SuperH -- that matters for stuff like writing a Forth. :)
Ah, good catch. I believe the remainder of the SH4 patents expire this year, but the SH2 patents are all in the clear. And the 64-bit J-core will be using a different design than the SH5, so those aren't relevant. I wonder exactly what said patents cover aside from things like encoding etc...
In particular, LEON is just about the only SPARC implementation I'm aware of whenever it's brought up, while RISC-V already has at least 3-or-4 implementations that have gone to fabrication in the past few years. It has toolchain support and stuff, at least. Oracle being the steward of the latest 10yrs of SPARC design probably has not helped, though, especially wrt IP concerns. LEON is still 32-bit only apparently from a quick search?
OR1k has realistically never really had support in almost anything, it seems, other than some binutils/Linux forks and an implementation or two. But it also differs architecturally: delay slots, no 2008 IEEE754, no 64-bit address space OR1k availability at the time of beginning. (Does modern SPARC still have delay slots? That's also a major core change, still.) So if you're going to fix those things, you might as well just start from scratch really, it seems.
I've literally never even heard of LM32, despite owning a Lattice FPGA on my desk and it having GCC support, apparently. It's a Harvard design though, and there is no 64-bit support in the chip, so those are two major things that would have to be fixed, and you're still on the hook for e.g. fixing the toolchain for this. So, it's still not free. Also while the core is free, does it really have no IP claims by Lattice?
Ultimately RISC-V just had the right support, at the right time (the last ~5 years), and has the right set of features that make it a lot more appealing architecturally. It has an open toolchain that will be (finally!) going upstream in major open source compilers (e.g. no official OR1k/LM32 support in LLVM, LM32 in GCC though), multiple implementations that are size-optimized (picorv32) and speed-optimized (Rocket) and can be openly synthesized/developed, 32/64bit support, needed things like modern upcoming SIMD ISA designs, multiple large and small supporters, compatible chips are beginning to roll out, etc. The ISA design IMO (the chained encoding) makes the instruction set fairly simple and straightforward to write tools for. If you look at all of these efforts, RISC-V is simply a juggernaut in comparison to any other.
I do think there is hope out there for more open cores to thrive e.g. due to licensing concerns and cost margins, esp in the embedded space. RISC-V does not have to be the "only" alternative or winner. It's just a very good alternative that has a very "wide reaching" design, with modern niceties (64-bit, SIMD, etc).
If I had to pick anything else, I'd probably pick the J-core revival of the SuperH CPU. It's somewhat dated, but the patents/IP have all expired, it's a very dense encoding, a proven architecture (20+ years!), has existing toolchain support (upstream Linux/GCC ports), and in theory can be taped out etc. I've been writing some RISC-V code lately and I'd be interested to see the density vs SuperH -- that matters for stuff like writing a Forth. :)