Committing to Rust for kernel code

Posted Nov 23, 2023 7:44 UTC (Thu) by Wol (subscriber, #4433)
In reply to: Committing to Rust for kernel code by Karellen
Parent article: Committing to Rust for kernel code

> The claim that "I am not free unless I have the freedom to take away other people's freedoms" is, IMHO, absurd.

Yes it is absurd. Not least because it's circular, and applies *EQUALLY* to GPL vs MIT.

GPL takes away (in considerable part) developers' freedom to make a living. Even its pre-amble says it takes away freedoms, iirc.

If we, as developers, *choose* to pass on our MIT freedoms to our customers, then everyone gets the best of both worlds. The problem is, this is a social choice, a *freedom*, and, as I keep saying, this falls squarely into nature's "pick any two" conundrum. How do you square the circle? I don't think you can ...

Cheers,
Wol

to post comments

Committing to Rust for kernel code

Posted Nov 23, 2023 8:21 UTC (Thu) by ssmith32 (subscriber, #72404) [Link] (11 responses)

What's "the freedom to make a living"?

Based on your past comments, I'm pretty sure my knee-jerk reading of that as an entitled "right to make a living" is most certainly off - that is, it's a genuine question..

Committing to Rust for kernel code

Posted Nov 23, 2023 13:14 UTC (Thu) by Wol (subscriber, #4433) [Link]

I think it's all down to the problem that freely available source code makes it hard to earn money from writing that source.

Sure, some companies (eg Red Hat) make money supporting that source.

While it's hard to put a finger on it, I just get the impression that more people make a living from OSS code that isn't Copyleft. And OSS makes it easier to sell the resulting software, even if you do "live by the spirit" and release the corresponding source.

Maybe I am a bit naive, but I believe most people agree with "live by the spirit", and if you do your best only to associate with others like that, OSS is much better than copyleft. OSS came before copyleft (in practice), and looks like outliving copyleft.

The difficulty is probably down to the fact that the software industry makes money from selling software (and the GPL interferes with this), while the world in general saves money by sharing software, and OSS helps this massively. Two completely opposing financial incentives, two completely mismatched mindsets.

Cheers,
Wol

Committing to Rust for kernel code

Posted Nov 23, 2023 13:18 UTC (Thu) by Wol (subscriber, #4433) [Link] (9 responses)

Just to add, I said the GPL takes away developer freedom. Because it quite openly seeks to ensure *end*user* freedom.

So software producers naturally favour OSS? Yep, people whos' business is software production prefer closed licences, but if software is a byproduct, OSS looks the best bet.

Cheers,
Wol

Committing to Rust for kernel code

Posted Nov 23, 2023 17:42 UTC (Thu) by ballombe (subscriber, #9523) [Link] (8 responses)

> Just to add, I said the GPL takes away developer freedom. Because it quite openly seeks to ensure *end*user* freedom.

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

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 will not go that far because release code under the MIT license is very generous but you see the point I making.

Committing to Rust for kernel code

Posted Nov 23, 2023 18:16 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

> 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.

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

Committing to Rust for kernel code

Posted Nov 23, 2023 8:27 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (6 responses)

> GPL takes away (in considerable part) developers' freedom to make a living.

Au contraire :)

MIT takes away that possibility by letting for example google or apple use that code. But gpl3 or agpl would force most companies to reimplement, and consequently hire someone to re-do the work.

The way I see it, with GPL the community is getting an advantage, with MIT some stakeholders are getting an advantage.

Developers who use GPL can also double license if they want.

What you mean is that GPL is taking away the freedom to make a living off of someone else's work without contributing anything.

Arguably also getting on a drakkar and raiding england is a way to make a living that current pesky laws have forbidden. Perhaps not all ways of making a living are equally good?

Committing to Rust for kernel code

Posted Nov 24, 2023 19:55 UTC (Fri) by Wol (subscriber, #4433) [Link] (5 responses)

> Arguably also getting on a drakkar and raiding england is a way to make a living that current pesky laws have forbidden. Perhaps not all ways of making a living are equally good?

The difference is do you want to live in a commune, or a communist state. Both are supposedly "share and share alike". But a commune is from choice, communism is imposed.

From the *givers* point of view, MIT and GPL are pretty much the same thing - you chose to give it away. From the recipient's pov, MIT gives you that same choice, that same freedom. GPL forces you to give your stuff away, under threat of lawsuit ...

(Yes, I know, only if you choose to share what others gave you, but the GPL applies coercion, MIT gives you choice)

Cheers,
Wol

Committing to Rust for kernel code

Posted Nov 25, 2023 7:32 UTC (Sat) by LtWorf (subscriber, #124958) [Link] (4 responses)

GPL is not imposed. If you use it it was because you have decided to somehow obtain the software, and you have no obligation of doing so.

You can write your own, pay someone else to do it, just not use that particular software. If you are ok with windows having an EULA, I don't see what your problem is with a much less restrictive GPL license.

> From the *givers* point of view, MIT and GPL are pretty much the same thing

From wrong axioms, a wrong proof follows. Unsurprisingly.

From the author's point of view, GPL means a much greater chance of getting improvements and contributions. See webkit, it exists because apple had to release it because KHTML was LGPL. Otherwise apple would have just never released their modifications. I do this assumption because the rest of safari was never open sourced.

So the givers of LGPL KHTML got webkit (wich wasn't that nice, because it was not a direct replacement), but it's more than with MIT.

If you are scared of the legal threat of the GPL and feel constrained by the clause that you must pass on the same freedoms, your intentions were never good to begin with; and as an author of free software I'm completely ok with ill intentioned people never using my software and interacting with me via bugreports.

(Of course in reality the ill intentioned people open bugreports to inform me of how dumb/evil I am for not letting them use my work to take freedom away from others… So I wrote a code of conduct that forbids this behaviour and I can at least instantly ban them).

> (Yes, I know, only if you choose to share what others gave you, but the GPL applies coercion, MIT gives you choice)

And seeing how the former CEO of github was pushing for MIT license (https://www.youtube.com/watch?v=-bAAlPXB2-c), microsoft continuing on the same path, apple avoiding GPL3, google completely forbidding AGPL… it seems that humanity isn't enlightened enough yet to not need the coercion.

Committing to Rust for kernel code

Posted Nov 25, 2023 11:39 UTC (Sat) by Wol (subscriber, #4433) [Link] (3 responses)

> > From the *givers* point of view, MIT and GPL are pretty much the same thing

> From wrong axioms, a wrong proof follows. Unsurprisingly.

Where's the difference? If it's GPL, commercially minded people won't use it, and you don't get anything back.

If it's MIT, commercially minded people don't contribute back. (According to you, at least ...)

The mindset that says "pay forward, pay back", will contribute regardless of licence.

As I say, what's the difference?

And if the GPL has no teeth (because, like in my case, it's simply an inappropriate licence), again what's the difference?

Cheers,
Wol

Committing to Rust for kernel code

Posted Nov 25, 2023 13:19 UTC (Sat) by LtWorf (subscriber, #124958) [Link] (2 responses)

> Where's the difference? If it's GPL, commercially minded people won't use it, and you don't get anything back.

Wrong premise again? Since Safari and Android do in fact exist, it's rather easy to show that you are incorrect.

I will stop this here because there can be no agreement if we can't even acknowledge real facts.

Committing to Rust for kernel code

Posted Nov 25, 2023 17:36 UTC (Sat) by Wol (subscriber, #4433) [Link] (1 responses)

> > Where's the difference? If it's GPL, commercially minded people won't use it, and you don't get anything back.

> Wrong premise again? Since Safari and Android do in fact exist, it's rather easy to show that you are incorrect.

Yep, they exist. However, I can't speak for Safari/Apple because I have nothing to do with that ecosystem, but don't Apple refuse to have anything whatsoever to do with GPL3? And as for Android, doesn't Google have a ban on GPL user-space? Safari and Android look extremely like exceptions to me ...

> I will stop this here because there can be no agreement if we can't even acknowledge real facts.

To misquote PJ, when dealing with real life, facts are squishy. Heck, even with your two examples, the companies involved are openly hostile to the GPL - they don't have anything to do with it if they can help it .. (Unless, in Google's case, I suspect they're quite happy to dump abandoned projects as GPL ...)

Cheers,
Wol

Committing to Rust for kernel code

Posted Nov 29, 2023 12:30 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

> don't Apple refuse to have anything whatsoever to do with GPL3

Apple is not the whole world

In fact a *huge* number of companies (both on the producer and user side) have been using (AL)GPL for years and are starting to realise the “communist hell” FUD is just FUD. And they’re complaining Red Hat is not free enough.

The loudest free software promoters for years have not been @FSF but VC players that try to use dual licensing tricks and other open-source-enabled antifeatures to force their customers to do things they have no interest in.