Re: --version output and license specifications

[EMAIL PROTECTED] (Karl Berry) writes: > I think it would be awfully dumb to ever make gnu.org != www.gnu.org > again (whether the same or different ip's). I agree. The URLs here are likely to be typed by hand and viewed by users, so the shorter the better, and it doesn't matter that much whethe

Re: --version output and license specifications

Number 1 is of course fully specified and would assume nothing. I think in this case this is most desirable. One resulting problem is figuring out/maintaining url's for other licenses. But I guess that's not exactly our problem, as Paul said. Maybe I will suggest both alternatives to rms

Re: --version output and license specifications

For GNU licenses, it might be simpler if the --version output merely referred to , Ok, I can buy that. So my sense is that what we want to propose to rms is this: hello (GNU hello) 2.1.90 Copyright (C) 2006 Free Software Foundation, Inc. License: GNU GPL v

Re: --version output and license specifications

Paul Eggert previously wrote: > "sort --version" could output something like this, say: > > sort (GNU coreutils) 6.2 > Copyright (C) 2006 Free Software Foundation, Inc. > License: GPL v2 . > This is free software. There is NO WARRANTY, to the extent >

Re: --version output and license specifications

[EMAIL PROTECTED] (Karl Berry) writes: > I very much doubt we can reliably maintain a url for each version of > each license. For GNU licenses, it might be simpler if the --version output merely referred to , as that will make the output shorter and the instructions for m

Re: --version output and license specifications

License: GPL v2 GNU GPL v2+ ... the + is very important. The important thing is the URLs, not the abbreviations. Yes, clearly there has to be something describing what the abbreviations mean. I'd prefer that to be a url, but it could also be in standards.texi. I don't know if rms wil

Re: --version output and license specifications

[EMAIL PROTECTED] (Karl Berry) writes: > (Not sure that we still want to refer to the COPYING* files.) I suggest using a URL instead; that's what several packages do now, and nowadays it is more convenient than a file and will explain the abbreviation well. "sort --version" could output somethin

Re: --version output and license specifications

1. there were a standardized, FSF/GNU supported "emit_version" procedure There's a function in gnulib, although I don't think it's a problem for programs to write their own. 2. --version were to take an optional argument that would tell that function It's only a few lines of text. I con

Re: --version output and license specifications

Karl Berry wrote: rms suggested going further. Here is his message (in its entirety): How about if we design a standard way of describing licenses and put the list on the second line. For instance, GNU GPL v2+ would describe Emacs. We could say that GPL-compatible licenses used wi

--version output and license specifications

I received a report from Texinfo users (Helge Kretuzmann and Norbert Preining, cc'd) that the --version output from info just said "GNU General Public License", and that this could be interpreted as meaning GPL version *1*. The texinfo tools' --version output comes from the GNU coding standards. S