Oboi here we go 🙄
Ubuntu has managed to do away with GNU Core Utilities in its default stack. The last three holdouts, cp, mv and rm, have moved to uutils’ coreutils; the Rust reimplementation Canonical has been feeding into the distro since 2025.
They had been held back from 26.04 LTS over flaws in the uutils versions. Everything else, from ls and cat to chmod and du, made that jump in earlier releases.
This change, while big, sits hidden away in an obscure mention in Canonical’s work-in-progress release notes for Ubuntu 26.10.
It’s been a long road
Canonical started oxidising Ubuntu last year, and Ubuntu 25.10 became the first release to ship coreutils as the default. That release also made sudo-rs the default privilege tool, replacing a command that had been in place for decades.
26.04 was the release where the plan did slow down quite a bit, as Canonical kept cp, mv, and rm on their GNU versions due to a bunch of TOCTOU issues that were blocking the full implementation.
These were caught during an audit, when Canonical commissioned Zellic for two rounds between December 2025 and March 2026, focusing on the most security-sensitive utilities first.
Across both rounds, Zellic raised 113 issues, and 44 of them were assigned CVEs. Canonical says the vast majority have been resolved.
Getting here has had its ups and downs, and the last stretch was not clean. In July, uutils cp went back into the archive and came straight out again after it broke live image builds.
The fix was quick; as the developers marked it “Critical,” the fix went upstream, and the migration landed in time for 26.10. What changes for you?
When typing commands, nothing changes for you on the surface. uutils coreutils is designed to be a drop-in replacement for essential GNU tools, and the project treats any divergence from GNU as a bug, further pointing out that some options may still be missing or behave differently.
So if you prefer staying on the GNU version, you have the option to install the coreutils-from-gnu package that houses all the required components.
The next stage
Coreutils is one piece of a broader campaign. Earlier this year, Canonical became a Gold Sponsor of the Trifecta Tech Foundation, pitching in €40,000 a year to fund memory-safe system software.
Under this, their current target is ntpd-rs, a Rust rewrite of the tools Ubuntu uses to keep its clock in sync. While work is still ongoing, it has already arrived for testing.
Its transition to being default is targeted for Ubuntu 27.04.
What Canonical is gradually building up towards is the completion of their oxidation vision for Ubuntu, and it’s not about blindly including new components. Rather, it looks like a measured approach that’s being worked out a few steps at a time.
How is this license laundering? These are complete new implementations and the original projects are not touched.
Because Canonicals real goal is to move Ubuntu entirely to corporate friendly licensing under the pretense of migrating to rust. Obviously they leave the original untouched, it’s a matter of adoption. Without the oxidization argument nobody would have gone along with Ubuntu just deciding to do a clean room implementation of gnu tools in corporate friendly licensing, by making it about oxidation they are able to manipulate a large portion of the rust community into contributing/supporting their license laundering.
If you are right, they started from the wrong place. I am pretty sure that in a corporate environment there are thing more important to be “corporate friendly” than the coreutils.
It’s not even Ubuntu doing the new implementation. And no, having a new project that is compatible to an existing one does not make it a license laundering. The word “license laundering” doesn’t even make sense.
Uh call it whatever you want but canonical pouring money and resources into development of corporate friendly licensed clones to existing tools so they can avoid copyleft restrictions in the future is not good. I never understand when people feel the need to defend corporations obviously harmful behavior.
This is not about defending corporations. It doesn’t matter who does that, I don’t think writing new tools with a different license is bad. My opinion has nothing to do about who does that, if communities, or corporations. I think having tools in a different language than C, especially something like Rust, is a good thing. Anyone who writes Rust code can read, adapt and make changes to it.
And for licensing, GPL can be problematic in some cases that is not compatible with every license. Therefore having an alternative in MIT license is a good thing. Even if it ends up being in a proprietary program, its still better than not able to use the code. The old GPL code is still maintained independently.
Lol. Anyone who writes C code can read, adapt and make changes to it
Anyone who writes Python code can read, adapt and make changes to it
Anyone who writes Ada code can read, adapt and make changes to it
What kind of argument is that?
I thought its obvious what I meant, based on the context of my entire reply. The argument is, anyone who writes and understands can make changes to the Rust code, but not on C or Python code. I can basic C coding, but wouldn’t trust me doing anything with it, but I would trust me doing something with Rust. Was it really that hard to understand? Also that means following is wrong:
The code is Rust code. Anyone who writes Python code can NOT read, adapt and make changes to it. That’s my point with C vs Rust, because not everyone writes C (or Rust) code.
Your argument
sapplies to any language. Hence why not re-write same tools in any of them, right?Because not everyone wants or can write any of them? If people like Rust and want to write and read Rust, then it makes sense to write it in Rust. Not in “any of them”. And when they see other projects written in Rust, it makes sense to review it, look into, adapt the code written in Rust. Not in any of the other languages, because the project is in Rust.
Let’s go back again to understand what my point was. I try to be clear as possible. The GNU tools are written in C. Only programmers who understand and can write in C can understand and write in C. But look… someone rewrote the GNU tools in Rust. Not in another language. In must be my lucky day, because Rust is my favorite and only language I write (that’s not true BTW, but that’s is besides). I loooove writing in Rust and immadiately open it up, look into, I can read and write in Rust. Not in another language.
I think I’d rather have it be rust AND copyleft, so the only projects that can use it are the ones that contribute back to society
MIT does not prevent from contributing back. Also GPL does not ensure it is contributing back. Besides thiefs and Ai companies, anyone can use GPL privately, modify the code and do whatever they want without contributing back, if not published openly.
Can you name me MIT licensed projects where it is a problem like you describe?
Xorg had several proprietary clones, and their software authors described how they chose MIT specifically to spite Richard Stallman who annoyed them, but with the benefit of hindsight they conceded that he had been right about the licenses. I saw this in a talk on YouTube somewhere.
I actually an agree an independent rust project would be really cool. If it was also GPL. I have yet to encounter any argument against GPL that doesn’t boil down to corpo boot licking.
You say “Even if it ends up being in a proprietary program, it’s better than not being able to use the code”. This is a bad faith argument. Everyone can use GPL code freely, the restriction is only that you must also publish under GPL if you publish. I’m sorry your favorite corporation can’t profit off community projects without giving back to that community… not. If GPL was a real problem BSD would have overtaken Linux ages ago. But it didn’t because GPL is good not just for the community but for the project. The only people that don’t stand to gain from GPL are corporations that want to monopolize the technology.
GPL is bad because it perpetuates the concept of durable intellectual property ownership/ licensing over supposedly “Free” (as in libre) code. Durable licenses are all bad. Unlicense is the only true FOSS license in common use, with an ‘F’.
“Free, but you must do these things” is not actually Free.
Notable and very honorable examples of projects that use Unlicense are youtube-dl and yt-dlp (and obviously, those are not programs intended to benefit corporations).
Now you have heard an argument against GPL that is not about corporations.
One example is that GPL games cannot be published in Steam, with using Steams proprietary tools and features.
And in general I am not actually against for any company to use MIT licensed products without open sourcing their own proprietary tools. It would be nice if they open sourced it, but I am against in forcing companies to do so. Now I understand the risks involved here, but its not like MIT license is the devil, just like GPL can be problematic in some cases, MIT can too.
For your example with Steam that would be perfectly fine to release under GPL, unless you signed an NDA to access Steams APIs or are actually including code provided by Valve under an incompatible license. Otherwise you couldn’t have GPL licensed software running on Windows using the Win32 APIs. What you can’t have is mixing code with incompatible licenses, but linking is fine.
I know for a fact that this is one of the major pain points, why they can’t or want to publish on Steam. There are games or programs with GPL code on Steam, but they do not make use of those features, because it would mean mixing incompatible licensed code (Steamworkshop) with your games code (GPL). I don’t know if things have changed, but I know in the past that was an issue.
Also dynamic linking is fine, not compile time linking. Those are two different things. I did not say dynamic linking is a problem.
Pretty sure a GPL game can include non GPL parts, software doesn’t need to all be released under a single license for everything in the package. Look at CDDA, bunch of different licenses apply to parts of that and its on steam.
I think you confuse two things here: Combining files in an archive with different licenses versus the source code that links and combines sources. GPL is about the source code. You can build a game that access other code in other licenses, otherwise no one in Linux could use Nvidia code in example. The final shipping product can mix GPL stuff and non GPL stuff, but cannot mix the code part that compiles.
Corporations are by their nature entities with priorities that are not aligned to the good of society. It is natural and obvious that we do everything in our power to compel them to do the best thing for society rather than the best thing for them.
Also while valve tends to be a pretty fair company they don’t need to be proprietary. Their product is selling game licenses and server space for cloud sync, none of that requires a closed source client. So while valve may be my favorite corpo they don’t get a pass from my previous statement about not being sympathetic to wanting to profit of community projects without giving back.
The exact problem you point out is in my view a feature not a bug because it means there is an economic advantage to someone doing what steam does but open source. Which is exactly the sort of incentive that helps capitalism help people.