I'm shocked the Rust community is pushing an MIT licensed Rust rewrite of GNU coreutils

community
1

I just stumbled upon a very interesting Rust project and community called uutils, which is rewriting GNU coreutils (and others) in Rust. Great idea, I thought, and it has recently emerged as a "real" thing, promising replacement tools soon.

But I looked more closely and was shocked by what I found. They have replaced the GPL with MIT license. Here is the reasoning, from the FAQ of their blogpost:

Why the MIT License?
For consistency purposes. We're not interested in a license debate and will continue to use the MIT license, as we did with Coreutils.

What a glaring non-answer. And there is no link to any reasoning.

A poster on Reddit called this "GNU plus Linux minus GNU" in a way mocking Richard Stallman's call to recognize GNU's contribution to Linux. Another said:

A small win for cooperation, but a massive loss for user rights.

Someone asked:

Did the project publicly post a rationale somewhere for why they didn't go with GNU License?

And received this reply:

Yeah, author doesn't have a huge preference. If contributors want to switch, he's fine with that.

And yet, apparently there will be no further debate about the license.

Uutils was also supported by Google Summer of Code. Coincidence?

It's beginning to look like Uutils is a Trojan horse in the Linux community, meant to replace core utilities (literally coreutils!) with a non-GNU version, promising memory safety but stealing user freedom.

Honestly I'm shocked things could have gotten this far. The project is coming to fruition as we speak.

Open question for the Rust community: is this the kind of license politics you are going to bring to the Linux Kernel? Is refurbishing Linux with an MIT license somewhere down the line, care of Google money?

Just for the record, no amount of memory safety will ever convince me to use MIT coreutils. Software freedom is more important than memory safety.

I'm shocked that 530+ Rust developers (says the Uutils blog) have signed up for this dangerous move without a rationale and without any debate. How dare they?

If these tools make their way into Linux distributions, as seems to be the goal, it's going to be war. We're not going to allow technofascists to steal Linux away from us, one Rust rewrite at a time. The whole Rust-in-the-Linux-kernel debate just got serious. We need to move against this development forcefully and decisively so that Rust development in Linux can move forward with confidence.

The first step is to demand the uutils leaders to provide their justification for the MIT license and provide a roadmap for releasing under the GPL. Play time is over.

1 Like
2

And what exact user freedoms does the GPL provide that the MIT license does not?

11 Likes
3

promising memory safety but stealing user freedom.

Is this a troll? I genuinely can't tell. How is MIT licence (the most do whatever you want) licence stealing user freedom? Please paint a picture for me, I can't seem to imagine it. What possible thing can big corpos do with MIT-licenced coreutils code to steal user (of Linux??) freedom that they couldn't do with GPL-licensed coreutils? Serious question, bc to me the math isn't mathing.

Software freedom is more important than memory safety.

Idk dude, if you super care about freedom then the MIT licence is as close to that as you can get. Its literally "do whatever idgaf" licence. Arguably copyleft licences are less free because they put additional restrictions on what the user of the code can or can't do. There is a solid case to be made that MIT is more of a "libertarian" licence than GNU is.

We're not going to allow technofascists to steal Linux away from us.

You know you can like, add MORE licences to whatever end-code you produce. If I use an MIT library, I can still licence my end-code more restrictively. If bits and pieces of what makes up a Linux distro are MIT licensed, they can still licence their contributions more restrictively with, say, a GPL licence. So then if you want to use that distro, you have to follow ALL the licences, including the most restrictive ones.

13 Likes
5

What “Linux” are you talking here, though? Arguably the most popular linux distribution never used GNU coreutils.

Shouldn't you ask that from people who are actually doing that work?

Indeed: how dare they to release what they wrote on their terms and not follow after someone's else ideal.

I would tell how “how dare they”. Every time they read how someone who haven't wrote or done anything proclaims:

Oh, thanks for one more reason to stick with MIT and not play the GNU-related politics.

If you are seeking war then you may get it. But threatening potential allies is not how you win wars.

Doesn't your rant work as enough of a justification?

When some self-righteous zealot arrives and starts threatening me for what is supposed to be free choice… isn't the fact that using MIT instead of GPL would free me from pointless discussions with people who give me nothing but demand everything enough?

12 Likes
6

Projects such as this seem really fraught. When you essentially transliterate the Gnu implementation into Rust, aren't you creating a "modified work" in the sense of the GPL?

7

I presume that this is a bit, but in case I'm wrong:

The original GNU coreutils will always be there and will presumably always be GPL. If it's important to someone that software is GPL, then presumably they will use GNU coreutils instead.

1 Like
8

Theres a case to be made that an MIT-licenced transliteration of GPL-licenced code, that this is a licence violation. But if so, that would have to be decided by courts. And if they do decide that it is licence-infringement, then yeah I guess the uutils project is wrong.

But I'm going off the assumption here, that no such licence violation took place, because OP was appealing to ethics/morality rather than legality here. My first answer is what I think, if assuming we are talking just purely on ethical/moral grounds,

9

The project shows tables with the Gnu stuff side-by-side. It seems fishy to me. I would never release software under the GPL personally, but I would also not publish stuff where I've studied a GPLed implementation.

10

Yeah, and thats their problem to figure out in court. Again:

If licence-infringement, then BAD
Else, my first answer

1 Like
11

The sad thing is that even if this particular one is a troll… there are enough of them who genuinely feel that way.

What started as a noble project to create free OS for the masses over years turned into collection of zealots who go around on forums and demand that others would work for their cause without any compensation or reason.

I have no idea if there are still any honest developers left who want to associate themselves with that crazyness, but what they achieve, and very efficiently achieve, is the opposite. That's how toybox was born and how llvm and clang went from an academic project to full-blown compiler, etc.

Would that still work on an Android desktop, though? It's coming, you know.

But instead of thinking how keep at least that meager slice of desktop that Linux (outside of WSL) still has… they go around threatening uutils developer… sadly that's normal for them.

I recommend you to study history better. While “I have never seen GPL sources” is good enough defense, it's not a requirement. And while USL v. BSDi lawsuit ended up with settlement and not with a court decision it went badly enough for AT&T to show that you don't become “contaminated for life” simply because you have taken a look on some source code, at some point.

5 Likes
12

Given the precedent, to emulate an API from scratch for learning and improved security without directly using the original code is not a “derivative work” which would break any rules. Further, the core utils are free, there’s no monetary harm in a potential alternative.

To the spirit of their intent, as copyleft licenses attempt to prohibit private tinkering, they are counter to their own objective, being significantly less free than their permissive complements by virtue of the burden of disclosure of changes, which prevents others from creating sustainable value, because these others who make improvements are forced to report all their work and give their improvements away for free.

If you have to report every change you make to some code, then it’s less free, not more. If contributors are required to work for free then they must support themselves through other projects, which distracts from working on the project at hand.

Copyleft seems idealistic yet economically unsustainable, but I could be wrong, obviously if we didn’t need to work to support ourselves then it would be great to contribute to free software for fun! IMHO the permissive licenses are better because you can fiddle with it privately and contribute good changes if you want without feeling obligated

13

How ironic. The main reason is almost certainly because almost all public Rust code is MIT (or close, eg. Apache), specifically because it's the least likely to cause any legal issues.

This isn't a zero sum, either it's virally user friendly or virally corporate friendly situation; the point of permissive licenses like MIT is just to be friendly.

Strictly GPL doesn't require you to publish any code change you make, only that if you "distribute" the binary output you must make the source at least available on request.

In fact this is a problem for GPL service projects now as apparently providing a service isn't distributing, hence we have a bunch of closed forks of GPL code like Redis, and now you need to remember to license with Affero GPL for it to actually do anything useful.

There was even an argument around whether literally physically distributing closed boxes that contained Linux counts as distributing a binary (TiVo being the canonical example), and I believe the answer was generally no!

In short, the "spirit" of GPL falls far short of the reality, and that spirit isn't even against the private tinkering you're concerned about.

10 Likes
15

No, there no argument needed at all. A transliteration would unambiguously be a gross violation. The is also no way that this project is anything close to a transliteration. I ask you to please be more precise in you word usage in the future.

2 Likes
16

My word usage is as precise as can be. Namely my statement is an implication statement:

Is transliteration => Very likely illegal

I didn't say it was a transliteration, I think its probably not (it would be insane if it was ngl). But just in case it is, then its probably illegal, and that's for the court to decide. So more succinctly:

If transliteration/other licence-infringement, then bad/likely illegal,
else, my first comment applies.
+
probably not transliteration, so probably my first comment applies

1 Like
17

In fact this is one of the things GPL3 tries to address.

In general, as far as user freedom is concerned, MIT is fine. I'd reach for the GPL if I wanted to have more control over how the code is distributed.

18

As I understand it, GPL2 and 3 are the same in their intent, though 3 is more explicit. Are you potentially confusing GPL3 with Affero GPL?

1 Like
19

As I understand it, GPL2 and 3 are the same in their intent, though 3 is more explicit.

Yes. The main new aspect of GPL v3 is that it addresses the issue of software patents. Indeed it does not impose a requirement to publish the source code of any derivative works published as a web service, as the AGPL does.

2 Likes
20

I think the uutils is not a reimplementation of the coreutils written in Rust, but an implementation of the Unix core utilities written in Rust. To my understanding, such software can be licensed under any license. So I think it is unnecessary to relicense the uutils from the MIT License to the GPL.

21

Have you tried to open their repo, at least? First line there:

uutils coreutils is a cross-platform reimplementation of the GNU coreutils in Rust. While all programs have been implemented, some options might be missing or different behavior might be experienced.

They are very explicitly duplicating GNU coreutils. But that doesn't mean they are copy-pasting code from GNU coreutils (this wouldn't make much sense since C and Rust are very different languages).

1 Like
22

I'm not really interested in the wider debate, but just saying: reimplementing an API/interface in a different language is something no one in FOSS wants to argue for being a derivate. This is the core of Oracle vs. Google, where Oracle tried to argue that Google violates their copyright by reimplementing the Java standard interfaces and lost.

If API/interfaces can be copyrighted, uutils would be in violation of coreutils. But so would also be every GPL implementation of other, proprietary APIs. No one really wants to open that can of worms.

If they cannot, I don't see how uutils is an issue. While it is certainly true that the GPL gives the user more freedoms (particularly the right to request the source of what they use), BSD equivalents to all of those tools exist and have practically not impacted user rights much.

8 Likes