Agreed. Since GNU Coreutils is GPLv3 but uutils is MIT, my guess is eventually Canonical will start using "works like the GNU software except you don't have to comply with GPLv3" as a selling point for Ubuntu Core (their IoT focused distro). This would let them sell to companies who want to only permit signed firmware images to run on their devices, which isn't allowed under GPLv3.
Depending on the product, this might be OK! If you've ever had cause to closely read the GPLv3, the anti-tivoisation clause for some reason is only really aimed at "User products" (defined as "(1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling"). This one looks like it's a potential grey area, since it's not obvious if it's intended for buildings that anyone would live in.
I worked on an embedded product that was leased to customers (not sold). The system included GPLv3 portions (e.g. bash 5.x) but they concluded that we did not need to offer source code to their cuatomers.
The reasoning was that the users didn’t own the device. While I personally believe this is not consistent with recent interpretations of the license by the courts, I think they concluded that it was worth the risk of a customer suing to get the source code, as the company could then pull the hardware and leave that customer high and dry. It is unlikely any of their users a would risk that outcome.
Take a look at their customer testimonials [0] and ask yourself if they have recently made anticompetitive or user-hostile moves. Now, ask yourself: do you think they like being beholden to a license that makes it harder for them to keep their monopolies?
Edited to add: it would be cool if, instead of the top-most wealth-concentrators F[500:], there was an index of the top-most wealth-spreaders F[:500]. What would that look like? A list of cooperatives?
If that's really the case, I wish they would just come out and say it and spare the rest of us the burden of trying to debate such a decision on its technical merits. (Of course, I am aware that they owe me nothing here.)
Assuming this theory is true then, what other GPLv3-licensed "core" software in the distro could be next on their list?
This isn't anything specific to uutils. When you build a Rust program that links with glibc, it needs to use libgcc to do the stack unwinding. If you look at other packaged Rust programs on Ubuntu, they all depend on libgcc for this reason. For example, Eza https://packages.ubuntu.com/plucky/eza and Ripgrep https://packages.ubuntu.com/plucky/ripgrep . If Ubuntu moves to some safe, permissively licensed glibc replacement in the future, this requirement will drop off all their Rust packages. I'm not saying this uutils change alone will let Ubuntu get out of GPLv3 compliance, I'm saying they likely view GPLv3 software in the base install as undesirable due to their IoT customers and will replace it with a permissively licensed alternative given the opportunity.
The dependency of glibc on the unwinder (for backtrace, pthread_exit and pthread_cancel) is a glibc packaging problem. You need to plan for replacing glibc anyway because its licensing could switch to (L)GPLv3+ (including for existing stable release branches).
However, it would be a fairly straightforward project to replace the unwinder used directly by Rust binaries with the one from libunwind. Given that this hasn't happened, I'd be surprised if Canonical is actually investing into a migration. Of course there are much bigger tasks for avoiding GPLv3 software, such as porting the distribution (including LLVM itself and its users) from libstdc++ (GCC's C++ standard library that requires GCC to build, but provides support for Clang as well) to libc++ (LLVM's C++ standard library).
In this hypothetical situation are Canonical also replacing the GPL Linux kernel? If they’re not replacing the Kernel, how does anything change for the end user?
Basically every IOT/router/phone/whatever which is advanced enough runs Linux and almost every one of them enforces firmware signing. They'd have to fight the whole world at this point.
Busybox is frankly a horrible user experience, and will never be a good one. Its niche is to be as small as possible, as a single static executable, while providing most tools you need to get the job done in an embedded system. Bells and whistles like a shell that's nice to use, or a vi implementation with working undo/redo, or extensive built-in documentation in the form of --help output, are non-features which would make busybox worse for its primary use case.
