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.
As a developer I love rust but canonical can fuck all the way off with this shameless license laundering.
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.
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.
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.
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?
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.
screw this project and it’s goal of corporate takover of a GPL project
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 guess we will see when closed source variants start getting made.
He knows but is being cynical about it.
And on that day, coreutils (and uutils for that matter) will magically become unavailable?
he he, no they won’t. But we won’t expect to see any kind of open source contributions from canonical anymore.
Free as in freedom :)
Why does everyone from piefed.social have the worst takes on literally everything?
Bahahahaha from the glass house of lemmy.ml! Good wheeze!
More like freedumb
Who’s issuing the paychecks, Canonical or Microslop?
Why does it matter?
i don’t really trust this
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.
I had a problem literally today because some script was relying on a particular behaviour of
dirnamethat was handled differently between uutils and GNU. It’s been fixed already in a newer version than the one I had, but it took me a long time to figure out what the heck was going on, because finding a missing expectation in a nested shell script is tough…It was just mysteriously doing the wrong thing.
I remember it was a common problem between Mac os and Linux as well.
One of the first things I get brew to do.
If you’re going to rely on shell scripts, you should stick to the built-in functionality of your shell as much as possible, as external commands can differ, or even be completely overridden, in random environments for a myriad of reasons.
For example, use
${var%/*}instead of(dirname $var). Forking out a whole OS process for such minuscule tasks is stupid anyway.This goes against la-la unix philosophy dreamy thoughts and beliefs, or portability fantasies. But it’s the right thing to do in the real world. And gives you at least some level of control over expected behavior.
I would argue the entire point of shell scripts is to coordinate running external programs, that’s what the shell is for, but I’m a dreamer.
If I was just going to use the built-ins I’d use Python or Ruby or something.
In this particular case I didn’t write the shell script, I was just debugging it because it broke on my system when I was running something.
Also your implementation has a bug because
dirname blah.pngreturns “.” 😉Also your implementation has a bug because dirname blah.png returns “.” 😉
It wasn’t meant as a 1-1 implementation, but fair enough.
I would argue that this helps my point. Because that’s an ambiguity
dirnamedoesn’t help with. What if “bla.png” is, or expected to be, a dir?And if you’re going to
test, are you going to use shell bult-ins or thetestcommand from coreutils? And if you’re callingtest, are you calling it with the full path so you don’t get a shell builtin anyway or not?If I was just going to use the built-ins I’d use Python or Ruby or something.
Using a better language is absolutely the right thing to do for anything that is not trivial.
Python is a shit choice for another reason though. They don’t know what backward compatibility means. So you may find your script broken in 2-3 years anyway. I don’t know about Ruby.
if they claim to be posix compliant but aren’t, then it’s their bug, not their users’
Parent mentioned that the supposed bug was already fixed, that’s not the point.
And they target GNU compliance, not POSIX compliance. Which is hard mode, since if it was the latter, they could have just checked out the freebsd utils or whatever at will whenever they felt unsure about something.
deleted by creator
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.
They’ve been partners ever since WSL launched, it was initially only available with Ubuntu.
Trust that Microsoft will send upstream any feature they don’t want to maintain themselves. Slowly, but surely there will be featured that only work on Windows. Then, when they believe they don’t have to play nice anymore, they’ll close off the code.
Embrace, Extend, Extinguish.
So… Let’s assume I don’t go around reading licenses for fun.
Can anyone explain to me what the major differences are between MIT and GPL?
MIT: The recipient of this source code can do with it as they please. That may include building it, distributing it, modifying it, building and distributing those modifications, commercializing it, whatever.
GPL: The recipient of this software, including builds of it, is entitled to the source code that was used to build it. Anyone with the source code can modify it, share those modifications, make builds with it, etc, but you cannot restrict the rights of the recipients of your builds more than the terms you yourself received the source code under. So you can make changes and distribute builds of those changes, but users you distribute builds to are also entitled to your code including the changes you made.
AGPL: Same as GPL, except the recipients of this software also include users of the software, such as over a network. This was because with SaaS suddenly people were using software they hadn’t “received”, because it was running on someone else’s computer and they only provided inputs and received outputs, so the licence was created to bring this back in line with the spirit of the GPL.
LGPL: You can use this library in your non-GPL code, and it doesn’t “infect” your entire codebase by extending the entitlement of the source code outside the library to all users of your builds. It does still entitle users to the source code of the library itself though, especially if you’ve made changes to the code of that library.
People often talk about the GPL preventing commercial uses, but that’s actually not true. You’re allowed to sell GPL software. It’s just a somewhat risky venture, because all users you sell software to also get all the source code. That means anyone can buy your software, request the source, and then immediately start competing with you by offering it themselves for free or cheaper or whatever. So it’s allowed, but rarely works for very long unless you have a lot of good will in the community.
Two additions:
- some software is also sold under a separate license in addition to GPL, so you can choose if you want free open source or paid closed source (e.g. Qt has this model)
- being in breach of license terms doesn’t mean you’re forced to do anything automatically: it means you can get sued and a judge might order you to do something (probably pay money) to heal the breach, or you can settle out of court (probably by paying money).
Sure but there are lots of companies that don’t provide source code for their GPL software. And nothing happens.
There’s an ongoing lawsuit: https://sfconservancy.org/copyleft-compliance/vizio.html
It just takes forever and lots of money. That’s not a software license problem though, that’s more of an “American Legal System” problem. And I say that not to imply that it’s worse than other legal systems, just that I know it’s one with these problems and I don’t know about others.
Damn dude, this is really articulate. Thanks.
AGPL helps a bit more for commercial uses as its more strict. But its will not 100% of what people think of protection.
Very nice breakdown.
Best website to look up any licence:
Here you go:
As for the tech, I will leave it to those who are experts in the field. My worries are about the licensing. I just love GPL licences.
The rust has set in and the rot begins…
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.
MIT is cancer
Yep. I hate to see it being used as a default license in the Rust ecosystem. Wonderful language, but terrible corporate culture.
It’s great for libraries. Less so for applications.
I think if someone licenses their applications wrong, they shouldn’t use my library. That’s why I license them as GPL.
But there’s also LGPL if you’re more tolerant to having your work used for less free software than I am.
For libraries MPL at least provides a little copyleft protection without making it difficult for developers to actually use them
I don’t think so.
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.
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.
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
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.
Why.
Why not?
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.
But from all the things why core-utils? I don’t think it is common to need changes in core-utils. Now with this MIT version it may certainly be needed, because of broken compatibility. So it feels like instead of doing nothing (because they work as is) and using GNU core-utils they switch to MIT core-utils that are slightly incompatible and because of that need work. I would assume that it will certainly provide patches for MIT core-utils, but I am sure it will just make another platform target for scripts like macOS. Some GPL projects will change their scripts to make them work with Ubuntu.
I guess corporations will corporate.
Because the kernel is the kernel, you just accept it for what it is. The vendors modules are required to run on the stupid soc made on three generations old fabs you’re targeting in your build and the only other part you need to be portable is the standard core utilities.
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.
Little late, but currently watching the entirety of the talk. Very interesting to see a honest view from someone who is invested into safety and C++. The language itself will probably never be safe, but maybe “safe enough”.
but maybe “safe enough”.
It won’t be. Bjarne doesn’t want any real workable safety to be added. And that’s for the best because it’s a shit language. And falling out of favor, especially for new projects, is the best outcome.
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.
Removed by mod
It’s been a long road[…]
🎵🎶🎵
