OpenBSD rejects Rust uutils port, keeps GPL coreutils in ports tree

On 20 September 2026 the OpenBSD ports@ mailing list turned down a proposal to add Rust-based uutils utilities as drop-in replacements for the GNU tools; project founder Theo de Raadt called any replacement of the GPL coreutils port a complete non-starter.

The proposal

David Uhden Collado submitted sysutils/uutils as a multi-package port whose meta-package installs uutils-coreutils, uutils-findutils, uutils-diffutils, uutils-grep, uutils-awk, uutils-sed and uutils-tar; the coreutils component is based on uutils/coreutils 0.12.0. The aim was to offer alternatives to the GNU utility ports without source changes in dependent ports: uutils-coreutils installs the same g-prefixed commands as sysutils/coreutils, as symlinks to a multicall binary under libexec/uutils, while every package conflicts with its GNU counterpart and declares the GNU port as a secondary @pkgpath.

Compatibility is not complete, the submitter noted: uutils-diffutils has no diff3 or sdiff, and uutils-awk remains mainly a POSIX implementation.

The pushback

Stuart Henderson replied that he did not think this was a usable approach for ports. The submitter answered that the Rust reimplementations interest him, that Ubuntu 26.10 already adopted uutils coreutils once the project reached a usable level of maturity, and that their permissive MIT licence suits OpenBSD.

Theo de Raadt's reaction was a one-liner: "Smells like agenda." A second set of permissively licensed utilities that behave only subtly differently from the ones users already have makes no sense, he argued: if a pipeline mixes the OpenBSD ls with OpenBSD sed or cut and accidentally relies on a non-standardized output characteristic, swapping in a different ls exposes the user to a clash of non-standardized tooling behaviour. On the remark that uutils is written in Rust he added: "Oh, because it is written in Rust. Your agenda is showing."

Why the ports tree keeps GNU coreutils

Coreutils exists mainly to assist GNU-behaviour-sensitive build environments and to grease the wheels for complicated ports during build, de Raadt explained; there is little priority on making it good for interactive daily use, where users should lean on OpenBSD's own utilities at the standard paths. Because that build side depends on the maximum stability of the slow-changing coreutils, any behaviour change would cost ports developers time.

Stuart Henderson saw no big issue with the tools being in ports for users who want them, given OpenBSD developer support to get them into the tree, but set two conditions: they cannot conflict with the GNU tools, and they cannot replace the GNU tools as dependencies of other ports, because Rust restricts architectures too much.

The status quo stands: ports needing GNU behaviour keep depending on the GPL-licensed GNU coreutils, and the uutils port has not been accepted.