Hacker News Reader

Comment by rolandog | Hacker News Reader

I have a suspicion it's about the license, like this commenter [0] did a year ago.

[0]: https://news.ycombinator.com/item?id=38853429

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.

If it was only for that, they could use/improve busybox, which has the same license as the kernel (GPLv2).

Perhaps it is also so they can be used in closed source systems (I have uutils installed on my Windows system which works nicely).

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.

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 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.

How is this not allowed under GPLv3?

Search for "Tivoization" and the GPLv3

Isn't preventing "tivoization" the whole point of the GPLv3?

GPv2 does that too: https://news.ycombinator.com/item?id=45691997

There are F500 companies shipping Ubuntu Core on devices that will only permit signed firmware, so I'm not sure your assessment is correct.

https://buildings.honeywell.com/au/en/products/by-category/b...

As long as nobody sues them everything is fine

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?

[0]: https://ubuntu.com/pro/

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?

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?

Linux is GPLv2, there is no tivoization protection. In fact most tivoized devices run Linux.

The Software Freedom Conservancy disagrees, and they are the main enforcers of the GPL these days, especially for Linux.

https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...

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.

They'll be doing that I expect, they are starting by making it possible for anyone to sue over GPL compliance, not just the authors.

https://sfconservancy.org/copyleft-compliance/vizio.html

I doubt GPL version 3 is the motivation here.

https://packages.ubuntu.com/plucky/rust-coreutils

The dependencies of rust-coreutils list libgcc-s1, which is GPL version 3.

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).

The authors have specifically said that it’s not. They just chose Rust community licensing norms, they don’t really care about licenses.

That might be Canonical’s motive though.

That's fair!

Seriously, how on earth are you coming up with this? Time and again they debunk those silly claims but people just keep bringing this up on and on. Is it some sort of conspiracy theory?

It could be a conspiracy on the part of Canonical, sure. People have hidden motives all the time. Sometimes you have to deduce their motives from their actions, while ignoring their words.

I don't think there’s any serious evidence of it being true though. All we can see right now is that there are a surprising number of MIT-licensed packages replacing GPL-licensed packages. It could be a coincidence.

Some of us in the Enterprise and Governmental sector try hard to avoid software with viral licenses.

We sigh in relief every time we see a software that we rely upon changes/adds non-viral license such as MIT, Apache, MPL, BSD, and so on.

At best this just makes them a patsy, which isn't actually better; but it, also becomes pretty clear if you pay more attention and dig into this (watch some of their interviews, etc.) that they actually DO care about the license, and are splitting hairs on what that means: if they don't care, but they have users who do that will be disappointed if they went in a different direction, then they not only do care, but have chosen to actively align with those specific users. But, regardless, again, and most importantly: this is about why they have a niche and why Canonical is pushing this, and if you try to just right software in such an environment and actively truly actually don't care about the license and just YOLO it, then that level of cavalier negligence cannot be rewarded with immunity to guilt or culpability in the outcomes.

"Licensing norms"? Are people really choosing software licenses without considering the implications just because it's a "norm"?

This is gonna cause a lot of disappointment down the road.

If most of an ecosystem chooses a specific license (dual licensed in Rust's case), the simplest thing to do is choose the same license as everyone else.

This may be reasonable if you're writing a library but not for applications.

Regardless of what others do, the best thing to do is to choose the best license for one’s own software. One which preserves the freedom of one’s users and the openness of one’s code.

Sadly people don’t always do what’s best. We sometimes do what other people are doing on the theory that maybe someone else has thought it through and already decided that it _is_ the best thing to do. It’s not perfect, but then heuristics rarely are. But it’s cheap to implement.

Considering how often MIT is chosen over the slightly simpler ISC version... yeah.

In the end, a lot of people are willing to write open source just for the sake of having it as it scratches their own need and isn't otherwise monetizable or they just think it should exist. I would never even consider touching a GPLv3 licensed UI library component, for example.

It's not always the most appropriate license and if a developer wants to use a permissive license, they are allowed to. This isn't an authoritarian, communist dictatorship, at least it isn't where I live and to my dying breath won't be.

Of course it's allowed. People can do whatever they want. If they think it over, consider the implications of what they are doing and decide that this is what they want, then by all means.

Choosing licenses due to peer pressure is completely stupid though. If you're not sure, you can just not pick a license at all. Copyright 2025 all rights reserved. If you must pick a license just because, then the reasonable choice is the strongest copyleft license available, simply because it maximizes leverage. The less you give away, the more conditions, the more leverage. It's that simple.

That people are actually feeling "pressure" to pick permissive licenses leads me to conclude this is a psyop. It's a wealth transfer, from well meaning developers straight into the pockets of corporations. It's being actively normalized so that people choose it "by default" without thinking. Yeah, just give it all away! Who cares, right?

I urge people to think about what they are doing.

I made some open source software myself and my desire is to see my code used as widely as possible.

So the ONLY reasonable choice for me is to release my code with a non-viral license. A copyleft license is TOTALLY UNREASONABLE for me because it limits the reach of my software.

(My license of choice is MPL-2.0)

Have you thought about it? If you have given it serious thought and decided that this is what you want, then by all means, go ahead.

The problem is that people choose permissive licenses to be "nice" when the truth is they have tons of unwritten rules and hidden assumptions. Magical thinking like "if I publish this open source software then it will come back to me in some way, maybe a job, maybe a sponsorship." No such deal exists. Then they wake up one day with corporations making billions off of their software while they're not making even one cent, and they suddenly have a very public meltdown where they bitterly regret their decisions. I've seen it happen, even with copyleft licenses.

When I publish something under MIT/ISC, it's generally, I wrote this to solve a problem/need, if anyone else finds it useful, cool. Use it for whatever you like.

If I'm writing something I intend or might intend to monetize later or otherwise don't want to have privatized, I'll probably reach for GPLv3, AGPL or a different license. The less "whole" a thing is, the more likely I'm going to use a more permissive license than not. Libraries or snippets of code are almost always going to be permissive at least from me. This includes relatively simple CLI utils.

I like how the first comment is asking "is anyone actually going to switch to this version?" and here we are with one of the major Linux distributions using it already, and already managed to ship a bug via it.

Brave of them to ship a Rust port of sudo as well.

It looks like we have three major open source imementations:

- GNU coreutils (GPLv3)

- uutils coreutils (MIT)

- busybox (GPLv2)

There's the BSD coreutils too.

Which is the first and canonical one. GNU added a lot of bells and whistles, and esp. nonsense like --help and --version support for everything, like true and false.

Toybox is the 4th one

https://en.wikipedia.org/wiki/Toybox

Agreed. Proprietary tools could then rely on those coreutils without any license fears.

I've had the same suspicion since I read about it the first time.

Yeah, if this is not upstreamed eventually, it will have to be rewritten again.

Is it not just yet another Rust rewrite?

Reply on news.ycombinator.com