Link: https://itsfoss.com/news/ubuntu-rustification-coreutils-migration/

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.

So, they will have to continue to support feature for feature, bug for bug with coreutils and others forever? What's the endgame here?

Relicensing

i don't really trust this

As a developer I love rust but canonical can fuck all the way off with this shameless license laundering.

how so?

This is dumb, I have to use osX for work and having coreutils be similar but not quite the same is a PITA, why would you inflict this on yourself to close a class of bugs that aren't really a huge concern for coreutils.

screw this project and it's goal of corporate takover of a GPL project

uutils is MIT

Unless other distros switch away from coreutils, it will remain the standard. It seems a lot of work for little/no upside.

The problem with macOS is that they use BSD utils, which are lacking functionality from GNU utils. If anything, Rust uutils being pushover-licensed means that Apple would be more likely to replace their broken coreutils with uutils and you'd get more parity with the coreutils installed on most Linux systems.

And I say that as someone that despises pushover licenses, but this creates the probably that macOS utils won't suck someday.

How is this license laundering? These are complete new implementations and the original projects are not touched.

This is not a takeover of GPL project, this is a new project that is compatible to existing tools with GPL license. The old GPL projects are untouched and not controlled by Canonical.

I don't understand why Canonical is replacing the existing GNU tools. Unlike many others, I don't think its "taking over GPL projects" or "license laundering" and I am also not against MIT license. My question is, why Canonical is doing this.

Someone has to ask their masters in Redmond.

MIT is cancer

I don't think so.

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.

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.

Who's issuing the paychecks, Canonical or Microslop?

Why.

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.

Why not?

Why does it matter?

Its not 1-1 so this is going to fry some bash scripts and install scripts. At work we had to stop using Ubuntu because of a couple of bad installs via this change. Debian is just as good so its fine.

I have no opinions on the rewrite, but I wish they made a flavor or something just for this.

Im not sure as well. A lot of popular stuff is on MIT. But if I were to guess, its one of the most permissive licenses, which is somewhat a bad thing when companies suction up solutions with AI and spit them out without attributing the coder involved.

I don't think Ai companies care about the license at all, or cannot be checked after the training. So that is not really an argument to me.

haha. Welp it only becomes an issue if your software doesn't get audited. I worked in medical and government so it might be a different world where your at. We literally cant use certain software given licenses and such. It can get a bit loony.

AI has tells they built in nowadays. If you use the newer models at least. But in addition...its pretty easy to just find the code in codebases if you end up in an audit.

Im not defending it, just saying that MIT is one of those that you can get away with a lot more than other licenses. And that might be an issue to some.

Yep. I hate to see it being used as a default license in the Rust ecosystem. Wonderful language, but terrible corporate culture.

I guess we will see when closed source variants start getting made.

I can't speak for medical field... but a more serious topic, in example videogames. :D

I think sometimes GPL can be in the way, so it is a tradeoff. In example if you use proprietary Steam features in your game, then you cannot build the game with GPL libraries and code, because that is not compatible with proprietary code. For some that is exactly what the GPL is set to do, for others its hindering games and other software to be released on Steam with Steam features. That means, its impossible to sell GPL software on Steam, if you want to use any of those features (I think in example Achievements and online save files in example). MIT would solve this issue.

Feature, not an issue.

He knows but is being cynical about it.

Ill be honest, I know of GPL but I know theres like 5 different versions of the GPL. Like AGPL is the most restrictive and has held up in court before because someone forked a project then stripped out everything, sold it again. And was deemed liable.

MIT could potentially solve it...or make it even more messy. Ill believe you on videogames.

If I were to guess, its probably moot in all cases unless it goes to court (or like my orgs not let you use software) and gets defended one way or another.

Rust eliminates memory safety vulnerabilities. It accounts for a large percentage of bugs that need patching in live environments, like servers.

I believe Ubuntu wants to grow in iot or embedded devices so reducing patching needs gives them a competitive edge there.

Getting ahead of the curve regarding potential future legislations/regulations around unsafe languages, which may introduce contract conditions, liabilities...etc (See 2:30-4:30 of this talk for an overview).

If they listened to the calls describing this move as premature, and it arguably was, they could have gotten strapped for time later.

An implementation in a good safe fast modern language that developers actually enjoy has other tangible benefits of course. But if people want the "corpo reason", the above should provide an answer.

Whilst that may be true, I would expect coreutils has all memory issues debugged by now.

I can understand new applications - or perhaps extended versions - to be created in Rust, rather than reinventing perfectly good wheels.

It feels like they're doing this just for the sake of it, and I expect there's probably better things that could be done with the money / labour

Thanks for providing a source. I will watch it at later time and put it on Watch Later list. Until then I can't really say anything about it, just wanted to thank you.

The corporate adoption on uutils already started.

https://learn.microsoft.com/en-us/windows/core-utils/overview

Windows is now using uutils for their coreutils. I want to see if Microsoft gives back anything to the project with that permissive license. Also, aren't canonical and Microsoft partners or something? I saw the Ubuntu wsl news.

You could understand if you used a materialist analysis.

Canonical sells products and support to corporations. The gpl is a problem for corporations because it requires that they contribute their changes back into the commons, creating additional overhead in many ways.

Canonical is funding, prioritizing and providing support for a rewrite of a gpl project in a different language with a more permissive license.

Put two and two together. Canonical is bankrolling and pushing something that materially benefits them.

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.

Do you know about the LGPL license? I think it allows you to statically link proprietary code, and the LGPL code remains open while the closed code remains closed. Modified and distributed lgpl still remain under the LGPL.

https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

I really don't see what they would gain by license laundering... They'll unGPL Debian, Gnome, Wayland and the Linux Kernal next?

If you wanted something out of copyleft, you would have an easier time just building on top of FreeBSD. It does like ~80% of what Ubuntu does already.

I don't feel too hot about them using MIT either, but I fail to see why they would implement this just to get rid of a GPL component. Seems expensive for nothing.

My bet is, Canonical as a service provider has a paying customer that is willing to pay for access to more secure rust utils. Or they want to save resources fixing CVEs.

Yea know that is a fair point. I guess I struggle to see any other reason to support this? Even though I believe rust is nominally more secure it’ll be a decade before any core utils clone will be as hardened as the original just by virtue of the original having decades of bug finding and fixes done already.

I don’t think canonical would go through the effort under normal circumstances but I think they’re just taking the opportunity in front of them to ride the rust hype into a less copyleft ecosystem.

This actually ties into a broader complaint I have that the rust ecosystem is built around MIT due to influence of the corporate backers of the rust foundation. Which is unfortunate because I actually really love rust as a language.

My bet is, Canonical as a service provider has a customer that is willing to pay for access to more secure rust utils. Or they want to save resources fixing CVEs.

There's also the spectre of future security regulations possibly demanding these changes one day too.

I still think its built on someone else's money. lol

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.

Hmm you could very well be right. I guess I’m being to reasonable by knowing new rust code is not automatically (and not usually) more secure then old c battle tested c code. Shareholders and CEOs don’t understand that, I wouldn’t be surprised if someone’s been convinced rust is axiomatically more secure and bankrolling the migration over it

Yes, but does anyone actually use LGPL still? Anyway that is a different license and not really GPL anymore, as it does not force anything. I mean if the project is GPL licensed already, then you can't turn it into LPGL, because that is no longer compatible. So the issue for programs and games being GPL remains. If they were LGPL from the start, yes, that probably would solve it.

I think that aligns with the deployment strategy right? They are targeting 27 which is the middle release and not LTS. Get some mileage on it prior to 28 LTS.

But yeah, its all corpo speech when they talk about it. Its probably some executive decision of the likes of "We think Rust is axiomatically better, so let's implement it" like you said.

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.