Committing to Rust for kernel code

Posted Nov 23, 2023 18:16 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: Committing to Rust for kernel code by ballombe
Parent article: Committing to Rust for kernel code

> Every developer is using far more code than what they contributed, so globally, the GPL is still a win for them.

Why? It's vice-versa. MIT is more advantageous for individual developers.

> Yes, you can say it is the "prisoner dilemma" all over and again and use MIT license to get an edge, but the "prisoner dilemma" terminology calls it "being selfish".

I think you might be confusing the "selfish" vs "selfless" choices here. GPL is the "selfish" choice, while MIT is a "selfless" choice that results in a better outcome if everyone cooperates.

to post comments

Committing to Rust for kernel code

Posted Nov 23, 2023 19:41 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (6 responses)

> MIT is more advantageous for individual developers.

Only if they are not interested in using any of Linux, GCC, glibc, GMP, GNOME, KDE, git, etc., free equivalents of which might or might not exist in a world without copyleft.

Committing to Rust for kernel code

Posted Nov 24, 2023 3:59 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> free equivalents of which might or might not exist in a world without copyleft.

FreeBSD exists, LLVM exists, musl libc exists as well.

Also, it doesn't really change the fact that MIT is a more flexible license. By choosing it, developers prioritize the long-term well-being of the project, rather than a momentary gain (from people forced to open proprietary contributions).

Committing to Rust for kernel code

Posted Nov 24, 2023 9:17 UTC (Fri) by Wol (subscriber, #4433) [Link] (4 responses)

> glibc, GMP, GNOME, KDE, git

Linux didn't use glibc for a long time.

Dunno about GMP, but Gnome and KDE relied on X which was BSD. Didn't we have Lesstif? And git was written by Linus, who is famously a pragmatist and doesn't really agree with the GPL. He used it because it was available, and did what he wanted.

So I think pretty much EVERY one of your examples could easily exist in a world where the BSD lawsuit didn't happen, and Linux was never born.

What other differences such a world would involve I don't know.

Oh - and again as I keep repeating, in many cases there is NO REAL DIFFERENCE between GPL and MIT/BSD. What's the difference if you apply them to interpreted scripts? Zilch. What's the difference if you apply them to a p-code system like Pick/MV that has no concept of linking? Zilch.

That's why my licence of choice would probably be LGPL / MPL. The GPL brings nothing at all to the table, and the other two "actively encourage" share-and-share-alike. Plus, I work for an end-user (almost always have), so I don't feel the "make a living from software" pressure, despite being a 100% through and through developer.

Cheers,
Wol

Committing to Rust for kernel code

Posted Nov 27, 2023 18:00 UTC (Mon) by smoogen (subscriber, #97) [Link] (3 responses)

>> glibc, GMP, GNOME, KDE, git

> Linux didn't use glibc for a long time.

I am probably confused by what you meant here.. From a distribution point of view:

1. That 'long time' over the length of Linux operating systems is now very short. Most operating systems had switched to upstream glibc by 6-7 years out of the first distributions.. so out of 20 year lifetime, about 1/3 of the time?

2. The libraries shipped on many of the early distributions were either glibc derived OR were GPL2 based. I think there were a couple of BSD based ones but I don't remember who shipped them.

That said, the licensing of the new kernel code would be up to the writers of the code and would be limited to BSD or MIT to be GPLv2 compatible. [The Linux kernel has BSD and MIT code in it.]

The one thing I have seen with GPLv2 kernel code versus BSD code has been that short term effects BSD code can make money but it also tends to have a short 'shelf-life'. Updates to parts get stuck away inside various companies and you end up with multiple people solving the same problem over and over again. The kernel code tends to be seen and shared around a lot more.. and fixes come in from various places. BSD maintainers I have known usually grouse about how hard it is to get fixes for their stuff. They know in talking with programmer Y that XYZ company knows the bug, fixed the bug, and has code.. but because the code could also be used elsewhere, etc.. it would need so many legal checkmarks to get it out no one is going to do it. [The same does happen with GPLv2 code.. but it seems that there is more of a 'we can't use this elsewhere since its already GPLv2 so meh share it.']

However I know that is also just my experiences and world view clouding my view.

Committing to Rust for kernel code

Posted Nov 28, 2023 10:26 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

Speaking of pre-libc.... there seems to be nearly 0 information available on the Internet - at least, easily found via the indexes of my favourite search engines of the early (pre GNU libc) Linux libc.

What was its origin and history again?

Committing to Rust for kernel code

Posted Nov 28, 2023 11:06 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

Self answer, best source seems to be the Linux "libc" man page: https://man7.org/linux/man-pages/man7/libc.7.html - linux libc was a GNU libc 1.x fork.

Committing to Rust for kernel code

Posted Nov 28, 2023 11:51 UTC (Tue) by Wol (subscriber, #4433) [Link]

You could always search for libc5 - the last linux libc. glibc2 became "libc6".

I've got some old software I would like to try and get running again (Y2K era) that needs libc5.

Cheers,
Wol