I totally agree, licensing GNU coreutils with a license without any #copyleft is a very very bad move and an attack to the community contributing to the project. GNU-Linux is what it is also because of the license used
2 Likes
Couldn’t agree more. I’ve been using and supporting Ubuntu since 2004 but this is frankly a hit under the belt and a serious threat for Linux future. Please don’t abandon copyleft like it was nothing. Replacing GPL software with MIT is not a move without long term consequences. Linux is what it is also because of the license it has.
2 Likes
I’m engaging Slow Mode on this topic to prevent piling-on until the developers have a chance to respond and to keep this topic constructive.
Note that it’s currently a weekend, so Slow Mode will run for several days.
- While Slow Mode is engaged, your ability to post --and to edit your posts-- will be very limited. So be sure you say what you really intend to say before posting, because you won’t be able to fix typos or take back heated words.
1 Like
These comments ignore the fact that the Linux license is not a GPL license.
Linux itself does NOT fall under GPL2. Go read the Linux license, but please read the two exceptions that differentiate Linux from GPL2:
- – gcc exception allowing linked 3rd party code that does not then become GPL2 or 3
- – Syscall exception which allows 3rd party code to make syscalls without becoming GPL2 or 3
Linux is not GPL2. Read the license 
. I don’t think it would have such broad adoption if it were a strict GPL2 licensed product.
3 Likes
Hello all!
Firstly, thank you all for your comments. I appreciate the engagement on this topic! I’d like to address the topic of licences with my perspective.
In my opinion, moving a package from an implementation that is GPL to an implementation that is MIT licensed does not pose a threat to Ubuntu, or our community and I hope to explain why I hold that opinion in this post.
As I mentioned in a previous reply, this move should not be seen as indicative of a political agenda, or of a wider move away from GNU software as a point of principle - this change is motivated by a desire to evolve core technical components of Ubuntu in a way that makes them as resilient and maintainable as possible over time - hopefully attracting new contributors to our already vibrant community.
I recognise the pivotal role that the GPL has played in the evolution of open source - in fact most of Canonical’s own software is, and will continue to be, GPL licensed for all of the reasons presented above in the various replies to this post.
Ubuntu is a collection of software that we curate to build a distribution. It’s a project dedicated to shipping the latest, and best open source we can find. There is no evidence of foul play, bad practice or poor intentions from the uutils maintainers - they’re a thoughtful, dedicated community who are building their own software, and even contributing back to GNU coreutils in some cases. They are achieving things I think we should aspire to with Ubuntu in the coming years, and I remain committed to giving this a chance at success - noting that we and others will need to work closely with them to resolve issues with locales, selinux support and other issues.
If the current situation changes and we believe that the interests of the uutils project are no longer aligned with those of Ubuntu, we can change the coreutils package we choose to ship with Ubuntu.
Likewise, if during the 25.10 cycle, we identify significant incompatibilities that detract from the stability and overall experience people have come to expect from Ubuntu, and we believe they cannot be solved in time for 26.04 LTS, then we will of course reconsider.
In the mean time, GNU coreutils will remain available, fully maintained in the Ubuntu archive for those who wish to use the existing package.
I hope this addresses some of the concerns raised. And I’d love to hear if anyone has had a play with oxidizr, and what their experience has been!
Jon
6 Likes
I tried oxidizr
$ sudo oxidizr enable --all --yes
2025-03-16T06:51:43.669756Z INFO Updating apt package cache
2025-03-16T06:51:45.108804Z WARN Skipping 'coreutils'. Minimum supported release is 24.04.
2025-03-16T06:51:45.108824Z WARN Skipping 'diffutils'. Minimum supported release is 24.10.
2025-03-16T06:51:45.108827Z WARN Skipping 'findutils'. Minimum supported release is 24.04.
2025-03-16T06:51:45.108829Z WARN Skipping 'sudo-rs'. Minimum supported release is 24.04.
I converted my Ubuntu Unity into Rhino Linux, so I think that may have played the part in this.
$lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Rhino Linux 2025.1 (server)
Release: 2025.1
Codename: devel
1 Like
Ah yes, oxidizr checks the release Id to ensure it’s “Ubuntu” and that the release string is “naively” greater than the minimum supported release
Edit: it should be fairly trivial to edit the source and build it if you wish
3 Likes
I enabled it recently but quickly ran into this issue while trying to do a pyenv install:
The good news is that the bug is already fixed, but the bad news is that Oracular doesn’t contain the fix, so I’ll need to keep it disabled until I update to the next release.
Usability-wise, the tool worked and was straightforward enough to use, so that is all good.
Given how quickly I hit an issue that would seem to be a fairly common use case, I do wonder how much investment these tools will need to make them viable replacements for the entire OS.
1 Like
Given how quickly I hit an issue that would seem to be a fairly common use case
oracular shipped with 0.0.26. Since then, 1861 patches have been written 
But yeah, bug reports are welcome. Regressions will be identified!
3 Likes
Hi! I jumped in with the defaults (coreutils and sudo-rs), and so far only minor issues, like sudoedit/sudo -e not being implemented…
I encounter the main issue when doing a snap refresh of vscode. It might be the mkdir -p (not sure) issue, but the update fails on copying files from the old version to the new one, with a bunch of lines like the following:
cp: '/home/galileo/snap/code/185/.local/share/containers/storage/overlay/d15233c533021c7a9750a3162df1c6a98e8371e4dc585c3745dd8182539510f2/diff/var/lib/apt/lists/auxfiles' -> '/home/galileo/snap/code/187/.local/share/containers/storage/overlay/d15233c533021c7a9750a3162df1c6a98e8371e4dc585c3745dd8182539510f2/diff/var/lib/apt/lists/auxfiles': No such device or address (os error 6)"
If I disable the experiments it works normally.
could you please report a bug with steps to reproduce ?
Sure! I need to check if I can revert the update and try again… or on the next available update.
At the moment the only relevant things I can think of is that vscode has the devcontainer addon, and that might be where the folders it was trying to create come from.
$ sudo dpkg --configure -a
Setting up grub-pc (2.12-5ubuntu9) ...
error: unexpected argument '-Z' found
tip: to pass '-Z' as a value, use '-- -Z'
Usage: cp [OPTION]... [-T] SOURCE DEST
cp [OPTION]... SOURCE... DIRECTORY
cp [OPTION]... -t DIRECTORY SOURCE...
For more information, try '--help'.
dpkg: error processing package grub-pc (--configure):
installed grub-pc package post-installation script subprocess returned error exit status 1
Setting up apparmor (4.1.0~beta5-0ubuntu9) ...
+ . /usr/share/debconf/confmodule
+ [ ! ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [ ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/apparmor.postinst configure 4.1.0~beta5-0ubuntu6
+ . /usr/share/debconf/confmodule
+ [ ! 1 ]
+ [ -z ]
+ exec
+ [ ]
+ exec
+ DEBCONF_REDIR=1
+ export DEBCONF_REDIR
+ . /lib/apparmor/rc.apparmor.functions
+ PARSER=/sbin/apparmor_parser
+ PARSER_OPTS=--write-cache
+ [ no = yes ]
+ [ n = y ]
+ [ -d /etc/apparmor.d ]
+ PROFILE_DIRS=/etc/apparmor.d
+ ADDITIONAL_PROFILE_DIR=
+ [ -n ]
+ AA_STATUS=/usr/sbin/aa-status
+ SECURITYFS=/sys/kernel/security
+ SFS_MOUNTPOINT=/sys/kernel/security/apparmor
+ STATUS=0
+ dpkg --compare-versions 4.1.0~beta5-0ubuntu6 lt-nl 2.13-7
+ dpkg --compare-versions 4.1.0~beta5-0ubuntu6 lt-nl 2.13-7
+ dpkg --compare-versions 4.1.0~beta5-0ubuntu6 lt-nl 2.5~pre+bzr1362-0ubuntu2
+ db_get apparmor/homedirs
+ _db_cmd GET apparmor/homedirs
+ _db_internal_IFS=
+ IFS=
+ printf %s\n GET apparmor/homedirs
+ IFS=
+ read -r _db_internal_line
+ IFS=
+ RET=
+ return 0
+ mktemp
+ tmp=/tmp/tmp.wrf0fgLfRW
+ cat
+ [ -n ]
+ cat
+ mkdir -p /etc/apparmor.d/tunables/home.d
+ mv -Z -f /tmp/tmp.wrf0fgLfRW /etc/apparmor.d/tunables/home.d/ubuntu
error: unexpected argument '-Z' found
tip: to pass '-Z' as a value, use '-- -Z'
Usage: mv [OPTION]... [-T] SOURCE DEST
mv [OPTION]... SOURCE... DIRECTORY
mv [OPTION]... -t DIRECTORY SOURCE...
For more information, try '--help'.
dpkg: error processing package apparmor (--configure):
installed apparmor package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of grub-efi-amd64-signed:
grub-efi-amd64-signed depends on grub-efi-amd64 | grub-pc; however:
Package grub-efi-amd64 is not installed.
Package grub-pc is not configured yet.
dpkg: error processing package grub-efi-amd64-signed (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
grub-pc
apparmor
grub-efi-amd64-signed
Disabling rust-coreutils removed that error.
1 Like
It is Selinux support missing and what Jon mentioned in comment #0
it is being worked on
2 Likes
oh! didn’t know that was related to that.
I thought Ubuntu doesn’t have Selinux?
Does Using Rust Coreutils Mean Leaving GNU? Will Ubuntu no longer be GNU/Linux?
3 Likes
Rust itself is dual-licensed under the Apache v2 and MIT licenses:
https://www.rust-lang.org/policies/licenses
This allows Rust to be used practically anywhere to include major corporations. Many corporations will not allow their software engineering teams to use GPL-licensed components when building software due to the copyleft requirement to license and release any linked software under the GPL. They view this as a potential liability and a potential loss of trade secrets / proprietary information.
This means that in corporate environments, software that is licensed as GPL-only ends up having the opposite of the intended effect–it encourages corporations to NOT use or contribute to the GPL-licensed software except under very controlled circumstances, for example, Linux kernel contributions. This means that the GPL-licensed software gets used as is (primarily for infrastructure and tooling), but that no contributions are made back to the community (not even bug fixes). I say this as having worked as a software developer for a major corporation based on what the corporate legal team allowed in terms of allow licenses of third-party software. How many corporations use GPL-licensed software to power datacenters and clouds but do not contribute back due to legal concerns?
I have mixed feelings about the difference in licenses.
I feel that software written using Rust will slowly displace most software written in C and C++ because of the advantages of Rust in memory safety and ecosystem ease of use while providing comparable performance. I have rewritten problematic software components original written in C and C++ to Rust and seen remarkable benefits. The rewritten projects have fewer bugs, are easier to maintain, and are equally capable and performant.
I think the use of uutils in Ubuntu is the right technical decision and that it will provide safer, more capable versions of coreutils, diffutils, findutils, etc. over the long term due to differences in community size and activity. There is simply more interest and excitement in contributing to uutils versus the original GNU projects. The more permissive MIT license could also encourage corporate users to contribute back simply because it requires more effort to maintain an internal fork.
The concerns about corporation appropriation are valid and I understand the concerns, but as I stated above GPL-licensed software gets used in corporate environments anyway, but without any of the intended benefits of the GPL coming back to the projects. If, at some future time the corporate takeover fears are realized, the project could always be forked and placed under a GPL license as described here: https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html#x1-40002.2
Rust itself is dual-licensed under the Apache v2 and MIT licenses:
Yes, as it is a “library”, not a “binary”. It’s long been held that licensing libraries under GPL creates more problems than it solves, as it stops people from using those libraries and creates the viral spread of the GPL that most corporations fear, and actually ends up being a net negative. uutils distributes binaries, which is where the GPL is actually the most useful.
I share your feelings about Rust in general, and think that all C/C++ code should be replaced by memory safe alternatives (Rust or not) within the next 20 years. I think Microsoft should be working to sunset C#, and replace it with a rust derivative and rebuild Windows in it (as monolithic as a task as that is). There is a real opportunity here to not just make software memory safe, but also to fix the mistakes and remove esoteria of the past.
I also agree that this is the right “technical” descision for performance and memory saftey. However, it is not the right decision.
This means that in corporate environments, software that is licensed as GPL-only ends up having the opposite of the intended effect–it encourages corporations to NOT use or contribute to the GPL-licensed software except under very controlled circumstances, for example, Linux kernel contributions.
And with uu-utils, they get a free pass to do this anyway with nothing given back to the community. There is no positive here. Additionally, the MIT License does not include an explicit contributor’s patent license. This means users of MIT-licensed software must be aware of any potential patent issues separately. This means that someone could contribute code to uu-utils, patent it, and use that to prevent a GPL fork.
If, at some future time the corporate takeover fears are realized, the project could always be forked and placed under a GPL license
If Canonical stepped up as a community leader and did this, I would be over joyed. As it stands now, without a GPL, I don’t think anyone should support this adoption. It will result in numerous downsides, and no upsides over Canonical forking it under the GPL and doing the exact thing they are doing now. That path has its own downsides, but despite the short term drama it would create, would be the right thing to do for the future of computing.
We shouldn’t repeat the mistakes of the past 30 years later. All of this has been debated and settled before, the only difference is new people are saying the same words that were said before, and making the wrong choice.
The broader debate over GPL licensing - especially for libraries - is well-worn, and it’s precisely why the GCC Runtime Library Exception and the syscall exception exist. That’s an oversimplification, sure, but more than sufficient for the topic at hand. No need to bike-shed.
The point at issue here is the binaries distributed by uutils, not libraries. For end-user tools, GPL licensing simply limits unshared modification. It imposes no meaningful negative constraint on Linux’s future - legally or practically. Any usecase where a corporation would fork and not contribute is a negative one.
That said, I acknowledge that uucore could technically avoid GPL constraints under similar reasoning. I’d accept that. But I still think it should remain GPL-licensed. If libraries depending on uucore are themselves required to be GPL, that’s not a flaw - that’s working as intended. However, I also would not debate any team that decided to keep uucore as MIT or similar.
Started playing with this now in my Plucky Puffin VMs, after heard about it live this evening in Linux Unplugged #607 and reading about it on Phoronix
1 Like