Conversation

The other would-be-funny-if-it-weren't-so-sad thing here is the idea that in 2021 the GNU Coreutils have the market leverage to convince consumers to choose free software over proprietary alternatives

Quote Tweet

Hector Martin

@marcan42

Mar 30, 2021

Hey, want to take a guess what the @FSF's latest board member, Ian Kelling's, most recent contribution to Free Software is? That's right: harassing a project trying to rewrite common POSIX tools in Rust for being Anti-Freedom™. Because they chose the MIT license.

Show this thread

113

Tony "Abolish ICE" Arcieri

@bascule

Mar 30, 2021

Replying to

@pcwalton

Just gonna leave this here github.com/uutils/coreuti

Tony "Abolish ICE" Arcieri

Replying to

and

Also this

Debian running on Rust coreutils

tldr: Rust/coreutils is good enough to boot a Debian with GNOME, install the top 1000 packages, build Firefox and the Linux Kernel.

Replying to

and

There's also landley.net/toybox/about.h as a permissive licensed BusyBox replacement (in C, not Rust). AOSP uses ToyBox as both the implementation of most *nix utilities in the OS and for building the OS. It's part of the AOSP toolchain used in the namespace-based build sandbox.

Replying to

and

Toybox's developer was previously the BusyBox maintainer. Conflict with GPLv3 proponents is why he ended up making it: landley.net/toybox/faq.htm Think he also got disillusioned as part of the GPL enforcement actions they started. Toybox makes GPL proponents particularly mad now.

Replying to

and

There's a whole drama over it: lwn.net/Articles/47830 GPL proponents see Toybox as essentially an anti-GPL-enforcement project. The Toybox maintainer is the person who *started* the BusyBox GPL enforcement actions and then grew disillusioned with it. I find it quite amusing.

lwn.net

A tempest in a toybox

The eLinux.org web site is currently promoting a project to write a replacement for Busybox under a permissive license. Normally, the writing of more free software is seen as a good thing, but, in...

Replying to

and

GPL regularly gets in my way. GPLv2 (Linux kernel) is incompatible with the GPLv3 or later license used by GNU and most other copyleft supporting projects. GPL is why Linux doesn't have a proper mainline ZFS support. GPLv3 forbidding an immutable root of trust is problematic.

Replying to

and

to be fair, making ZFS incompatible with Linux has been a quite intentional move from Sun so is not the GPL at fault here (I have my share of GPLv3 avoidance issues, fwiw)

Replying to

and

It is the GPL at fault. GPL is similarly incompatible with MPL 1.0 in the same way for the same reason. It's incompatible with other licenses for similar reasons. Even if the talking point that Sun chose the license for that reason was true (doubtful), it's still GPL's fault.

Replying to

and

oook

Replying to

and

GPL is even largely incompatible with itself (GPL vs. AGPL, GPLv2 vs. GPLv3, etc.). Like most modern licenses, CDDL deals with patent grants, which is GPLv2 incompatible. Apache 2 is GPLv2 incompatible for the same reason. Per-file licensing is the issue shared with MPL 1.0.

4:05 PM · Mar 31, 2021Twitter Web App

Replying to

GPL / FSF supporters repeating the same claim for years about Sun's choice of the CDDL to be incompatible with the GPL doesn't actually have evidence. Does Google choose Apache 2 for nearly everything to be incompatible with the Linux kernel? I think it's a very silly claim.

Replying to

and

as I said, oook