Hacker News Reader

Comment by tyrion | Hacker News Reader

The goal of modernizing coreutils is great, and doing it in rust is even better. However, it makes me very sad that this is licensed under the MIT licence.

Being licensed under the GPL is an essential part of the GNU project and their philosophy. Of course everyone is free to do as they please. However, IMHO, if one appreciates the GNU project and the ideals it stands for, then, maybe, it could be preferable not to rewrite parts of it under weaker licences that go directly against their mission!

View on HN

Your argument seems to imply that GNU was the progenitor of the utilities. A quick sample of the first 10 utilities from the first column of http://maizure.org/projects/decoded-gnu-coreutils/ on my machine showed 80% of the utilities were copied from existing sh utilities. Sure, GNU has added features, but there is nothing unseemly about creating new utilities using a different licence that are largely compatible - that is exactly how GNU coreutils came to life in the 90s.

arch - GNU

chgrp - Descended from chgrp introduced in Version 6 UNIX (1975)

comm - Descended from comm in Version 2 UNIX (1972)

dd - Descended from dd introduced in Version 5 UNIX (1974)

du - Descended from du introduced in Version 1 UNIX (1971)

factor - Descended from sort in Version 4 UNIX (1973)

head - Descended from head included in System V (1985)

join - Descended from join introduced in Version 7 UNIX (1979)

ls - Spiritually linked with LISTF from CTSS (1963)

mktemp - GNU

Where does their argument imply that GNU was the progenitor of those utilites?

I think he/she commented on the wrong parent comment, it makes a lot more sense about the current top comment

>Being licensed under the GPL is an essential part of the GNU project and their philosophy.

Having "won the desktop from Windows" and "finished a next-gen OS (Hurd)" was also part of that plan, but it didn't really pan out, did it?

I'm glad for MIT software since I can use it in more places I can use GPL (which companies often wont touch, in it's later license version).

Do the places you work forbid the use of Linux or the GNU Coreutils?

In what context are you using Rust Coreutils? Windows? MacOS? BSD?

>Do the places you work forbid the use of Linux or the GNU Coreutils?

They allow them. I had cases where clients forbade some GPL code (banks, etc) - worse with GPL3.

They'll stop doing that if most code is GPLv3. If most code is GPLv3, we're all better off – but while people are still prepared to work around GPL-rejecting companies, those companies can still reject the GPL.

It's the tragedy of the Commons.

The GPL license usage is falling, and even Linux is GPLv2 and rejects GPLv3. Some Linux code is dual licenses GPLv2 and MIT.

ApacheV2, MPL, MIT, ISC and BSD licenses are gaining in popularity.

>They'll stop doing that if most code is GPLv3

No, they'll just find a MIT/BSD or probably proprietary alternative.

From a legal perspective, what is the advantage in a proprietary alternative?

E.g. they don't get to sue you for using it and not opening your own software that links to it, since you can buy a license allowing you to do just that.

That's also why some GPL software is dual licensed. GPL for the masses, and a proprietary license allowing you to do whatever without needing to follow the GPL if you can afford it.

Ah! You mean a special kind of proprietary license for them. That makes sense.

I thought you meant they would just use copyrighted code that wasn't under a GPL (which would be just as illegal and probably more dangerous in terms of enforcement).

Do they forbid using the code, or incorporating the code into their own works? I hear of places forbidding the use of GPL code (even in-house) where they use proprietary software like Microsoft Word with no worries.

Because Microsoft doesn't demand you open source your plugins. GNU software might force you to.

Corporations choosing to not use GPL software mostly don't know enough about it, to know it's ok. So they ban it outright.

> GNU software might force you to.

No, they might not. Just like Microsoft, they might demand that you don’t release your plugins. Addidionaly, GNU software gives you the alternative of releasing your plugins. But you don’t have to, and they can’t make you do it.

Yeah I really agree here. Especially when it comes to coreutil implementations. I've seen multiple implemented under MIT/BSD and it always makes me a little sad.

I have access to an incredibly high quality easy to use router firmware in the form of OpenWrt by virtue of GPLd coreutils. I wish FOSS developers weren't so afraid of it these days

Agreed. It would also be good of this Rust project to state that all of the utils are original works and no one has peeked at the C sources. Perhaps the maintainers of the C versions should do the same in reverse.

https://github.com/uutils/coreutils/search?q=gnu "This is the way it was implemented in GNU split." i dunno maybe there are cases where they copy more than behavior... but interesting to look through

There are more examples, here is one:

  // a few global constants as used in the GNU implementation

It's pretty easy to ask someone "Hey, can you go take a look at GNU split and see how they handle this case?" and then implement your own clean-room solution afterwards.

Alternately, to solve the problem yourself and mention it to someone and have them say "that's how GNU split does it, so why not?"

Isn't that, by definition, not a clean-room solution?

‘Clean-room reverse engineering’ refers to the practice of having one person look at disassembled source code, spec sheets, actual behaviour, etc. of some program; describe that behaviour to a second person; and having the second person implement the described behaviour.

https://en.wikipedia.org/wiki/Chinese_wall#Reverse_engineeri...

Ah, that's interesting! I didn't know that was a sufficient insulation of IP.

yea seems pretty easy then right, sounds like no source that is available for eyes to see is safe from 'clean room reverse engineering'

> Perhaps the maintainers of the C versions should do the same in reverse.

Nitpick: they don't need to, they can just attribute the Rust developers if needed. They can also just take MIT code and publish it under GPL (reverse is not true).

Taking MIT code and re-licensing it under the GPL will cause a huge uproar:

http://undeadly.org/cgi?action=article&sid=20070913014315

I'm not sure that is even legal.

It's doable if you can get OK from every single copyright owner of the source files.

LLVM did it. Switching from "University of Illinois/NCSA" to "APL 2.0".

But not without some big discussions.

I didn't mean re-licensing it - the parts that are under MIT stay under MIT, but the patches on it have a different license. That is completely legal and license doesn't forbid this. (ianal, yadda yadda...)

A similar thing happened to OpenOffice / LibreOffice: [0]

> OpenOffice uses the Apache License, whereas LibreOffice uses a dual LGPLv3/Mozilla Public license.

> For some legal reasons, then, anything OpenOffice does can be incorporated into LibreOffice, the terms of the license permit that. But if LibreOffice adds something, take font embedding, for example, OpenOffice can’t legally incorporate that code.

[0] https://hackaday.com/2020/11/02/openoffice-or-libreoffice-a-...

Richard Stalman and others that believe the GPL is generally the best license are not against ever using the MIT license. Stalman has been willing to be pragmatic and support tactical choices of other licenses besides GPL when licensing.

So it is worth having some deeper thoughts about what the implications are for different licenses of coreutils. When does using coreutils create a derivative work that requires GPL?

Tactical considerations exist, but even so, a copyleft license might have better long term results in promoting software Freedom. The FSF supported a non-copyleft license for Ogg Vorbis, because at the time it seemed reasonable that this was the best way to fight the (at the time) patent-encumbered MP3 format. But in practice it had little benefit:

"However, we must recognize that this strategy did not succeed for Ogg Vorbis. Even after changing the copyright license to permit easy inclusion of that library code in proprietary applications, proprietary developers generally did not include it. The sacrifice made in the choice of license ultimately won us little."[0]

[0] https://www.gnu.org/licenses/license-recommendations.html

I don't know when that was written, but vorbis is used pervasively today, including in proprietary applications.

I think this is more of a reflection of mainstream OSS culture in general. Rust development currently is heavily tied to proprietary services (e.g. GitHub required for contributions, issues, crates.io login, CI, etc., Discord and Slack communities rather than Matrix, Zulip) and likes to license things under MIT. I think the lack of awareness/care for the big picture of fighting for software freedom is simply not there just as it is missing from mainstream OSS culture. Because convenience and network effect are king.

You do have a point but in case you are saddened by this phenomena, let me just point out that we live in a VERY different age compared to when GNU coreutils were born. Nowadays you only get a few minutes -- or hours if you are lucky -- to answer a ton of fundamental questions like "where do we host code?" and "how do we communicate on this project?" or "how do we do CI/CD?" etc.

The people in the past had all the time in the world to tinker and invent. Maybe I am mistaken though, past is usually looked through rose-tinted glasses right?

But the fact remains: nowadays answering the above questions is beyond my pay grade: in fact it's beyond anyone's pay grade. Services like GitHub are deemed a commodity and questioning that status quo is a career danger.

I really do wish we start over on most of the items you enumerated. But I am not paid to do it. In fact I am paid to quickly select tools and never invent any -- except when they solve a pressing business need and are specific enough for the organization; in that case it's not only okay but a requirement.

Beyond anything else however, we practically have no choice. If I don't host a new company project on GitHub I'll eventually be fired and replaced with somebody who will.

I would also onto your point and say that one reason why Rust is easy to get into is because of the convenience that these semi-proprietary platforms provide.

We here on HN have both the time and ability to set up things like CLI Git, and Matrix. But for a new language, forcing people onto esoteric (& superior) platforms makes them less likely to use them.

It would be nice if Matrix and self-hosted Git were the default, but when acquiring users/programmers is your goal, Rust doesn't have that luxury.

Agreed. Maybe they will tighten things up in the future but when you are after adoption and getting as much help as you can, it's indeed a luxury to be morally idealistic.

That's a little harsh.

Rust uses Github, but could easily switch to a self-hosted platform if Microsoft became opposed to Rust's goals; (and yes, Microsoft is a Rust sponsor, but not an essential one). Cargo has support for alternate registries built in.

Some of community is on Reddit and Discord, but most technical discussion takes place on Discourse and Zulip. The official "user questions" forum is a Discourse instance. Most subcommunities forming around Rust projects use Zulip instances.

The Rust community uses proprietary services when convenient, but it's hardly dependent on them.

> easily switch

Disagree, just look at bors and the use of Azure CI. It would be a huge PIA to switch.

> hardly dependent on them

I wouldn't say hardly, I think it's more like kinda. GitHub's network effect is pretty strong. Compare the number of contributors to golang for example which is hosted on Google code.

> it could be preferable not to rewrite parts of it under weaker licences that go directly against their mission

+1. It's very sad to see user freedom being thrown away as a goal and replaced by software that becomes unpaid labor for FAANGs. Especially since the SaaS takeover.

GPL does not protect against SaaS provider creating derivative as there is no further distribution of binary or source code. Only AGPL (and other more strict licenses) addresses SaaS derivatives issue.

In the case of coreutils, there is really no issue with presence or absence of GPL. cp is just cp and nobody is going to hang a proprietary extension off the side.

I think people should be able to license under whatever they choose to license under. Diversity is good for the most part.

Reply on news.ycombinator.com