GNU Core Utilities 9.12 released [LWN.net]

Pádraig Brady has announced GNU Core Utilities (coreutils) version 9.12. "There have been 288 commits by 16 people in the 21 weeks since 9.11". New features include an -A option for uname which labels all output, as well as adding awareness of the failfs and nullfs filesystem types to stat and tail.

There are many bug fixes in this release as well, including one for a bug "present in 'the beginning'" that caused some utilities to fail when traversing hierarchies if files are being removed in parallel.

to post comments

The story behind the headlines...

Posted Sep 14, 2026 22:38 UTC (Mon) by NightMonkey (subscriber, #23051) [Link] (6 responses)

I wish there were more stories about how these core utilities are maintained and about who maintains them. I feel there's likely a very interesting story there about open source, free software and the spirit of volunteering (or getting paid to maintain core components of F/OSS software, if they are paid).

Not glamorous work, but so necessary! :)

The story behind the headlines...

Posted Sep 14, 2026 23:59 UTC (Mon) by pixelbeat (guest, #7440) [Link] (5 responses)

No payment :)

We do keep some general notes on the dev process like testing, multi-byte support plan, rejected feature requests, and gotchas.

One thing we focus on is good documentation. For example there is an online manual about the size of a standard book, which the --help and man pages link into at the appropriate place. This works on the terminal but you can also see this for example in the arch distro ls man page, where clicking on a particular option, will take you to the appropriate part of the full manual.

The story behind the headlines...

Posted Sep 15, 2026 0:34 UTC (Tue) by collinfunk (subscriber, #169873) [Link] (3 responses)

+1 on the lack of payment. I don't think anyone else working on GNU coreutils does so as part of their employment either. I suppose it looks good on my resume, which is payment enough. :)

Also, I second the suggestion of those articles. If you are interested in the history of coreutils in particular, you may enjoy a video by David MacKenzie [1]. You may recognize the name from various --help outputs or man pages. If not, this should help give you an idea:

$ git grep -Fc 'David MacKenzie' AUTHORS
AUTHORS:54
$ wc -l AUTHORS
115 AUTHORS

[1] https://www.youtube.com/watch?v=D7vfI-WSP8Q

The story behind the headlines...

Posted Sep 15, 2026 20:43 UTC (Tue) by jmalcolm (subscriber, #8876) [Link] (2 responses)

I was all set to refute you and did some last minute research to get my facts straight. Turns out that, although Red Hat employs people that work on the GNU coreutils, Red Hat does not fund coreutils work directly. That is, the Red Hat employees that work on coreutils are paid to work on other projects and not paid to do coreutils work.

This was a surprise to me as Red Hat does fund a great deal of the rest of the GNU project (eg. GCC, binutils, glibc, autotools, etc).

The story behind the headlines...

Posted Sep 16, 2026 0:13 UTC (Wed) by himi (subscriber, #340) [Link] (1 responses)

The funded work on GCC and the various related tooling is probably a hangover from when there was a significant amount of contract work in supporting and developing the compiler toolchains - for RH that's probably subsumed into the general stream of Enterprise Linux support these days, but keeping people on the books as explicit "GCC developers" likely helps with the marketing of that support (as well as being a sensible thing to do, of course).

Things like coreutils aren't quite so glamorous, I guess . . .

The story behind the headlines...

Posted Sep 17, 2026 15:36 UTC (Thu) by anton (subscriber, #25547) [Link]

I get the impression that paying customers of Linux distributors ask for various compiler things, and the people at Red Hat and Suse that work on compilers do it such that these companies can satisfy these customer support issues. When compiler maintainers talk about "relevant code" that is affected (or not) by an optimization, I think not just of widely-known benchmarks, but also of kernels supplied by these customers that represent performance-critical parts of their applications.

Similarly, I have talked to people from Oracle who work on GraalVM, and they often seem to have some customer request on their mind when they talk about an optimization.

And likewise, commercial Forth compiler vendors usually do things because a customer requests them, and they usually do not do things that no customer asks for.

I guess that Red Hat gets few customer requests about core utils, so Red Hat does not pay anyone to maintain them.

The story behind the headlines...

Posted Sep 15, 2026 16:12 UTC (Tue) by q3cpma (subscriber, #120859) [Link]

Ah, thanks a lot of that multi-byte page! I've been waiting for multi-byte tr for years (using sed's y command for some simple cases instead) and it's good to see that collective demand being acknowledged.

GNU coreutils

Posted Sep 15, 2026 14:56 UTC (Tue) by ballombe (subscriber, #9523) [Link] (87 responses)

I must say I found pretty troubling that Microsoft announced a "Coreutils for Windows" that is actually uutils.
<https://learn.microsoft.com/en-us/windows/core-utils/over...>

GNU coreutils

Posted Sep 15, 2026 18:40 UTC (Tue) by dvdeug (guest, #10998) [Link] (86 responses)

Why? GNU coreutils is GNU coreutils. coreutils is too basic a name for one package to claim exclusive control over, and it's probably better that it works as a name for the basic package of POSIX utilities.

GNU coreutils

Posted Sep 15, 2026 19:44 UTC (Tue) by gus3 (guest, #61103) [Link] (83 responses)

Why not "Core Utilities for Windows"?

I think that "coreutils" could be yet another trick-move by M$. And they have a history of doing that (viz. the Halloween documents).

GNU coreutils

Posted Sep 15, 2026 20:11 UTC (Tue) by stockerta (subscriber, #165517) [Link] (1 responses)

Your paranoia is showing, calm the hell down mate.

GNU coreutils

Posted Sep 15, 2026 23:30 UTC (Tue) by mcon147 (subscriber, #56569) [Link]

This is microsoft, you really do have to consider their past behavior

GNU coreutils

Posted Sep 15, 2026 20:17 UTC (Tue) by jkingweb (subscriber, #113039) [Link] (75 responses)

Why not "Core Utilities for Windows"?

That has its own possibilities for confusion since they are not core Windows utilities, and they're not written my Microsoft, either.

The software is itself called "uutils coreutils", so I think it's reasonable and not at all nefarious to refer to the suite as simply "coreutils". I'd suggest that if you have a problem with the name it's the uutils people at fault, not Microsoft.

GNU coreutils

Posted Sep 15, 2026 20:25 UTC (Tue) by collinfunk (subscriber, #169873) [Link] (74 responses)

The installer used to have the following checkboxes, which I felt were misleading, given that they aren't GNU programs:

Prefer GNU find over DOS find for ambiguous commands
Prefer GNU sort over DOS sort for ambiguous commands

But after I mentioned it to them, they changed it to the less confusing:

Prefer Coreutils- over DOS-style behavior
Prefer Coreutils- over DOS-style behavior

I find it a bit ambiguous, but it is an improvement, I guess.

GNU coreutils

Posted Sep 16, 2026 16:29 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (73 responses)

This is very weird. Is it a sign of copy-pasting from the GNU coreutils repository? If so, it might signal a derived work, and it might be a sign of license violation. How did that text end up there?

Would you mind sharing some links about this discussion?

GNU coreutils

Posted Sep 16, 2026 19:43 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (70 responses)

While obviously an actual copyright violation would be seriously problematic here, it could just as easily be a case of miscommunication. GNU has been asking people to call this family of operating systems "GNU/Linux" for so long that the resulting internet meme is now stale and tired. Regardless of the merits of that request, it is bound to cause confusion in cases where a Linux kernel and typical Unix-ish userland are both present, but GNU code is absent. Perhaps somebody at Microsoft wrongly believes that "GNU" is the generic term for this type of userland (GNU documentation frequently refers to "the GNU operating system" and so forth).

And to state the obvious just in case: You do not infringe copyright merely by reading GNU's documentation when you are simultaneously working on uutils. Reading GNU's source code would be more of a grey area, but even that does not *automatically* create infringement (under e.g. the Abstraction-FIltration-Comparison test).

GNU coreutils

Posted Sep 16, 2026 20:22 UTC (Wed) by collinfunk (subscriber, #169873) [Link] (69 responses)

The uutils project, at least, copies our test cases, which are under the GPLv3+ license, frustratingly [1]. See the following commit removing GNU coreutils source code in comments [1]. Along with the pull request containing additional minor modifications to copied tests. With commit messages downplaying the copying, of course [2]. This is after I warned them on PRs around 5 times...

[1] https://github.com/uutils/coreutils/commit/a0b63c884c6f9d...
[2] https://github.com/uutils/coreutils/pull/14004

GNU coreutils

Posted Sep 16, 2026 20:43 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (68 responses)

This seems quite bad behavior (I'd say it's a plain violation of the license). Unfortunately, I can confirm that the same maintainer behaved in that same way when dealing with another project they're unrespectfully copying from.

Is the FSF aware of this? Does it have anything to say about this?

From a commit message the PR you linked to in [2]:

> tests: rename and diversify test data to distinguish from GNU originals
>
> Rename test functions that were structurally similar to GNU coreutils GPL tests, and change their test data so the inputs/outputs differ:

lol

This is what kids do at school, when copying from wikipedia and then editing the words so that it doesn't look identical to the eyes of the teacher.

Isn't this itself evidence of stealing copyrighted material?

GNU coreutils

Posted Sep 16, 2026 20:48 UTC (Wed) by mb (subscriber, #50428) [Link] (5 responses)

> Isn't this itself evidence of stealing copyrighted material?

Before the change: Maybe. After the change: No.

Plagiarism

Posted Sep 16, 2026 21:10 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (4 responses)

> > Isn't this itself evidence of stealing copyrighted material?
>
> Before the change: Maybe. After the change: No.

If one does that in a thesis, they'll obviously fail for plagiarism. How is it not plagiarism in this case?

And if it is plagiarism, by what legal mechanism isn't it an infringement of copyright?

Plagiarism

Posted Sep 16, 2026 21:16 UTC (Wed) by mb (subscriber, #50428) [Link]

As far as I understand the changes they deleted the copied parts.
So it's not copied anymore, because the copied parts have been removed.

But a court has to decide at the end.
Feel free to start a case, if you are a copyright holder.

Plagiarism

Posted Sep 16, 2026 22:59 UTC (Wed) by intelfx (subscriber, #130118) [Link] (2 responses)

And if it is plagiarism, by what legal mechanism isn't it an infringement of copyright?

At least one mechanism comes to mind: copyright protects expression, not idea. If it’s the only way one could reasonably write this test, it is not protected. If there is little unique expression in the specific text that was copied, it will enjoy weak protection.

If one does that in a thesis, they'll obviously fail for plagiarism. How is it not plagiarism in this case?

It must be noted that this is software, not a thesis. There is no “plagiarism” here, it does not exist as a wrongdoing.

Plagiarism

Posted Sep 16, 2026 23:22 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (1 responses)

> > If one does that in a thesis, they'll obviously fail for plagiarism. How is it not plagiarism in this case?

> It must be noted that this is software, not a thesis. There is no “plagiarism” here, it does not exist as a wrongdoing.

Plagiarism involves a derived work without acknowledging the derivation. In the case of copyright and licensing, if there's a derived work, the license must be respected, and otherwise it's a violation of the license. If the derivation is not acknowledged, it's a clear violation.

Plagiarism

Posted Sep 17, 2026 2:28 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

Plagiarism is an academic term. It refers to the use of ideas without giving appropriate credit or attribution for those ideas. It is a wrong against your readers, because it prevents them from understanding the state of the literature, and against the prior work, because it denies them credit duly earned. The concern is with properly documenting the sources of your ideas and facts, so attribution is enough to avoid plagiarism.

"Derivative work" (often misstated as "derived work") is a term from copyright law. Its precise definition depends on jurisdiction, but nearly all of the time, it requires more than merely using an idea. Some of the concrete expression from the original must have been copied into the derivative. This does not necessarily mean word-for-word copying. You can make a derivative work by, for example, copying the characters or setting from an established work of fiction into your own unofficial (or licensed) sequel, but not by writing a story in a loosely similar setting with a similar genre and characters. The concern is with protecting the author's economic interest in the original, so attribution is not (generally) enough, and you must comply with the author or rightsholder's licensing terms.

Conflation of these concepts helps nobody, and just leads to confusion.

GNU coreutils

Posted Sep 16, 2026 20:59 UTC (Wed) by collinfunk (subscriber, #169873) [Link] (2 responses)

The FSF is aware of those cases, and I will leave any statement or lack thereof to them.

I will say that, on a personal level, seeing some of the tests I have written, copied, and pasted, with detailed comments left intact and slightly changed solely to satisfy a different interpreter/compiler, is frustrating. The fact that Canonical is paying for this work while the VP of Engineering, responsible for the decision, downplays all licensing concerns [1] simply adds insult to injury.

[1] https://www.youtube.com/live/Doqwh1b4QyA?si=h1FzEtH13EewIQuc

Canonical seems to support uutils infringing copyright

Posted Sep 16, 2026 21:14 UTC (Wed) by alx.manpages (subscriber, #145117) [Link]

> The FSF is aware of those cases, and I will leave any statement or lack thereof to them.

Thanks for confirming! Let's see what FSF has to say about it, when/if they do (I hope they'll do).

> I will say that, on a personal level, seeing some of the tests I have written, copied, and pasted, with detailed comments left intact and slightly changed solely to satisfy a different interpreter/compiler, is frustrating. The fact that Canonical is paying for this work while the VP of Engineering, responsible for the decision, downplays all licensing concerns [1] simply adds insult to injury.

Indeed.

GNU coreutils

Posted Sep 17, 2026 0:27 UTC (Thu) by moltonel (subscriber, #45207) [Link]

> seeing some of the tests I have written, copied, and pasted, with detailed comments left intact and slightly changed solely to satisfy a different interpreter/compiler, is frustrating. The fact that Canonical is paying for this work while the VP of Engineering, responsible for the decision, downplays all licensing concerns [1] simply adds insult to injury.

Which part of that interview did you find insulting ? You make it sound like they downplayed infringement concerns, but AFAICT the only concerns discussed there are from the "Ubuntu is replacing GPL with MIT for nefarious reasons" line of thought, which frankly seem fair to downplay.

Copyright infringement is a more serious issue, and your frustration is valid. The uutils devs feel they have solved the issue. You can disagree with their conclusion, but you shouldn't deny their good intentions.

GNU coreutils

Posted Sep 16, 2026 22:11 UTC (Wed) by Wol (subscriber, #4433) [Link] (58 responses)

> This seems quite bad behavior (I'd say it's a plain violation of the license). Unfortunately, I can confirm that the same maintainer behaved in that same way when dealing with another project they're unrespectfully copying from.

If these are plain-text scripts, then I don't see how it can be a licence violation. If it's binaries then yes it could be.

But if you copy stuff AS SOURCE, it's pretty impossible to breach the GPL. All you have to do is say "this source is GPL3" and that's it. Compliance done!

That's why I get upset about people moaning "why isn't this whatever strong copyleft GPL'd rather than weak copyeft MIT or BSD?". As soon as you get into the realm of scripting and interpreted languages, as far as the licence goes GPL and MIT are near as dammit indistinguishable.

Cheers,
Wol

MIT vs GPL for scripts (was GNU coreutils)

Posted Sep 16, 2026 22:58 UTC (Wed) by dskoll (subscriber, #1630) [Link]

Not necessarily. People can and sometimes do release obfuscated versions of scripts that the interpreter can handle without any problems, but might as well be object code as far as a human is concerned. GPL can prevent that; MIT cannot.

GNU coreutils

Posted Sep 16, 2026 23:13 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (56 responses)

> But if you copy stuff AS SOURCE, it's pretty impossible to breach the GPL. All you have to do is say "this source is GPL3" and that's it. Compliance done!

Yet, uutils hasn't claimed that "this source is GPL3". They'd have to claim it to comply. It's easy to comply, but they haven't done that easy thing at all.

I don't know if Collin is a copyright holder, or if it's just the FSF. Depending on that, and whether they comply voluntarily or not after the requests to comply, their license might be terminated, possibly permanently.

GNU coreutils

Posted Sep 17, 2026 15:16 UTC (Thu) by moltonel (subscriber, #45207) [Link] (55 responses)

They have complied, both in response to comments and proactively, by deleting or modifying the relevant lines and by strengthening their documentation and process. I'd be surprised if the FSF found the current state problematic enough to demand action from Uutils Coreutils, but I'm sure Uutils would do additional deletes/rewrites if the demand came.

It's worth describing was was originally taken from GNU here: some comments, and a small minority of Uutils test cases that reused the same arbitrary values as the GNU ones. The code itself is both in a different language and the boring "launch program with some args and check the output" that copyright law would likely exclude as "obvious and/or necessary". So although changing a test to check if "8 + 5 = 13" instead of "5 + 6 = 11" seems ridiculous, the argument is that those constant were the only shred of actually GPL-copyrightable expression, and that this kind of change makes the file clean.

Collin asserts that changes like these are not enough, and it is a real possibility but the case is not clear-cut. I haven't seen any statement from the FSF or GNU Coreutils community, but most interactions I've seen seemed mutually beneficial and in good terms, with antagonistic opinions being the minority.

GNU coreutils

Posted Sep 17, 2026 16:48 UTC (Thu) by alx.manpages (subscriber, #145117) [Link] (54 responses)

> So although changing a test to check if "8 + 5 = 13" instead of "5 + 6 = 11" seems ridiculous,

I don't see how that is not a derivation. If one has copied literally the original expression and modified it minimally to not look like the original while still being fundamentally the same, it looks like fraud.

17 U.S.C. § 101:
"A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted."

If those changes are enough to not be "based upon", copyright law is really a joke, and the English text that specifies the law is nonsense. (It could very well be.)

> The code itself is both in a different language

That shouldn't matter. Translation is among the things that cause a derivative work, according to the above. What would matter is whether it was derived or not from the original code or was written from scratch, and whether the original code taken for that derivation was copyrightable or not.

GNU coreutils

Posted Sep 17, 2026 20:12 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

You're testing addition. How large of a difference would it take to not be derivative? It's not like the syntax being tested (presumably) really lets one be creative in more than two of the blanks in _ + _ = _. Perhaps double it if the syntax allows = before the +.

GNU coreutils

Posted Sep 17, 2026 20:24 UTC (Thu) by mb (subscriber, #50428) [Link] (37 responses)

> If one has copied literally the original expression and modified it minimally

In "8 + 5 = 13" vs. "5 + 6 = 11" each of the three operands of the addition is changed.
How would you change an addition even more?
By your reasoning every three operand addition is a derivative of GNU coreutils.
Preschools are infringing GNU Copyright!

GNU coreutils

Posted Sep 17, 2026 20:43 UTC (Thu) by alx.manpages (subscriber, #145117) [Link] (32 responses)

> By your reasoning

My reasoning is based on 'derivative work' being 'based upon' existing work. You seem to have misunderstood my reasoning deeply. Nothing in my reasoning says anything about similarity of two works, and indeed implicitly reasons against similarity.

> every three operand addition is a derivative of GNU coreutils.

No, because one doesn't copy GNU coreutils code to later modify it. One writes the additions from scratch.

If one decides to base their additions on coreutils' code, then one indeed is basing their code on coreutils' code. It's not the end result, but the process.

If you have one work with has been based upon some pre-existing work, it's derived, regardless of how much you've changed individual tokens to make it look differently without substantially changing it.

If you invent a spaceship that is identical to an existing spaceship that exists in a different galaxy --and thus you have not possibly known about it--, you've legitimately invented it without being derived.

If you take a wooden ship, and replace all of its wood foils by new ones, you haven't invented a new ship. You've derived it from the existing one.

GNU coreutils

Posted Sep 17, 2026 21:01 UTC (Thu) by mb (subscriber, #50428) [Link]

>If you have one work with has been based upon some pre-existing work, it's derived

Ok. Therefore, everything in the world is a derived work of stone age knowledge. Therefore, everything is related and must be the same license.

GNU coreutils

Posted Sep 17, 2026 22:09 UTC (Thu) by intelfx (subscriber, #130118) [Link] (30 responses)

My reasoning is based on 'derivative work' being 'based upon' existing work. You seem to have misunderstood my reasoning deeply. Nothing in my reasoning says anything about similarity of two works, and indeed implicitly reasons against similarity.

Then, unfortunately, your reasoning is contrary to how the copyright laws (and courts) actually work, at least in the US.

Under copyright law (which is what gives licenses like the GPL its power in the first place), a work (or a portion of it) must have both substantial similarity (under the relevant legal tests/standards) with the allegedly derivative work and 2) sufficient unique expressivity ("protected expression") to be protected at all. Both must be proven, or else there is no infringement, regardless of how one might feel about the situation.

This is the same debate as we've had just a few weeks ago about LLMs, and, unfortunately, the same misconceptions abound.

GNU coreutils

Posted Sep 17, 2026 22:24 UTC (Thu) by alx.manpages (subscriber, #145117) [Link] (29 responses)

Indeed, copyright law (like other laws) requires some thresholds.

It's like stealing physical property. If one steals less than 400 EUR, in my country, there's no crime. That's not because they haven't stolen, but because they didn't pass the threshold. Some wrongdoers are aware of this, and repeatedly steal quantities below the threshold. Not much happens to them.

This is essentially what uutils seems to be doing. It seems to be testing the limits of what (code) they can steal without having legal problems. I'm not sure about whether what they've stolen has passed thresholds or not (I hope the FSF, which has lawyers and other resources for that, does that). I'm just saying they've stolen code.

GNU coreutils

Posted Sep 18, 2026 10:40 UTC (Fri) by moltonel (subscriber, #45207) [Link] (28 responses)

> [Uutils] seems to be testing the limits of what (code) they can steal without having legal problems.

That's a really unfair accusation. They've always had a clear stance against copying from GNU, and have strengthened it where they could. They have no reason to get anywhere close to infringement (even before considering legal problems, no lawyer was involved in any of this), and when one was spotted they just made a straightforward fix. Disliking their handling of the issue is one thing, assuming bad intent is another.

GNU coreutils

Posted Sep 18, 2026 14:01 UTC (Fri) by collinfunk (subscriber, #169873) [Link] (27 responses)

> That's a really unfair accusation. They've always had a clear stance against copying from GNU

Which has not been followed so far. See the latest release notes [1]:

Also, some contributions had carried comments and code over from GNU coreutils, against our own rule
that uutils is an original implementation. We reviewed the tree and rewrote what we found, in comments and in the few
functions that followed the C too closely; no behaviour change. The GNU coreutils maintainers have been notified.

Of course, it downplays the actual copying.

[1] https://github.com/uutils/coreutils/releases/tag/0.12.0

GPL antipathy (was GNU coreutils)

Posted Sep 18, 2026 14:13 UTC (Fri) by dskoll (subscriber, #1630) [Link] (26 responses)

All the uutils developers had to do was to release their code under the GPL and there would be no controversy whatsoever.

I don't understand the antipathy towards the GPL, especially from a project heavily sponsored by Canonical which has made its fortune largely on the back of GPL'd software.

GPL antipathy (was GNU coreutils)

Posted Sep 18, 2026 14:27 UTC (Fri) by collinfunk (subscriber, #169873) [Link] (25 responses)

The project's public position is that they do not care about licensing at all, and they simply inherited the project's existing MIT license. My understanding is that they inherited the project before anything besides coreutils existed under the uutils umbrella.

However, you can notice from their website that 13/14 of the projects they have rewritten, in their words, are GNU projects or under the GPL [1]. The exception to this is shadow-utils. Unfortunately, this project is totally vibe coded [2]. And the README claims that shadow-utils is both a GNU project [3] and GPL-licensed [4]. The actual shadow-utils project is neither a GNU project nor GPL-licensed.

14/14 makes it difficult to believe it is a coincidence that they are relicensing projects. When they say it is not a goal of the project, it is difficult to feel that they are not lying. What purposes they have for hiding their intentions, I can only guess.

[1] https://uutils.org/
[2] https://github.com/uutils/coreutils/issues/11828#issuecom...
[3] https://github.com/uutils/shadow/blob/a116e9fa0fd48efe403...
[4] https://github.com/uutils/shadow/blob/a116e9fa0fd48efe403...

GPL antipathy (was GNU coreutils)

Posted Sep 18, 2026 17:22 UTC (Fri) by moltonel (subscriber, #45207) [Link] (24 responses)

> they do not care about licensing at all

Just to be clear (because your formulation made me jump), that's not caring as in "the specific FOSS license doesn't matter much fort this project, MIT is a common default, there's no anti-GPL sentiment going on", not "we don't bother respecting licenses". This "not caring" stance is actually pretty common and unsurprising, yet uutils constantly have to justify themselves, some people can't accept the boring answer.

> Unfortunately, this project is totally vibe coded [2]. And the README claims that shadow-utils is both a GNU project [3] and GPL-licensed [4]. The actual shadow-utils project is neither a GNU project nor GPL-licensed.

Ha, good catch, that's a funny one. I guess LLMs think all *nix tool are GNU :p All I can conclude from this is that I won't put these suid binaries on my system anytime soon. Maybe joining uutils will help that project mature.

https://github.com/uutils/shadow/issues/320

> 14/14 makes it difficult to believe it is a coincidence that they are relicensing projects. When they say it is not a goal of the project, it is difficult to feel that they are not lying. What purposes they have for hiding their intentions, I can only guess.

And there we are, with textbook conspiracy theories.

GPL antipathy (was GNU coreutils)

Posted Sep 18, 2026 17:35 UTC (Fri) by collinfunk (subscriber, #169873) [Link] (5 responses)

>> 14/14 makes it difficult to believe it is a coincidence that they are relicensing projects. When they say it is not a goal of the project, it is difficult to feel that they are not lying. What purposes they have for hiding their intentions, I can only guess.
>
> And there we are, with textbook conspiracy theories.

I do not think any reasonable person would read what I said and come to the conclusion that I am a conspiracy theorist.

I suspect you are annoyed with me for opposing your Gentoo PR [1] and are using unnecessary ad hominems as a result.

[1] https://codeberg.org/gentoo/gentoo/pulls/89

GPL antipathy (was GNU coreutils)

Posted Sep 18, 2026 19:43 UTC (Fri) by moltonel (subscriber, #45207) [Link] (4 responses)

> I do not think any reasonable person would read what I said and come to the conclusion that I am a conspiracy theorist.

You literally accused a group of people of lying and hiding their intentions, and redefined their activities as something other than their stated goals, despite the mundane straightforward explanation having been given many times over. I am not concluding anything about you, just about these beliefs and lines of thought.

> I suspect you are annoyed with me for opposing your Gentoo PR [1] and are using unnecessary ad hominems as a result.

What I am annoyed about is recurring attacks on that project that go way past reasonable criticism. I have done my best to respond with patience and balance, taking arguments and examples into consideration, and not dismissing real issues. I am pushing back against the ideas, not their author, this isn't an ad hominem.

GPL antipathy (was GNU coreutils)

Posted Sep 18, 2026 20:54 UTC (Fri) by collinfunk (subscriber, #169873) [Link] (3 responses)

Your first argument was that it didn't matter because the cases that I linked were only test cases [1]. That argument is obviously silly, unless someone mentions a jurisdiction where testing code is exempt from copyright. It also just isn't true.

Your second argument was that upstream takes them seriously, because they have told people not to look at code under the GPL [2]. This is obviously false, as a maintainer told me they would not copy test cases anymore [3]. Only to need another warning later that month [4].

Your third argument is that it is possible to copy code by accident [5]. I personally find it quite difficult to open files in another project, copy-paste them verbatim, and then forget to read the license and comply with it. Perhaps you disagree. I would be hesitant to accept patches from you if so.

Your final argument here is that it is impossible for people to have intentions other than their most publicly stated ones.

[1] https://codeberg.org/gentoo/gentoo/pulls/89#issuecomment-...
[2] https://github.com/uutils/coreutils/pull/13818#issuecomme...
[3] https://github.com/uutils/coreutils/pull/12608#issuecomme...
[4] https://github.com/uutils/coreutils/pull/13194
[5] https://codeberg.org/gentoo/gentoo/pulls/89#issuecomment-...

GPL antipathy (was GNU coreutils)

Posted Sep 19, 2026 7:26 UTC (Sat) by moltonel (subscriber, #45207) [Link]

This systematic twisting of people's arguments makes it impossible to have a reasoned discussion. The silver lining is that the sources are there, so people can check how they correlate with your interpretation.

GPL antipathy (was GNU coreutils)

Posted Sep 19, 2026 9:35 UTC (Sat) by bluca (subscriber, #118303) [Link] (1 responses)

> Your first argument was that it didn't matter because the cases that I linked were only test cases [1]. That argument is obviously silly, unless someone mentions a jurisdiction where testing code is exempt from copyright. It also just isn't true.

Well actually, in _practice_ in most case it effectively doesn't matter. Licenses have teeth because they apply to software distributed to end users (ie, binaries in most cases), which means product builders can be held liable for violations. E.g. your garden variety Linux TV manufactorer is responsible for all the binaries it ships to its customers, so if they violate a license, they can be sued, usually successfully.

Now I don't know much about uutils, and there are certainly exceptions, but I'd say in the majority of cases, you don't really ship unit tests to end users. They are only used by the developers and their internal build systems. And here's the thing about licenses including the GPL: internally I can do whatever the heck I want with your GPL'ed source code. I can modify it without giving you anything back, I can mix it with incompatible licenses, and anything in between, and there's not a single thing you can do about it: if it's all for internal usage that never gets redistributed, never touches an external machine or a user or a customer, so I can do anything I want with it.

Heck in a repository you can mix sources with all kind of licenses, all next to each other! Monorepos do exist, you can have a monorepo with an APL2 source file and a GPL2-only source file checked in next to each other, and it won't really matter much. What _really_ matters in practice is what one distributes to users.

So, in many cases (which again might not apply here, not familiar with uutils), _effectively_ and _in practice_ even though not de jure obviously, license of tests doesn't really matter for those purposes. It matters for other purposes ofc, most important of all for clarity. But I am willing to bet nobody is going to be sued because of the license of a unit test that isn't shipped, as long as the license of the shipped product is clear and above water.

GPL antipathy (was GNU coreutils)

Posted Sep 19, 2026 10:27 UTC (Sat) by alx.manpages (subscriber, #145117) [Link]

If their tests are publicly distributed on github, they are being distributed, for the purposes of the license. The fact that they aren't included in the binary packages doesn't mean it's not distributed.

If I have access to it, and they even hold a license by which I can download and use them, that's distribution.

They could perfectly license the tests as GPL, and that would indeed be fine. But they haven't done it.

GPL antipathy (was GNU coreutils)

Posted Sep 18, 2026 18:47 UTC (Fri) by dskoll (subscriber, #1630) [Link] (17 responses)

This "not caring" stance is actually pretty common and unsurprising

But given that uutils is likely going to be used mostly on Linux where a substantial number of people do care about licenses, why not license it under the GPL?

If you truly don't care about the license, you should have no objection to relicensing it under the GPL, right? Given that the current license is MIT, it's easy... you don't even need to ask contributors' permission to relicense it. You can just make new versions GPL-licensed and you're done. (Of course, people can still use previous versions under the MIT license if they want to.)

I suspect the real position is "We say we don't care about the license, but we're not open to changing it to any other Free Software / Open Source license, so we actually do care."

GPL antipathy (was GNU coreutils)

Posted Sep 18, 2026 21:15 UTC (Fri) by moltonel (subscriber, #45207) [Link] (9 responses)

Fair question, and I suspect that if the original author had anticipated the backlash, he might have chosen a different license. But changing the license now is not as easy as you make it sound. You'd still want to get the go-ahead from your contributors, or risk losing/forking your community. Uutils is also a library (used for example by nushell and brush), so a switch to GPL would cascade through the ecosystem.

I think Collin's phrasing ("they do not care about licensing at all") is exaggerated. Some contributors presumably do care to some extent (I invite you suggest a license change on one of the BSD mailing list and see how that goes). It's just not the main thing that attracts them to the project (there are *many* reasons to be interested in uutils). But when a large portion of the internet accuses your project to be about "relicensing" (rather than reimplementing), or your distro to be planning to go proprietary, the reply "it's not about the license" eventually gets distorted into "we don't care about licensing".

And lastly, realistically, switching uutils to GPL would not gain users anything. The extra protection that GPL gives is pointless for coreutils, because as the Ubuntu guy said "nobody can make money with `cp`". There's no incentive to make proprietary modification to coreutils. The `cp` in that proprietary appliance from an uncooperative manufacturer will remain the same as the one on github, whether it stayed MIT or switched to GPL.

GPL antipathy (was GNU coreutils)

Posted Sep 18, 2026 21:22 UTC (Fri) by collinfunk (subscriber, #169873) [Link] (3 responses)

> And lastly, realistically, switching uutils to GPL would not gain users anything. The extra protection that GPL gives is pointless for coreutils, because as the Ubuntu guy said "nobody can make money with `cp`". There's no incentive to make proprietary modification to coreutils. The `cp` in that proprietary appliance from an uncooperative manufacturer will remain the same as the one on github, whether it stayed MIT or switched to GPL.

Do you think things like "Microsoft Coreutils" get announced at their Build event because they are feeling extra nice at the time?

GPL antipathy (was GNU coreutils)

Posted Sep 18, 2026 22:58 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

> Do you think things like "Microsoft Coreutils" get announced at their Build event because they are feeling extra nice at the time?

No? They clearly explained their rationale at that announcement. Why do you think it has anything to do with licensing as opposed to the fact that uutils is cross platform and Microsoft wanted to remove friction for WSL users and provide a multi-call binary?

GPL antipathy (was GNU coreutils)

Posted Sep 18, 2026 23:07 UTC (Fri) by collinfunk (subscriber, #169873) [Link] (1 responses)

I was arguing with the person to whom I was responding, who was making the claim that GNU coreutils or any other implementation has no monetary value, and using that to hand-wave away licensing concerns.

It sounds like you agree with the point I was implying: that Microsoft invested resources in this (developer and Product Management time, for example) because they felt it would get people to use Windows more, benefiting them financially.

GPL antipathy (was GNU coreutils)

Posted Sep 19, 2026 2:25 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

You are conflating the financial value of improving a platform with the value of monetizing proprietary code.

Yes, Microsoft benefits financially by making Windows and WSL more attractive to developers. However, that benefit comes from reducing ecosystem friction, not from hoarding a closed-source version of cp. The economic incentives already align with keeping the code open and upstreaming changes which is why they do with this voluntarily with uutils, making a copyleft license functionally redundant for this specific class of software.

GPL antipathy (was GNU coreutils)

Posted Sep 19, 2026 0:02 UTC (Sat) by dskoll (subscriber, #1630) [Link] (4 responses)

Well, OK. The thing is the goal of uutils (or at least, Rust coreutils or whatever it's called) is to be an exact drop-in replacement for GNU coreutils, which is GPL-licensed. I would not go on a BSD mailing list and suggest a license change because the BSD kernels and userspace are not claimed to be drop-in replacements for GPL'd things.

I cannot imagine that the uutils developers didn't consider the risk that they might inadvertently create software that some would consider to be derived from the GPL reference project for which they aim to be an exact drop-in replacement. I also think that any reasonable developer would, out of an abundance of caution, license the drop-in replacement under the same license as the original project. So it does seem a little disingenuous to me.

switching uutils to GPL would not gain users anything

Maybe, maybe not. The more GPL'd code a consumer device uses, the more likely it is for users to be able to get access to the source code, because there are a lot more interested parties who might enforce their license. Every non-GPL'd project that can be used to replace GPL'd code reduces users' leverage a little bit.

The library part of uutils could be LGPL'd which avoids most of the issues with GPLing a library.

GPL antipathy (was GNU coreutils)

Posted Sep 19, 2026 9:23 UTC (Sat) by bluca (subscriber, #118303) [Link] (3 responses)

> The library part of uutils could be LGPL'd which avoids most of the issues with GPLing a library.

It still leaves huge pitfalls in place though. LGPL sucks as a license in a multi-platform project that aims to be popular and used by proprietary programs too, it only really works with a bunch of manual exceptions bolted on, so that it's not really LGPL anymore. Most important of all, an exception for static linking. You can only dynamic link to an LGPL library, if you statically link it, your program is now also LGPL. And for a Rust project, which really only does static linking, that means effectively there's no difference between LGPL and GPL.

This is why years ago I spent a fuckton of time and effort relicensing zeromq from LGPL3 + a bunch of custom exceptions to MPL2. It's a much, much nicer and usable license especially for libraries, and I can't recommend it enough.

GPL antipathy (was GNU coreutils)

Posted Sep 19, 2026 13:29 UTC (Sat) by dskoll (subscriber, #1630) [Link] (2 responses)

LGPL sucks as a license in a multi-platform project that aims to be popular and used by proprietary programs too (my emphasis)

Well, there you go. If uutils aims to be "used by proprietary programs too", then it clearly cares very much about the license and it's disingenuous to pretend it was picked almost as an afterthought.

It also means the project has to be scrupulous about not inadvertently creating a work derived from a GPL'd work, which imposes quite a high additional workload.

GPL antipathy (was GNU coreutils)

Posted Sep 21, 2026 8:10 UTC (Mon) by bluca (subscriber, #118303) [Link] (1 responses)

> Well, there you go. If uutils aims to be "used by proprietary programs too", then it clearly cares very much about the license and it's disingenuous to pretend it was picked almost as an afterthought.

I am not really familiar with uutils so I have no idea. I was merely referring to the generic statement about LGPL vs GPL, as it's not that simple in many use cases, but I don't know what the intended use for the uutils library is.

> It also means the project has to be scrupulous about not inadvertently creating a work derived from a GPL'd work, which imposes quite a high additional workload.

Sure, but to a point. Copyright covers specific implementations, not generic ideas, and I am no lawyer but I'd willing to bet no court would rule that a handful of comments in some unit tests or some generic input data are even copyrightable, let alone enough to make one project the derived work of another. Given uutils and coreutils use very different programming languages, it seems to me it would be really hard to accidentally end up in that situation.

Translation results in a derivated work

Posted Sep 21, 2026 12:49 UTC (Mon) by alx.manpages (subscriber, #145117) [Link]

> Given uutils and coreutils use very different programming languages, it seems to me it would be really hard to accidentally end up in that situation

Translating a book from English to Chinese (completely different languages) results in a derivative work. The language is unimportant. I don't know why this is repeatedly mentioned as a reason to dismiss copyright concerns.

GPL antipathy (was GNU coreutils)

Posted Sep 19, 2026 12:23 UTC (Sat) by Wol (subscriber, #4433) [Link] (6 responses)

> But given that uutils is likely going to be used mostly on Linux where a substantial number of people do care about licenses, why not license it under the GPL?

Because some people are pragmatists, and some people are fundamentalists?

I gather most Rust software is MIT, so the pragmatist says "uutils is Rust, pick the Rust licence, pick MIT". And unless the primary maintainer(s) change the licence, it's *not* easy to change a project licence. Sure you can fork it, but then your fork needs to win the ensuing battle.

Me, I'm a pragmatist. I have no problem whatsoever contributing to GPL stuff (ScarletDME is GPL), but my preferred licence is the MPL - weak rather than strong copyleft. And as I've often said, for much of the code I enjoy writing, it gets distributed as source or the equivalent of .o files (binary modules), so the GPL gains me pretty much nothing over MIT or MPL.

(And linux is about freedom - the freedom to choose your own licence for your own code!)

Cheers,
Wol

GPL antipathy (was GNU coreutils)

Posted Sep 19, 2026 13:34 UTC (Sat) by dskoll (subscriber, #1630) [Link] (5 responses)

(And linux is about freedom - the freedom to choose your own licence for your own code!)

While it's obviously true that anyone can pick whatever license they want for their own code, I don't agree that's what Linux is "about". The GPL was not designed for the benefit of the original software developers. It was designed for the benefit of software users who might want to modify the software, and then users of that modified software who in turn might to want to modify it further.

uutils is not really a greenfield project. It's a re-implementation of an existing GPL'd project with a very long history. I don't blame people for looking askance at it as some kind of license-washing project. It does come across that way to me, to be honest.

GPL antipathy (was GNU coreutils)

Posted Sep 21, 2026 10:40 UTC (Mon) by taladar (subscriber, #68407) [Link] (4 responses)

My impression is that it does seem to come across as license-washing mostly to people who don't believe a Rust implementation has a lot of other benefits but who do believe the GPL has benefits. Meanwhile to people who think the GPL is basically somewhere between useless and harmful (e.g. to use your own code in your own work projects) while Rust has lots of benefits this reading that the primary purpose of the reimplementation is license-washing seems pretty absurd.

GPL antipathy (was GNU coreutils)

Posted Sep 21, 2026 13:12 UTC (Mon) by dskoll (subscriber, #1630) [Link] (2 responses)

I guess I'm in the middle? I can see the benefits of both a Rust (re-)implementation and the GPL.

Although I don't use Rust myself (I'm retired and have no desire/motivation to learn a new programming language at this point) I can see the benefits of using a memory-safe(r) language instead of C. But I'm also a strong GPL proponent. I think it's unfortunate that different language ecosystems seem to gravitate to different licenses.

GPL antipathy (was GNU coreutils)

Posted Sep 21, 2026 14:04 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

But I'm also a strong GPL proponent. I think it's unfortunate that different language ecosystems seem to gravitate to different licenses.

Companies do love shipping a single static binary without additional obligations…I still prefer to only use the FOSS tools though.

GPL antipathy (was GNU coreutils)

Posted Sep 22, 2026 8:07 UTC (Tue) by taladar (subscriber, #68407) [Link]

The GPL model just doesn't offer nearly as many benefits as whole program optimisation. And, crucially, the Rust community wasn't prepared to hand-wave dynamic linking soundness issues to the same extent the C and C++ communities do.

GPL antipathy (was GNU coreutils)

Posted Sep 21, 2026 14:49 UTC (Mon) by moltonel (subscriber, #45207) [Link]

Yes, that seems to match some real profiles, which would have a hard time seeing each other's viewpoints.

If somebody can't see any technical or community advantage to the Rust reimplementation, they might look at the license as the main purpose of the project, which would deserve some pushback. That theory was probably reinforced by Ubuntu adopting Uutils, between the fact that Canonical is for-profit and that the initial Uutils packages had issues that made a lot of users grumpy.

I don't think there's much correlation between people seeing the technical/community value of Uutils, and their disposition towards different licenses. I haven't seen anyone advocating for Uutils because of its license, but I did see a rare few advocating for it while wishing it was GPL.

GNU coreutils

Posted Sep 17, 2026 20:44 UTC (Thu) by collinfunk (subscriber, #169873) [Link] (3 responses)

> By your reasoning every three operand addition is a derivative of GNU coreutils.
> Preschools are infringing GNU Copyright!

Please note that the person you are responding to is not affiliated with GNU nor coreutils.

GNU coreutils

Posted Sep 17, 2026 21:05 UTC (Thu) by alx.manpages (subscriber, #145117) [Link] (2 responses)

Please note that the person you are responding to is not affiliated with GNU

Incorrect. I'm listed in GCC's MAINTAINERS file:

alx@devuan:~/src/gnu/gcc/master$ grep Colomar MAINTAINERS 
Alejandro Colomar               -               <alx@kernel.org>
Alejandro Colomar                               <alx@kernel.org>

nor coreutils.

Correct.

GNU coreutils

Posted Sep 17, 2026 21:10 UTC (Thu) by collinfunk (subscriber, #169873) [Link] (1 responses)

Sorry. Regardless, it sounded like the other commenter thought you were making claims representative of the GNU coreutils developers, and I felt it was worth correcting.

GNU coreutils

Posted Sep 17, 2026 21:22 UTC (Thu) by alx.manpages (subscriber, #145117) [Link]

> Sorry.

No problem.

> Regardless, it sounded like the other commenter thought you were making claims representative of the GNU coreutils developers, and I felt it was worth correcting.

Yup, sounds appropriate. :)

GNU coreutils

Posted Sep 18, 2026 10:07 UTC (Fri) by moltonel (subscriber, #45207) [Link] (13 responses)

Derivative work is not the only text of law at play here. In case of software, you notably have to look at abstraction-filtration-comparison [1], and understand the idea/expression dichotomy. All in all, it means that what can be considered for copyright is more narrow and subtle than you would think. Which is a good thing, because derivative work on its own is so cripplingly all-reaching that it would have killed the FOSS movement alltogether.

Have a look at the dozens of test cases in the PR linked by Collin that are not under accusation of infringement : they all look exactly the same. I have very similar tests in my CLI projects that have nothing to do with coreutils. This tells us that the this kind of test framework is incidental to a CLI project. A framework expression could itself be infringing, but because of the language difference, this one is clearly a different expression than GNU's.

Next we have to look at the test cases in abstract. A drop-in replacement reimplementation necessarily has similar checks. This is an "element dictated by the external factor of compatibility". That's painfully obvious when testing addition in `expr`, but I invite you to look at the other cases, maybe we can learn something.

Last but not least is the expression of those abstract test cases, in other words the actual values used for integers, dates, file names, etc. Uutils acknowledged those, and replaced them to clear the infringement. Hurray ?

To be clear, that infringement will IMHO remain a stain in Uutils's history. Even if I believe (IANAL) that they did clear GPL-copyrighted material out of their repo, I feel that they could have done a more thorough job, to avoid upsetting people. That said, their stance against copying from GNU is strong, they've put more controls in place, we'll see if they manage to avoid further accidents. It can't be easy with so many contributors, including some beginners and some LLM users. And let's not forget that GNU-Uutils interactions seems generally positive, with contributions of bugreports, testcases, and ideas flowing both ways.

[1] https://en.wikipedia.org/wiki/Abstraction%E2%80%93filtrat...

GNU coreutils

Posted Sep 19, 2026 9:47 UTC (Sat) by alx.manpages (subscriber, #145117) [Link] (12 responses)

The A-F-C test is not itself the law. It's just a tool used by courts for finding out whether two texts are likely enough to be derived, for when a direct proof doesn't exist.

From the wikipedia page you linked to:
> The Second Circuit Court of Appeals developed the AFC test for use in Computer Associates Int'l, Inc. v. Altai Inc. In that case, Computer Associates sued Altai for copyright infringement of a computer job scheduler program that was designed to be easily ported between operating systems. Proving copyright infringement requires proving both ownership of the copyright and that copying took place. This second requirement can be met either by direct proof, or as is more usually done, by demonstrating the following: 1) the defendant had access to the copyright material and 2) there is substantial similarity between the copyrighted work and the defendant's work.[2] Demonstrating substantial similarity can be difficult when the two works are not exact replicas, either in full or in part. The Second Circuit court had found there was little previous guidance on how best to do this.

In this case we have direct proof "that copying took place", so this test is unnecessary/irrelevant.

GNU coreutils

Posted Sep 19, 2026 21:33 UTC (Sat) by Wol (subscriber, #4433) [Link] (11 responses)

But another important test is "Does the copied work contain sufficient creativity to be eligible for copyright?"

My gut feel is the answer is a resounding NO. It's just maths.

Cheers,
Wol

GNU coreutils

Posted Sep 20, 2026 0:32 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

> It's just maths.

FYI, your definition of "just maths" is copyrightable in nearly every jurisdiction.

GNU coreutils

Posted Sep 21, 2026 9:57 UTC (Mon) by taladar (subscriber, #68407) [Link]

Mathematically expressed algorithms or proofs, maybe. Simple arithmetic expressions of concrete number? Extremely unlikely.

GNU coreutils

Posted Sep 20, 2026 15:12 UTC (Sun) by alx.manpages (subscriber, #145117) [Link] (8 responses)

> But another important test is "Does the copied work contain sufficient creativity to be eligible for copyright?"

> My gut feel is the answer is a resounding NO. It's just maths.

My instinct says there's enough. I'm not familiar enough with copyright cases, though, so I can't compare my instinct with real cases and what judges had to say about them.

Why I think it's copyrightable:

The intention of the uutils/coreutils project is to be perfectly drop-in compatible with GNU/coreutils (by perfectly, I mean, with the same exact options and their combinations, not just similar like different POSIX-compatible implementations of these tools, which are more loose).

There are several ways to do that:

- Copy the source code, and just do a translation from C to Rust. This would be the simplest alternative. It would clearly be a derivative work, of course, and would have to be under GPL.

- Copy the tests, and implement from scratch until the tests work. In this case, the tests would obviously be a derivative work, and would have to be under GPL. The source code would be a clean implementation, though, and since they don't link to the tests, I think they could have any license. Reading and using the tests would be similar to reading and using documentation.

- Read the documentation with great care to detail, and implement what it says. You better hope that the documentation is right. :) After you're done, you'll certainly have to expect many bug reports about incompatible details, because documentation never matches reality.

- Fuzz the binary extensively, so as to experimentally determine the behavior.

I believe they've gone route 2, and maybe hoped that by translating to a different language, people wouldn't notice that this has been a copy from the original (plausible deniability?), or maybe they thought that by translating they'd be free of copyright. But translations are explicitly a derivative work according to the US law. And then there's the case of a few lines of code from the tests that have been copied verbatim (they forgot to change them minimally so as to not be identical?), which just serve as evidence that this has indeed been the route. I don't think only a few lines of code have been copied and/or translated from the original, because then how have those tests been developed otherwise? I don't think someone has been fuzzing GNU/coreutils extensively so as to exercise all of the corner cases so as to reverse-engineer tests; have they? Especially, since fuzzing isn't as reliable/efficient as copying the testsuite. Fuzzing might help with some corner cases that aren't being tested, though.

GNU coreutils

Posted Sep 21, 2026 7:16 UTC (Mon) by kleptog (subscriber, #1183) [Link] (3 responses)

It's interesting to me that the US and the EU are almost complete opposites here. The US uses "derivative work" which tracks genealogy and so is susceptible to Ship of Theseus arguments. In contrast, EU copyright law cares if "protected expression" is present in the current work, so replacing everything really does make a new ship. Put another way: US copyright law cares about your git history, EU copyright law does not.

But more importantly, US copyright law cares about Sequence, Structure and Organisation (SSO) so even code that is completely rewritten can run into issues. The CJEU explicitly rejected this approach, so a program that is rewritten in a new language line-by-line would likely be safe.

That said, I looked at the test cases and it contains such original works as 'abc', 'xyz' the alphabet and the list of printable characters. The comments literally describe what the test case was doing and it doesn't look like you could write those test cases in any other way. Rust code doesn't look like C at all. These constants are probably not copyrightable anywhere on their own, but in the US may be considered one of the planks of the ship.

I dont have a horse in this race, but it would seem to me that uutils is no-brainer safe for EU copyright law and in the US perhaps fodder for copyright lawyers. For me it's interesting: which approach is better for protecting the progress of science and the arts?

GNU coreutils

Posted Sep 21, 2026 10:21 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

> In contrast, EU copyright law cares if

Hmmm.... Are you sure there is such a thing as "EU Copyright law"? There are directives... And the German copyright system is somewhat different from the British and Irish systems AFAIK. Can you really say "EU copyright .... cares if" here?

GNU coreutils

Posted Sep 21, 2026 10:32 UTC (Mon) by bluca (subscriber, #118303) [Link]

You can as long as such details are specified in the directive(s). Yes, member states are in charge of translating directives into national laws, given they are all different. But they must follow the directives, and if things end up in court, they can be appealed to CJEU which has primacy over every national court as per the treaties, and thus has the last say, and generally speaking follows the directives.

GNU coreutils

Posted Sep 22, 2026 11:47 UTC (Tue) by kleptog (subscriber, #1183) [Link]

EU Directives specify policy objectives, the national implementations are mostly about mechanisms.

For example, the UK copyright law looked a lot like the US system where the goal is to protect economic activity. Over the course of a few decades it was transformed to be more in line with the French/German idea that it is author's expression that is to be protected, not the economic value.

A way to put it is that EU copyright law is aimed at allowing everyone to create new expression and have it recognised as theirs, whereas US copyright law is aimed at protecting the economic value for the creators under the theory that if you don't do that, no-one will create new things.

Additionally, for this discussion the Software Directive is very relevant in that it explicitly rejects many of the copyright related arguments used by US software companies. For example, Google vs Oracle was dead on arrival in the EU.

(There is also a flavour of Civil Law's valuing of legal certainty over Common Law's judicial flexibility. But that's really a side track.)

But for the purposes of this discussion, EU copyright law can be considered quite uniform.

GNU coreutils

Posted Sep 21, 2026 11:09 UTC (Mon) by moltonel (subscriber, #45207) [Link] (3 responses)

You should acquaint yourself with the project's history and development docs before making these claims.

> Copy the source code, and just do a translation from C to Rust.

Would make no sense for the project's original goal (which was just to learn Rust, no ambition of becoming a realistic drop-in replacement like it is today). This would also go against the current goals, which includes idiomatic maintainable code, but also doing better than GNU wherever they can.

> Copy the tests, and implement from scratch until the tests work.

Nitpick: Uutils don't do TDD. Huge caveat: the GNU tests are nowhere near good enough as a specification. But Uutils does use (and contributes to) the standalone GNU testsuite (as well as BusyBox and ToyBox), this is the basis for they GNU compatibility metric [1].

> The source code would be a clean implementation, though, and since they don't link to the tests, I think they could have any license.

You forget that unittests in Rust are often in the same file as the code. And mixed-license repos are a pain, even if the final binary is single-license. Have you never wished you could pull some `vipw.c` code into the rest of the shadow repo ? Can you certify that none of the BSD code is derived from that GPL file ?

> Read the documentation with great care to detail, and implement what it says

Yes, that's obviously a part of it, that's how most people figure out details of coreutils behavior. And of course, just like tests, it'll have errors and gaps.

> Fuzz the binary extensively

Uutils's fuzzing framework is here[2], and a lot of issues and PRs mention fuzzing, it seems to work. But I imagine the behavior of some coreutils is pretty hard to fuzz.

> I believe they've gone route 2,

This is a surprisingly strong assertion. You're extrapolating from a handful of cases, apparently without much knowledge of uutils's development practices.

Uutils has ~20-50 monthly contributors [1], presumably many new or non-recurring. Clearly, some of them thought that copying some trivial testcases was OK (or perhaps you could point fingers at LLMs), but that doesn't make it the project's unwritten strategy. Beside the clear no-copying official policy [3] and the cleanup PRs, you can see that copied tests also get caught and rejected at review time [4].

As an aside, the testcases that were copied were rather underwhelming. Basic values with no edge cases. You could do much better here, for example prop-testing. Uutils gained very little from copying these, the wrongdoing of having trivial tests in BSD rather than GPL is minimal. If I was the copyright holder, I'd be annoyed but wouldn't go attacking the project. Some people have a fundamental dislike of Uutils, and I feel that this copying issue is just used instrumentally.

> I don't think only a few lines of code have been copied and/or translated from the original, because then how have those tests been developed otherwise?

Sorry, but this is silly. How could somebody come up with original code and tests, indeed ? Docs, sharable test suites, fuzzing, audits [5], manual testing, good old user bug reports, rinse and repeat. The usual stuff.

[1] https://github.com/uutils/coreutils-tracking
[2] https://github.com/uutils/coreutils/tree/main/fuzz
[3] https://github.com/uutils/coreutils/blob/main/CONTRIBUTIN...
[4] https://github.com/uutils/coreutils/pull/13818#issuecomme...
[5] https://seclists.org/oss-sec/2026/q2/331

GNU coreutils

Posted Sep 21, 2026 13:11 UTC (Mon) by alx.manpages (subscriber, #145117) [Link] (1 responses)

> > Copy the source code, and just do a translation from C to Rust.
>
> Would make no sense for the project's original goal (which was just to learn Rust, no ambition of becoming a realistic drop-in replacement like it is today). This would also go against the current goals, which includes idiomatic maintainable code, but also doing better than GNU wherever they can.

I expect you could do a translation that uses idiomatic and maintainable Rust. With spoken languages, translators also translate so that expressions make sense in the target language, and do not translate word-by-word.

> You forget that unittests in Rust are often in the same file as the code.

I don't write Rust, so I don't know what's conventional there.

> And mixed-license repos are a pain, even if the final binary is single-license.

So, it seems uutils cares more about the license than it seemed at first.

> Have you never wished you could pull some `vipw.c` code into the rest of the shadow repo ?

No.

> Can you certify that none of the BSD code is derived from that GPL file ?

Yes. We don't have much code under src/ in shadow that is interesting for sharing with other files. The code that moves around is under lib/.

If I ever had to move code from there to elsewhere, I'd be happy to relicense the other files as GPL, FWIW.

GNU coreutils

Posted Sep 22, 2026 8:05 UTC (Tue) by taladar (subscriber, #68407) [Link]

> I expect you could do a translation that uses idiomatic and maintainable Rust. With spoken languages, translators also translate so that expressions make sense in the target language, and do not translate word-by-word.

Not really. C and Rust program architectures and idiomatic styles are extremely different. This is a concept that just doesn't occur to this extent in natural languages.

GNU coreutils

Posted Sep 21, 2026 15:31 UTC (Mon) by alx.manpages (subscriber, #145117) [Link]

You're extrapolating from a handful of cases, apparently without much knowledge of uutils's development practices.

Uutils has ~20-50 monthly contributors [1], presumably many new or non-recurring.

Interestingly, the copying from GNU coreutils seems to have come from recurring contributors/maintainers. And it isn't just a handful of cases; it's large commits full of copied text (we're talking hundreds of lines of code!).

Here are a few references, but there are several more:

8d03a6aa (2026-04-04; "numfmt: add GNU test patch for devdebug, help-1, and field-range errors")
fa24992b (2026-01-20; "unexpand: add support for extended tab stop syntax (+N and /N) (#9265)")
55b2eacb (2021-08-14; "Added gnu tests for tr (mostly as comments)")

Look at the dates. This is an attitude extended in time. Look at the authors. They have many many commits in the project. Look at the subjects. They're quite explicitly and shamelessly copying the GNU tests.

GNU coreutils

Posted Sep 18, 2026 14:06 UTC (Fri) by Wol (subscriber, #4433) [Link]

> That shouldn't matter. Translation is among the things that cause a derivative work, according to the above. What would matter is whether it was derived or not from the original code or was written from scratch, and whether the original code taken for that derivation was copyrightable or not.

But it DOES matter. As has been pointed out, in order for a work to be copyrightable (not derivative, copyrightable), it needs to involve a reasonable amount of creativity. And Maths is not a *creative* activity. It's "sweat of the brow". Which is EXPLICITLY EXCLUDED from copyrightability.

"8 + 5 = 13" is Maths. "5 + 6 = 11" is Maths.

If I write screeds on the proof of Fermat's Last Theorem, if it's all dense Maths then it is not Copyrightable Subject Matter.

As a researcher I probably would want people to copy (so long as they include my name at the bottom), but I can NOT stop them copying the Maths. I could stop them sticking my copy of my work in a photocopier, but that's because the layout, formatting, pagination etc is considered an artistic work suitable for copyright protection. Not the mathematical content.

Cheers,
Wol

GNU coreutils

Posted Sep 16, 2026 20:21 UTC (Wed) by moltonel (subscriber, #45207) [Link] (1 responses)

AFAIK GNU coreutils does not have an installer that this could have been copied from, and neither does Uutils coreutils. This seems to be purely MS's bug.

GNU coreutils

Posted Sep 16, 2026 20:30 UTC (Wed) by alx.manpages (subscriber, #145117) [Link]

Ahhh, that makes sense. From the message, I had interpreted it as if that text was in uutils' installer.

If it's in MS's installer, it's likely a misconception from MS, which isn't surprising.

Thanks!

GNU coreutils

Posted Sep 15, 2026 21:22 UTC (Tue) by moltonel (subscriber, #45207) [Link] (3 responses)

> Why not "Core Utilities for Windows"?

Because "coreutils" is nice and sweet, and widely understood as "a collection of utils including cat, cp, chmod, etc, probably also grep and sed" (even though GNU puts those in a different package). The term isn't tied to GNU: you'd understand "BSD coreutils" just as well. FWIW, somehow "Core Utilities for Windows" sounds to me like a different thing, related to the Windows registry or something. Adding to the fun, the Wikipedia article is "GNU Core Utilities" ;)

This naming feud reminds me of one that got trendy in France last year: whether vegetarian sausages could be called "sausages", with some people insisting that the term was reserved for meat products, and that vegetarians must now find a different word for this clearly sausage-shaped food item that had been called "sausage" for years.

This is silly. Let people say just "sausage/coreutils" when it's enough, and qualify with "meat/veg/gnu/uutils" when the context is unclear and/or the difference matters.

GNU coreutils

Posted Sep 16, 2026 14:13 UTC (Wed) by ballombe (subscriber, #9523) [Link] (2 responses)

The name coreutils was invented in 2003 by GNU as a fusion of textutils, shellutils, and fileutils,
It was never used for other OS, there was never a BSD coreutils.

The wikipedia page is 'https://en.wikipedia.org/wiki/Coreutils'.
coreutils is one the GNU project achievement whose value should not be underestimated.

Before uutils there was little confusion about what coreutils was.

GNU coreutils

Posted Sep 16, 2026 16:39 UTC (Wed) by moltonel (subscriber, #45207) [Link]

> The name coreutils was invented in 2003 by GNU as a fusion of textutils, shellutils, and fileutils, It was never used for other OS, there was never a BSD coreutils.
> Before uutils there was little confusion about what coreutils was.

There you have it : the definition has shifted. As I said, it's now more a category than a specific implementation. But it's been a few years, I find it hard to believe that people are genuinely confused that the term doesn't only relate to GNU. Having a generic term is useful, and adding an implementation name when necessary is easy.

Coming back to the "Coreutils for Windows" term that troubled you, it should hopefully not be surprising that MS chose the implementation with proper Windows support. And while they could have titled "Uutils-Coreutils for Windows", that seems like a needless mouthful, that MS's audience would not care about. I can't help but feel that "trouble" or "confusions" are not the real emotions at play here.

> The wikipedia page is 'https://en.wikipedia.org/wiki/Coreutils'.

That link redirects to https://en.wikipedia.org/wiki/GNU_Core_Utilities, which matches the page's title (on LWN too). The terms were always interchangeable, "coreutils" isn't a brand name, it's an abbreviation in the purest *nix tradition.

> coreutils is one the GNU project achievement whose value should not be underestimated.

Fully agreed, but I don't see where GNU coreutils is getting underestimated, devaluated or anything else ? If anything, being category-defining is a consecration. FWIW, I respect and admire the achievements of both GNU and Uutils.

GNU Core Utilities

Posted Sep 17, 2026 0:40 UTC (Thu) by CChittleborough (subscriber, #60775) [Link]

Relying on Wikipedia often fails. It has an article named GNU Core Utilities, which was renamed from Coreutils in 2006 to "use [the] full name". Since then, "Coreutils" has been a redirect to "GNU Core Utilities".

OTOH, GNU Coreutils is a remarkable project. The code which handles directories for cp, mv and install is a real eye-opener.

GNU coreutils

Posted Sep 16, 2026 0:32 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Following the naming scheme of "Windows Subsystem for Linux", I think we'd get "Windows Utilities for the Core" or other horror.

GNU coreutils

Posted Sep 16, 2026 10:43 UTC (Wed) by Karellen (subscriber, #67644) [Link] (1 responses)

I'd have thought, for a Windows package, calling it posixutils or similar would make it much more clear to Windows users that it's not anything that could be considered core to Windows.

Or, if they're not aiming this at Windows-only users, but just at those already familiar with the Linux ecosystem, then surely sticking with the upstream name of uutils would be better? (And, as I think someone else already pointed out, you end up with the curl problem of the package they're providing not actually working exactly the same as the package they're kinda claiming to be. (Yet.))

GNU coreutils

Posted Sep 16, 2026 19:50 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

They can't call it posixutils, because Windows has had a POSIX-conformant subsystem for many years before WSL came along. Using the word POSIX now would invite confusion between that subsystem and WSL. Perhaps it's not so bad in newer versions of Windows, where WSL is (as far as I can tell) the only POSIX game in town, but they still have a long tail of legacy customers who are on ancient versions and (one presumes) paying extortionate rates for ongoing support.