4 ms·

Your sarcasm aside, GNU doesn't hold the exclusive right to make the coreutils, nor the demand to put them under GPL. After all, they're just an implementation

Your sarcasm aside, GNU doesn't hold the exclusive right to make the coreutils, nor the demand to put them under GPL. After all, they're just an implementation of the POSIX spec (which to be fair tries to implementation match) and non-GPL coreutil utilities do exist (Both OpenBSD and FreeBSD for example have their own set of coreutils that are well, BSD licensed.)

quickthrower2 3y ago
It isn't about that though. Of course GNU doesn't hold that right, who said they did?
- noirscape 3y ago
  Even then I think the amount of people who care about MIT vs. GPL isn't large enough to be relevant. "Communities" (really, just distro maintainers, I don't think most people will install their own coreutils) aren't really that aligned to the GPL as the parent likes to imply they are (the only real license alignment usually is "no proprietary if we can help it", which makes GPL vs MIT equal and probably even leans slightly towards MIT because that permits more functional systems in restrictive environments.) A distro's choice will probably come down to feature completeness, safety down the line and ease of maintenance. In that regard, uutils is a much scarier thing for GPL adherents than the coreutils, which suffer from the classic GNU Project bloat problems as well as being written in C, neither of which will ever be fixed (due to structural GNU Project reasons as well as it just being a 3 decades old software project.)
Diti 3y ago
Where can one read the part of POSIX which describe Coreutils? I always thought those were just GNU tools.
- noirscape 3y ago
  Just check the spec itself. It pretty much describes the expected commandline syntax and behavior for commands the coreutils provide[0]. GNU coreutils is on its own a superset of a part of the POSIX spec (they started as rewrites of several Unix utilities), which mostly means that they added a bunch of extra flags and options. The other half of this is GNU bash which includes the non-command parts of POSIX such as shell syntax. POSIX itself meanwhile is basically a reverse spec (very much like how the C standard isn't really a standard, it's just a collective set of rules all notable C compilers follow); it was made to unify all the various Unix offshoots that were being developed and define a common set of commandline utilities and rules that they all shared. (Nowadays, that's mostly the BSDs, Linux and MacOS. Windows is the only notable OS that doesn't really do anything with POSIX besides a few aliases.) [0]: See for example the POSIX reference for cp and you'll see it's pretty similar to the GNU cp manpage - https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c...
- ksherlock 3y ago
  The open group documentation (which is the source of truth) is also available as manual pages (via the Linux man-pages project) so you can access them from your terminal, eg `man 1p mv`. On ubuntu/debian, they're in the manpages-posix (1p) and manpages-posix-dev (7p/3p) packages. https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/man-pages-posix/ https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/man...

quickthrower2 3y ago

It isn't about that though. Of course GNU doesn't hold that right, who said they did?

noirscape 3y ago
Even then I think the amount of people who care about MIT vs. GPL isn't large enough to be relevant. "Communities" (really, just distro maintainers, I don't think most people will install their own coreutils) aren't really that aligned to the GPL as the parent likes to imply they are (the only real license alignment usually is "no proprietary if we can help it", which makes GPL vs MIT equal and probably even leans slightly towards MIT because that permits more functional systems in restrictive environments.) A distro's choice will probably come down to feature completeness, safety down the line and ease of maintenance. In that regard, uutils is a much scarier thing for GPL adherents than the coreutils, which suffer from the classic GNU Project bloat problems as well as being written in C, neither of which will ever be fixed (due to structural GNU Project reasons as well as it just being a 3 decades old software project.)

Diti 3y ago

Where can one read the part of POSIX which describe Coreutils? I always thought those were just GNU tools.

noirscape 3y ago
Just check the spec itself. It pretty much describes the expected commandline syntax and behavior for commands the coreutils provide[0]. GNU coreutils is on its own a superset of a part of the POSIX spec (they started as rewrites of several Unix utilities), which mostly means that they added a bunch of extra flags and options. The other half of this is GNU bash which includes the non-command parts of POSIX such as shell syntax. POSIX itself meanwhile is basically a reverse spec (very much like how the C standard isn't really a standard, it's just a collective set of rules all notable C compilers follow); it was made to unify all the various Unix offshoots that were being developed and define a common set of commandline utilities and rules that they all shared. (Nowadays, that's mostly the BSDs, Linux and MacOS. Windows is the only notable OS that doesn't really do anything with POSIX besides a few aliases.) [0]: See for example the POSIX reference for cp and you'll see it's pretty similar to the GNU cp manpage - https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c...
ksherlock 3y ago
The open group documentation (which is the source of truth) is also available as manual pages (via the Linux man-pages project) so you can access them from your terminal, eg `man 1p mv`. On ubuntu/debian, they're in the manpages-posix (1p) and manpages-posix-dev (7p/3p) packages. https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/man-pages-posix/ https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/man...