Re: --version output and license specifications

[Bruce Korb]

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 with the GPL
>     need not be mentioned.
>
>     I think such a standard, if specified clearly and precisely, could
>     catch on and be a step forward for the community.
>
> It seemed a reasonable idea to me, although more work :(.  I guess the
> output from emacs --version would then be something like this:
>
> GNU Emacs 21.3.1
> Copyright (C) 2002 Free Software Foundation, Inc.
> License: GNU GPL v2+
> This is free software. There is NO warranty; not even for
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  
>
> (Not sure that we still want to refer to the COPYING* files.)
>
> What do people think of such a thing as a GNU standard?  I see that
> --version output varies widely now ...
>
> To pursue this, I guess a next step would be to look at the list of free
> software licenses and come up with some abbreviations for the ones most
> widely used.  Anyone care to look into that?
>
> Thanks,
> Karl

Hi Karl,

Not being one who likes copying code around and keeping it current,
especially in light of the fact that what --version says is variable,
it would be nice from my perspective if two things were to happen:

1. there were a standardized, FSF/GNU supported "emit_version" procedure
2. --version were to take an optional argument that would tell that function
   to just emit the project version, or project version + some simple
   copyright/licensing information, or, finally, to be exhaustive in that
   information (secondary licenses, etc.)

99.99% of the time, I just want the basic "what version is this" question
answered, meaning it is now necessary to sed, grep and awk the output to
figure out what ought to be simple.

So, this "emit_version" thing would need interfaces that would describe
all the relevant information and the command line option setting.
If that makes enough sense to enough people, I'll write the thing.
I'd vote for making it public domain just in the vein hope that it
might get more widely adopted sometime over the next few decades.  :)

Cheers - Bruce