[hnlmorg]

What license would that be? GPLv3 for GNU? GPLv2 for busybox? Or BSD for Toybox (Android)

Or BSD/ISC for FreeBSD, OpenBSD, macOS etc coreutils? All of which also have subtly different implementations from each other.

Or maybe you are talking about other UNIXs like CDDL for OpenSolaris?

Or perhaps you meant a proprietary license like Solaris, AIX, HP-UX, Tru64 UNIX and so on?

Or maybe we just agree that there isn’t a standard license for coreutils and developers should be free to chose to license their own code however they wish?

[DaSHacka]

I think the obvious answer is whatever tool you're attempting to replicate/supplant, you should use the same (or a compatible) license.

The issue is there's a massive leap between GPLv3 and MIT, even something like GPLv2 or anything else is better than MIT or public domain-tier licenses.

[burntsushi]

> I think the obvious answer is whatever tool you're attempting to replicate/supplant, you should use the same (or a compatible) license.

Is this really obvious? Did GNU coreutils do this for the project it was attempting to replicate/supplant?

> even something like GPLv2 or anything else is better than MIT or public domain-tier licenses

That's an opinion, not a fact.

[DaSHacka]

> That's an opinion, not a fact.

Except on average, how often do GPL projects get forked and modified without the changes getting released to the public versus with MIT projects? Which one benefits end users more?

[hnlmorg]

Happens all the time; even with GPL projects.

Technically with GPL, you only need to provide the source if requested. You don't specifically need to publish those changes ahead of time. And as it happens, some businesses don't even share the source when requested.

[burntsushi]

Except what? Do you actually have data?

Also interesting your silence about my other point. Tell me, did GNU coreutils copy the license of its ancestor?

[hnlmorg]

> I think the obvious answer is whatever tool you're attempting to replicate/supplant, you should use the same (or a compatible) license.

But there isn’t a standard license for coreutils, as I’ve demonstrated.

And worse to your point is that literally only one implementation of coreutils is GPLv3. So by your logic “rewrite in rust” projects shouldnt be GPL-licensed.

> The issue is there's a massive leap between GPLv3 and MIT, even something like GPLv2 or anything else is better than MIT or public domain-tier licenses.

Actually MIT is closer to what the term “public domain” means than GPLv3 is.

But either way, you’re arguing preference as fact. And your preference here is basically just a license flame war. I thought the community had evolved passed this pettiness.

[DaSHacka]

> But there isn’t a standard license for coreutils, as I’ve demonstrated.

There is for the specific coreutils they're attempting to replicate the behavior of though. They're directly targeting the GNU coreutils.

> Actually MIT is closer to what the term “public domain” means than GPLv3 is.

Yeah, that's the problem with it.

> But either way, you’re arguing preference as fact. And your preference here is basically just a license flame war. I thought the community had evolved passed this pettiness.

Is it really pettiness if one license allows for Elasticsearch situations and the other keeps the software and its derivatives free for people to use? Go and try to argue that the Linux kernel should be relicensed as MIT, surely the license doesn't matter at all and had no impact whatsoever on how things got to the point they are now. It's just pettiness, right?

[hnlmorg]

> There is for the specific coreutils they're attempting to replicate the behavior of though. They're directly targeting the GNU coreutils.

In the case of uutils coreutils specifically, sure. But that's not universally true for every RiR (Rewrite in Rust) project.

> Is it really pettiness if one license allows for Elasticsearch situations and the other keeps the software and its derivatives free for people to use?

GPLv3 wouldn't prevent ElasticSearch situations. They had to create a new license to solve that.

The problem with ElasticSearch was that AWS were making money running ElasticSearch without financially contributing ElasticSearch. There's nothing in GPL that prevents that. If there were, then nobody would be running Linux servers ;)

> Go and try to argue that the Linux kernel should be relicensed as MIT

Why would I argue that when there are plenty of kernels that are BSD licensed? If I cared about software licenses, then I'd use one of them instead.

> surely the license doesn't matter at all and had no impact whatsoever on how things got to the point they are now. It's just pettiness, right?

It's petty because you're complaining that developers should not be free to choose the software license they want for their own software projects because of an ideological complaint you have based around a misunderstanding of GPL.