[moody__]

This article paints copyleft software as something fairly disjoint from corporate software, however in my experience these are not mutually exclusive. If you look at the kernel's howto for new development[0], it seems fairly focused on the reality that a majority of people walking in to the linux project are doing so on the payroll of some company. For some guy in his 20s who is a bit late to the party, and not being helped out by some corporate arm, the Linux kernel feels like this completely unapproachable monster. In other words, without knowing someone ahead of time it seems impossible to be active in the community. The source is available sure, but that doesn't mean the code isn't corporate.

Copyleft licenses often need a lawyer in the room to figure out what can and can not be done, they are complicated legal documents. My preference for MIT is to allow software to spread in a way unencumbered by the access to a license lawyer.

[0] https://www.kernel.org/doc/html/v4.16/process/howto.html

[karmakaze]

An MIT license requires no propagation of software changes. I would say that a Copyleft licenses enforce software to be out-in-world. The lawyers needed to find out how not to propagate changes.

This reverse duality depends on whether the 'software' propagated is that which uses licensed software or evolution in public of the licensed software itself. If Linux itself was MIT licensed we would have a much messier world of fragmented, semi-working, partially compatible, proprietary platforms.

[moody__]

We already live in the world of fragmented, semi-working, partially compatible platforms. The openness did not make this better. Take one look at what is going on in the risc-v world with nearly every soc having its own fork of the linux kernel, hacked up for specifically their board. ARM has the same issue to a lesser extent. You want to try bcachefs on your ARM NAS board? good luck.

[karmakaze]

Compared to what though? Every SoC having its own entire OS implementation derived from some closed source origin that way back when started from some MIT licensed base. It probably wouldn't even have a bcachefs to every try on it.

[moody__]

Apologies I typed soc but really I was trying to talk about sbc's. The type of little boards you find running linux. As far as I know there is not currently (or at least as of a few years ago) risc-v sbc you could get that boots off of nothing but mainline.

[snvzz]

>Take one look at what is going on in the risc-v world with nearly every soc having its own fork of the linux kernel

There aren't that many RISC-V Linux-capable SoCs out there, and the ones I know all can boot a generic Linux (relying on SBI for e.g. timers or console i/o), and have ongoing efforts for upstreaming drivers.

It's a much more serious problem on ARM, which does not have anywhere as much platform nor boot standarization.

[moody__]

I was not aware of a risc-v board that could boot with nothing but mainline, could you link me to one that doesn't require any third party code to use?

[snvzz]

Anything based on JH7110, of which VisionFive 2 is most mature.

As well as anything else in opensbi upstream.

[moody__]

Thanks, I'll give that a look.