I'm mixed on it. If it is more secure/safe then that's a good thing, but if it's done because it's MIT-licensed instead of GPL-licensed, then that could possibly be concerning.
this post was submitted on 24 Mar 2025
104 points (92.6% liked)
Linux
52350 readers
850 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
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.
uutils is not distro-specific.
The correct title should be "Ubuntu explores replacing gnu utils with MIT licenced uutils".
Waiting for Canonical to up sell proprietary utils features by subscription. Ubuntu's regular release cycles were brilliant in 2004 when there weren't a lot of alternatives but why does it still exist?
Sorry, "tee" is not part of the basic Ubuntu package. Do you want to unlock premium coreutils for the cheap price of 19.99$ p.m.? Alternatively, upgrade your Ubuntu pro to pro-double-plus-good for 10$ p.m.
What does this have to do with MIT licensing?
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?
The best example I could point to would be BSD. Unlike Linux, the BSD kernel was BSD (essentially MIT) -licensed. This allowed Apple to take their code and build OSX and a multi-billion dollar company on top of it, giving sweet fuck all back the community they stole from.
That's the moral argument: it enables thievery.
The technical argument is one of practicality. MIT-licensed projects often lead to proprietary projects (see: Apple, Android, Chrome, etc) that use up all the oxygen in an ecosystem and allow one company to dominate where once we had the latitude to use better alternatives.
- Step 1 is replacing coreutils with uutils.
- Step 2 is Canonical, Google, or someone else stealing uutils to build a proprietary "fuutils" that boasts better speeds, features, or interoperation with $PROPRIETARY_PRODUCT, or maybe even a new proprietary kernel.
- Step 3 is where inevitably uutils is abandoned and coreutils hasn't been updated in 10 years. Welcome to 1978, we're back to using UNIX.
The GPL is the tool that got us here, and it makes these exploitative techbros furious that they can't just steal our shit for their personal profit. We gain nothing by helping them, but stand to lose a great deal.
Thanks for your explanation.
load more comments
(1 replies)
Kinda like a full 180° back to UNIX™.
Okay, I'm not a fan of this either but let's not get too worried about this. Everyone's known Ubuntu is a joke for a long time and they don't really have much influence on even several of their downstreams, let alone the rest of the ecosystem.
I think Ubuntu has a lot of influence in industry
I prefer a glibc replacement.
Time for Mecha-Stallman to declare war.
It's funny since don't these core utils come from bsd meaning the new license is more like the original license than gpl is like either. So didn't gnu effectively steal the code and change the license for political reasons?
The time has come to GNU-slash the enemies of freedom!
I for one welcome our rust overlords
I personally don't see the point.
See other comments: all these rewrites are not using the GPL but rather permissive licenses like MIT. Bye-bye FOSS (in those ecosystems).
I don't like them moving away from gpl but there were already plenty of non-gpl coreutils clones, so, i'm not sure how much it really matters as long as the linux kernel is still gpl.
Unlike the other alternative coreutils, uutils focuses on GNU compatibility. If you depend on GNUisms, uutils allow you to unGNU & unGPLv3+ your system.
I don't understand, you'd still have to completely replace the linux kernel for a situation where this matters to occur, no?
and the linux kernel is where 99% of the work is, correct?
The Linux kernel is licensed under GPLv2, not v3. The third version of the license forbids tivoization (vendoring unmodifiable copyleft software). Also, the GNU coreutils aren't limited to Linux.
I know they aren't limited to linux, but can you give me an example of a situation where this matters?
All of the situations I can think of are remedied by the fact that linux is still GPL'd
I will give you one. You want to embed the coreutils in some other projects ie. a browser. But at that point it's cheaper for you to submit your modification upstream because you are making money selling the browser not by selling modified coreutils. Maintaining your own fork is not worth it once you make meaningful changes.
~~I think this is the reason why uutils are being funded by Big Tech and why they chose this license. (to get funded)~~ correction: I only found that they are funded by the Sovereign Tech Fund and apparently the author is open to changing the license, they don't care (see video/presentation).
But yes, I agree this whole comment section is deranged. The reason why Ubuntu chose uutils is because of Rust's safety and because of speed. In some workloads (I think it's sorting) they totally smash the GNU counterparts.
For Ubuntu it does not make any sense to make a proprietary fork. You don't choose your OS based on its coreutils. If they added a new convenience flag for their proprietary grep, it would just make them look bad. Also skilled users would hate it because now their scripts would not be portable. Or if it were really that big of a gamechanger, the feature would get added to the other coreutils and Ubuntu would end up with nothing but bad reputation. Unless they made change to the underlying code for performance. Then it would be harder to implement in the other coreutils but as I said before, nobody would care. Faster and safer coreutils are a nice to have, not something people base their OS choice on.
Edit: added source to author's stance on license
load more comments
(4 replies)
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.
load more comments
(4 replies)
load more comments
(6 replies)
view more: next ›