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

112

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.

10:47 PM · Mar 30, 2021Twitter Web App

Replying to

and

Linux kernel has GCC plugins that are GPLv2 only which is incompatible with the GCC GPLv3 license. If you use those, you lose the GCC Runtime Library Exception and cannot distribute the resulting code if it links in libgcc code. The whole thing is just a mess and is painful.

Replying to

and

You also presumably can't redistribute the plugins and instead can only build them locally. The Linux kernel can use them because it doesn't need the runtime library exception. GCC is such a pain (cross-compiling, etc.) and I'm glad AOSP got rid of it. GNU binutils soon too.

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.

Show replies