Bug: Not GPL. :-)

[pnathan]

Hi,

I love this project, but infrastructural software really should be under the GPL. It's very important that distributed software can be fixed by the end user, which the MIT licenses & friends doesn't require.

Please consider releasing as GPL.

Regards,
Paul

[bencook]

More importantly, as derivative works of the original C coreutils, this must be licensed under the GPL as well.

@bencook Why v2 but not v3?

[bencook]

@ivegotasthma It would be whichever the original program is licensed under.

[willneumob]

It's a complete rewrite of, a) some POSIX commands, and b) other utilities commonly used on *nix systems. There are already BSD-licensed implementations of most of these tools on FreeBSD. Please don't license this as GPL; GPL is significantly less "free".

[Cynede]

people please, don't start this holy war here, it's not constructive, first listen what owner think about this, if he don't mind then voting from contributors - there is just no other way

[pnathan]

@bencook - I would suggest demonstrating the "derivative work" claim - that is a legally binding claim placing requirements on the derivators. I support moving to the GPL but such a claim should be demonstrated. :-)

@willneumob LGPL is ideal for libraries, but I don't think it affects programs like this: the mandate would apply, and people aren't generally going to be using a libcoreutil (I think... I've never done so or seen it done in any sense, and I've been floating around the scene for > 10 years... if that means anything. ;) ).

[johnstorey]

For what it's worth, the first thing I checked was the license. Then I moved the project off my list of potential things to work on.

[willneumob]

@pnathan Well, for a shell script, they are similar to libraries. If I write an extensive shellscript making use of these programs, might I be forced to release my works? I'm not suggesting people would want to actually link it against their code as a library. L is for Lesser, not Library.

[Cynede]

@willneumob so people currently share all scripts which are using coreutils?

[willneumob]

@johnstorey Because of GPL or MIT? You're always free to fork the MIT version if that's what you wanted (as far as I understand the law)...

@Heather Well, no, but the coreutils project might technically be within their right to pursue action against someone who does not? I mean, what's the difference between a C developer using a library's API and linking against that library, and a shell script running these commands? It might be fine, and IANAL; just food for thought. I don't feel that strongly about it. But LGPL might allow more flexibility, while still requiring changes to this codebase itself to be shared.

@willneumob

Well, for a shell script, they are similar to libraries.

Uhh...no

If I write an extensive shellscript making use of these programs, might I be forced to release my works?

Read up on what the license says.

I'm not suggesting people would want to actually link it against their code as a library. L is for Lesser, not Library.

Please read the license and the wiki page for it.

[willneumob]

I guess LGPL is fairly specific about using shared libraries, so, you're right, it might not apply. I still stand by shell utilities being abstractly similar to libraries, as they are external binaries and the "API" is the command line interface and arguments to the program. But I give up :) It's really not my thing to have an opinion about as I haven't contributed code to this project. Much respect to those who have, and it's their opinions that should matter in this.

[yincrash]

I apologize for any inconvenience posting to HN has caused. I hope that the incoming interest and possible future contributions will outweigh any distress.