At first I was sceptical, but after a few thought, I came to the solution that, if uutils can do the same stuff, is/stays actively maintained and more secure/safe (like memory bugs), this is a good change.
What are your thoughts abouth this?
My scepticism is that this should’ve been done within the coreutils project, or at least very closely affiliated. This isn’t an area of the linux technical stack that we should tolerate being made distro-specific, especially when the licensing is controlled by a single organisation that famously picks and chooses its interpretation of “FOSS” to suit its profit margins.
On a purely technical level, GNU coreutils should very seriously consider moving to rust if only to counter alternatives before it’s too late. While these utilities work well in C (and usually stay secure thanks to the Unix philosophy limiting the project scope), FOSS projects are continuing to struggle with finding new contributors as younger devs are more likely to use modern systems languages like Go and Rust. Not to mention that any project using Rust as a marketing tool will appeal to anyone rightfully concerned about hardening their system.
I personally don’t see the point.
I fear moving away from GPL that moving to Rust seems to bring, but Rust does fix real memory issues.
Take the recent rsync vulnerabilities for example.
At least this one in a Rust implementation of rsync would have very likely been avoided:
CVE-2024-12085 – A flaw was found in the rsync daemon which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time. Info Leak via uninitialized Stack contents defeats ASLR.
I fear moving away from GPL that moving to Rust seems to bring, but Rust does fix real memory issues.
So you prefer closed-source code to potentially unsafe open-source code?
Take the recent rsync vulnerabilities for example.
Already fixed, in software that’s existed for years and is used by millions. But Oh no, memory issues, let’s rewrite that in <language of the month>! will surely result in a better outcome.
the deGPLification of the Linux ecosystem ffs
I would love this news if it didn’t move away from the GPL.
Mass move to MIT is just empowering enshittification by greedy companies.
What does the license change actually mean? What are the differences?
