The “reported upstream” link is broken (fixed link).
The amount of issues is scary
A significant number are slight differences from GNU behavior that likely wouldn’t impact users or just random miscellaneous project tasks like “this is inefficient” or “clean up this thing.” Not saying there aren’t problems to be addressed, just that the number looks more concerning than it actually is. Wouldn’t be surprised if some are outdated as well.
TLDR:
Current status for 26.04 LTS
We shipped rust-coreutils as the default in Ubuntu 25.10 to maximise real-world testing ahead of the LTS. Based on the audit findings and remediation progress, here is where we stand for Ubuntu 26.04 LTS.
We have included the latest upstream release 0.8.0 in Ubuntu 26.04, which incorporates the bulk of the security fixes.
cp, mv, and rm continue to be provided by GNU coreutils in 26.04. These utilities have remaining open TOCTOU (time-of-check to time-of-use) issues (8 as of Apr 22, 2026) that need to be resolved before we are confident shipping them.
Our plan is to address the remaining issues as soon as possible and target Ubuntu 26.10 with 100% rust-coreutils.
A very, merry 🖕 to whoever decided to use a cuck license for this.
🖕 to the mods, their censorship, and all the retards that abuse reports to silence ideas they don’t like.
You people are the reason why the world is going to shit and nobody has the balls to fight back.
Pussies.
The team of over 200 rust developers involved with the project did. They wanted to avoid the “politics” and are not entertaining comments or explaining their decisions. It’s not up for discussion.
This is incredibly common in rust development.
Why are you hallucinating facts?
- There is no “team of 200 rust developers”.
- “<lang> developer” is not an identity.
- uutils is not a “professional” project, as in people are paid by the (non-existing) uutils company to work on it.
- The project started as personal hobby of one person during COVID, There were no 200 contributors who sprung up magically and simultaneously from the start.
They wanted to avoid the “politics” and are not entertaining comments or explaining their decisions. It’s not up for discussion.
If you think you saw a group of 200 people starting uutils and doing this. You should seek medical help.
I double checked myself and linked the 15 month old ledru blog post that has the actual claim and statements about rust-coreutils in my reply.
I did that before you replied to me, but it may have taken a little bit for edits to federate across instances.
The number is 530 contributors, not 200 rust developers, although I personally feel that because the project is in rust the word contributor and the phrase “rust developer” are interchangeable without incurring any accusation of manipulative language or purposeful deception.
I made no claim that uutils is a professional project. Nonetheless, the person who wrote the uutils blog post I linked is an employee of Mozilla and the author of the update in the op is an employee of canonical, the company that makes Ubuntu. This is not uncommon in all open source development regardless of licenses and is the reason I didn’t bring it up. Not enough people realize there are double digit big name projects maintained by some guy in Idaho and the overwhelming majority are shepherded by developers and maintainers in the pay of some company or another.
I never made a claim about who started the project to rewrite coreutils in rust.
🖕x 200 then
Any distro that packages this should package a libre version with GPL.
Eventually that option will go away.
Even if a decent number of the vulnerabilities closed by mit/rust coreutils are not exploitable or would require an insane chain, distros untouched by the perverse incentives of rust will eventually adopt them based solely on the number of closed bugs alone.
We are headed for the ibm/unix past of open source because the multipolar world we are headed towards mirrors the conditions of that past.
The tools of that transition happen to be rust/junior devs/ai, but if different tools were available that would generally reach those ends they would be in use instead.
Rust basedMIT licensed coreutilsYes! I mean, don’t divert the hate of permissive license to Rust. Those are unrelated but now more people hate Rust because of this.
They’re not unrelated. Lauded projects to rewrite some gpled c thing in rust are almost universally mit licensed.
Attempts to get those licenses changed are almost universally met with a line in the sand.
There are a lot less GPL projects in your system than you might think. Your core system is already filled with liberally licensed libraries and programs. Case in point, since you talked about rust rewrites, original sudo is not GPL software.
Oh no, a non gpl package on my computer? How did you find out about my one weakness! I’m melting, melting! Oh, what a world, what a cruel, cruel world!
If you’re posting from Desktop Linux, your comment utilized at least 10 liberally licensed libraries. And that’s before it got into the wire. GPL packages are a MINORITY, not a majority with exceptions.
How does copyleft benefit you?
It establishes and defends intellectual property held in common by all of humanity.
N.B. held in common, not public domain. The property and right of all people for all time.
Our new present and its future requires the defense of ideas for all.
Of course, if you want to feel smug and know you’re on the winning team then be assured we are going to be losing copyleft soon.
Our new present and its future requires the defense of ideas for all.
And MIT is lacking because it doesn’t force commercial users to lie about what they do behind closed doors? Trust me, if they are so inclined, they already do plenty of that. Next, with LLM assistance, all your copyleft code is freely available for word-salad-surgery remix and rebrand with whatever license anybody wants - as it always has been, LLMs just cut the labor required to do so by a huge margin.
Yes. MIT is literally lacking that protection because it doesn’t force corporate users to lie or do their own work.
Should the fact that the powerful act with impunity when not challenged be an argument against challenging them? That’s a little facile…
Again, if you just want to feel good that the things I care about are going away, rest assured that llm output is going to remove the concept of copyleft in advance of a multipolar world where secrets and incompatibility are suddenly the order of the day.
I don’t think I’ll ever understand the constant complaints about the license. If it were the kernel or some software that was particularly unique, then I’d understand. However, there are many existing implementations of the coreutils programs that are already under permissive licenses. If someone didn’t want to use the GPL, they could just use one of those. This is partly why it is incredibly fiddly to write cross-platform shell scripts.
The mit license allows someone (some company) to modify the open source codebase and sell the result without making their modifications public.
It allows the software equivalent of the enclosure of the commons.
If there was a particularly large or significant and widespread codebase —like for example the coreutils— that was used everywhere and mit licensed, a company could make their own slightly different coreutils without publicizing the differences and use their position in the market to enclose the commons of knowledge about the use of that software. Such a situation would lead to a fractured feature ecosystem and confusion around best practices. In that environment, the biggest and most popular software distributor would benefit because their product would be most common and therefore the best target to design around.
I know there’s a lot of “coulds” and “woulds” in that sentence, but that’s exactly what happened in the 80s and 90s with the ostensibly open source Unix codebase and the reason why the gpl was invented.
The mit license allows someone (some company) to modify the open source codebase and sell the result without making their modifications public.
That is not equivalent to closure of the commons, that’s some company spinning a proprietary version of something. If they try to sell it, most people won’t buy - most people will continue to use the FOSS version. The people they sell it to may enjoy the proprietary enhancements, but that doesn’t prevent the FOSS community from developing those enhancements in the open if they so choose.
MIT license is not a software patent.
The enclosure of the commons.
It’s a thing that happened a long time ago during the Industrial Revolution in England where land that people used to grow subsistence or cash crops for their own use as opposed to their lords use (land called the commons) was fenced in and given to newly elevated lords as estates.
The effect was that people who could live in villages before were forced to move to the cities and live in slums or poorhouses and became laborers in mills.
E: clarity
Oh, so you believe MP3 pirates have actually stolen something off of the retail music shelves as well, then? Digital piracy is the ultimate evil and all that? Supporting strong jail terms for pirates, are you?
The difference between the commons of the industrial revolution and the commons of the digital landscape is that the commons of old was a finite resource. The digital commons is effectively infinite.
It’s a mat with conclusions on it and you can jump on them, it’s a jump to conclusions mat!
The digital commons is protected by making sure changes to it and work that builds upon it remain in the commons, not by letting everyone go hog wild because copying only costs the amortized price of access, storage and electricity.
Gpl does that by requiring that things that use it also become gpl.
I’m really surprised to be explaining this. Some guy wrote a book that has a good overview of all this stuff but in the context of sampling almost 30 years ago, I’ll chase it down when I get near that shelf.
It’s already fractured, as I literally mentioned. That’s why it’s hard to write cross-platform scripts. Part of the reason it’s fractured is that the implementations most commonly in use other than GNU coreutils are permissively licensed and thus cannot easily adopt unique features from GNU coreutils.
In any case, at this point, changing the coreutils license itself will not materially change much in terms of how fractured the existing landscape is given that people could already use Busybox, Toybox, programs from any of the BSD userlands, etc. if they didn’t want to use GNU coreutils for whatever reason.
If it doesn’t matter then why not use the original projects license?
I know you’re not able to read minds or responsible for the greater rust community but how come when I or anyone else asks the above question of any mit licensed rust project is the answer never “huh, I guess if the license doesn’t matter then we can gpl it no problem!” And always “no, and get your politics out of my code!”
It clearly matters to someone because everyone’s feet are always dug in to the sand about sticking with mit.
Do you make your learning projects that you don’t really care about GPL? I don’t.
The reason people don’t want to GPL stuff like this is it’s bothersome to change it and get support from the existing contributors who are actually, you know, contributing to the project. The “get your politics out of my code” thing (for the license) is at this point because some completely random person who has no relevance to the project coming by, screaming about the GPL, and subsequently spawning a massive MIT vs. GPL debate/mudslinging contest is incredibly annoying. I’d frankly be tempted to keep it non-GPL just to spite anyone who does that. It’s a different thing if people who are actually relevant to the project consider doing it.
EDIT: I noticed this is a different subthread than I was thinking it was, so for context the project was started as a single person’s way to learn Rust using relatively easy to implement programs (with easy to access docs). Also, elsewhere someone mentioned forking. In that vein, I largely think this entire discussion is completely unserious because there has been a over a decade for someone to fork it in one of the drive-by license complaints, or even through complaints like here, yet no one has done anything.
The code in question is a rewrite of a gpl licensed c package in rust under the mit license.
The “completely random person with no relevance to the project” specifically in reference to uutils-coreutils, but I will stand on the assessment for every other rust/mit rewrite of a c/gpl package, is in every instance a contributor, maintainer or user of the gpl package it’s based on and therefore neither random or irrelevant.
They are always people saying “hey, we wanna help but your license is standing in the way, why not change it so we can more easily work together?” Or “this project is great but the license is too permissive, since the thing it’s based on got by great with gpl, couldn’t the license be changed to gpl?”
Forking over license would be counterproductive and silly when the thing in question is a reimplementation of a gpl package. Literally just use the license that the original work had!
From my perspective the people asking rust/MIT rewrites of gpl/c stuff to go back to gpl are being perfectly reasonable and have every possible definition of standing to make that request and always get treated as interlopers.
I believe you about the spite thing though. People do be spiteful.
While you’re right that this isn’t the thread about someone’s private learning project (btw, allowed under gpl), plenty of personal learning projects have changed license when they grew beyond the scope of just some guy messing around.
Part of refactoring during that growth includes administration and licenses are part of that.
Projects I have personally written had to have a license applied or changed when their scope changed.
I think especially once several companies employees are acting in their official capacities in the project it’s very reasonable to bring up the license!
We havent even touched on the violation of the gpl aspect, where no programmer and certainly not one using a llm could be reasonably thought to be ignorant of the gpl coreutils inner workings and doing a clean room implementation which is what is legally required to not be considered a derivative work!
Decades ago the gpl assholes had to figure out that you can’t use the license to stop Sony from doing something you won’t use it to stop your neighbor from doing.
The way around that is to make the rust rewrite gpl.
The “completely random person with no relevance to the project” specifically in reference to uutils-coreutils, but I will stand on the assessment for every other rust/mit rewrite of a c/gpl package, is in every instance a contributor, maintainer or user of the gpl package it’s based on and therefore neither random or irrelevant.
There are constantly random people complaining who literally have never been involved with GNU coreutils (or frankly any GNU project at all) or uutils. If all the people complaining worked on GNU projects, they’d have a truly astounding supply of contributors.
They are always people saying “hey, we wanna help but your license is standing in the way, why not change it so we can more easily work together?” Or “this project is great but the license is too permissive, since the thing it’s based on got by great with gpl, couldn’t the license be changed to gpl?”
People say this in the other direction as well.
Forking over license would be counterproductive and silly when the thing in question is a reimplementation of a gpl package. Literally just use the license that the original work had!
From my perspective the people asking rust/MIT rewrites of gpl/c stuff to go back to gpl are being perfectly reasonable and have every possible definition of standing to make that request and always get treated as interlopers.
I suppose you complain about this when the BSD folks reimplement functionality present in Linux or other GPL projects. To put it bluntly, uutils isn’t GNU coreutils. It’s an implementation of the utilities trying to get as close as possible to the same functionality, but it will likely never truly “replace” GNU coreutils (as long as the latter is still being developed, at least).
We havent even touched on the violation of the gpl aspect, where no programmer and certainly not one using a llm could be reasonably thought to be ignorant of the gpl coreutils inner workings and doing a clean room implementation which is what is legally required to not be considered a derivative work!
This is completely ridiculous. How does “no programmer … could be reasonably thought to be ignorant of the gpl coreutils inner workings” even make sense to you? Under this thought process, it’s impossible to make a clean room implementation at all because you cannot be “ignorant of the [XYZ project] inner workings” if you implement the same functionality. I suppose all the BSDs are in violation of the GPL since they have implemented roughly the same functionality. Not to mention Toybox.
Is rust-coreutils being developed by Canonical? Then it sounds like shooting themselves in the foot. Why give competitors a chance to take over a vital package that is at the core of their OS?
How is MIT a “chance to take over”? It’s a chance to go proprietary with future enhancements, but that’s far from a takeover.
I’m no licensing expert and I was responding to the previous comment that said someone can fork it and then make it proprietary. So If they already have dominant market position, they could force people to use a proprietary version.
Some Canonical employees are working on it but it’s not originally a Canonical project.
mit lets companies take them without contributing back critical stuff like security fixes.
their money and resources is very important to keep foss alive and it relies a lot on the gpl because it just means they are forced to take responsibility for the projects they use to make their billions.
critical stuff like security fixes.
Yeah, that’s straight outta Canonical’s “pay us for extended support” playbook. Which is why I shifted to Debian a couple of years back. Canonical used to add positive value to Ubuntu, now they’ve shifted into the negative from my perspective.
That’s great, except they could already just use a permissively licensed implementation. This is in fact what a lot of companies already do. For instance, Android uses Toybox, macOS uses utilities originally ripped from NetBSD (mostly), etc.
Generally, a lot of companies also don’t contribute back fixes upstream. They’ll often just dump the code in some hidden away corner of their site as a giant source blob.
For something like coreutils, where a significant change is sort of unlikely in the first place, thinking the GPL makes a difference is bizarre to me.
So why did they choose to use permissive license instead of the license of the original?
Because it was started as a project to learn Rust by one dude.
Also, that was back when Rust had bad documentation (at least a couple years before 1.0), so by far the easiest way to learn was by making something like this and looking through other existing projects like the compiler or Servo.
That doesn’t answer the question why use different license than the original. And why not change the license/fork to gpl when it became more than a fun project. As we see it is a major issue with the project.
Being able to take someone else’s code used as a learning exercise for your own learning without worrying about it being GPL’d is quite useful. You seem to be arguing permissive licenses should never be used, which I think is ridiculous. A project meant to just learn about XYZ language/framework/whatever by implementing “simple” tasks is one of the most basic examples of a project that should be under a permissive license.
The only thing that could realistically be done is to license all changes going forward as GPL. If someone wanted to fork the project to do something like that, they could. But of course no one will bother, because the people who are terminally rabid online about this project not being under the GPL contribute to neither this project nor GNU coreutils.
It is not a major issue. It’s only really an “issue” at all because people who don’t contribute and likely would never contribute anyway constantly complain about it. I will state this again: there are multiple already existing implementations of the coreutils programs, so there is practically nothing keeping companies tied to it. There is little actual benefit to the coreutils programs in particular being under the GPL.
Yeah…
