[vox-tech] writing free getopt, ran into a dilemma...

vox-tech@lists.lugod.org vox-tech@lists.lugod.org
Mon, 1 Apr 2002 03:56:40 -0500


Micah,

  I'm going to join the last two posts into one reply to make
things easier.


On Sun, Mar 31, 2002 at 12:47:59AM -0800, Micah Cowan wrote:
> On Sat, 2002-03-30 at 04:45, msimons@moria.simons-clan.com wrote:
> > On Thu, Mar 28, 2002 at 09:13:19AM -0800, Mark K. Kim wrote:
> > > The one I tried to link statically on Windows one time said it was GPL,
> > > but according to Micah it's apparently LGPL with misdocumentation. :P
> >
> >   readline is GPL, getopt is LGPL... maybe some maintainer got confused?
>
> getopt's license would seem to be debatable - the sourcefile itself
> claims to be plain ol' GPL, though the accompanying, seperate license
> file claims LGPL.

  I admit I didn't check the source files the first time, because 
logically it *MUST* have the LGPL if it is linked into *the* libc
that practically every binary on a Linux system uses.  I'm not
much for logic proofs but I think this could be a proof by 
contradiction:
  If getopt used the GPL, then everything linked to it must also 
(meaning the rest of libc), and anything linked to that (including 
dynamically linked) would have to... thus every binary that runs 
on a Linux system is GPL'd.  Time to contact Oracle about their
OCI library...
  Well that was fun, now back to reality.  The above demonstrates
the 'viral license' concept microsoft whines about.


  Since I'm generally bad at proofs a source to backup that idea
that everything linked to a GPL thing must also have a GPL license... 
comes from the preamble of the LGPL where it describes the differences 
between itself and the GPL.

/usr/share/common-licenses/LGPL
#   When a program is linked with a library, whether statically or using
# a shared library, the combination of the two is legally speaking a
# combined work, a derivative of the original library.  The ordinary
# General Public License therefore permits such linking only if the
# entire combination fits its criteria of freedom.  The Lesser General
# Public License permits more lax criteria for linking other code with
# the library.


  So we have another reference problem... what source code tarfile
(or whatever) did you find the GPL attached to getopt.c?

  I checked my copy of source which I got via "apt-get source glibc"
with timestamps shown [way] below.  Both my header and source files have
references to the 'GNU Lesser General Public License':

glibc-2.2.5/posix/getopt.c
#    The GNU C Library is free software; you can redistribute it and/or
#    modify it under the terms of the GNU Lesser General Public
#    License as published by the Free Software Foundation; either
#    version 2.1 of the License, or (at your option) any later version.

  Stallman playing his word games renamed the 'Library General Public
License' to the 'Lesser General Public License' I suspect in an attempt
to make it sound more distasteful... he may have had other reasons,
regardless they are both the 'LGPL' we have been talking about.


[...okay onto the second post]

On Sun, Mar 31, 2002 at 12:40:30AM -0800, Micah Cowan wrote:
> > > Intermixing options with arguments is a GNU
> > > extension, and GNU pulls some mildly dirty tricks to get it (such as
> > > permuting argv, despite the fact that it's elements are declared const).
> >
> > Here is what I believe the valid declarations to be (these from ANSI C):
> >   int main(void);
> >   int main(int argc, const char **argv);
>
> No, the second shouldn't have the "const".
>
> > POSIX adds the following one additional main:
> >   int main(int argc, const char **argv, const char **envp);
>
> This is a standard UNIX convention, but is not POSIX (at least, I can't
> find it).

  Okay so I've now stumbled on a copy of the ISO draft standard, 
dated about the middle of January 1999.  Thanks for the link,
I'll keep that in mind if I ever need the 'real thing'.

  I agree 100% const is not part of main in the standard.

However, I found that 
  int main(int argc, char **argv, char **envp);
is listed as a 'common extension' it appears that the ISO rule is
extensions which can not cause a valid ISO C program to break when
compiled in that environment are allowed by the standard.  (In
my opinion since main with envp isn't defined by the standard the 
programs that use that form of main are not ISO C programs even through
every other line may be ISO C ;)

c9x-draft:
#       J.5  Common extensions
#
#       [#1]  The  following  extensions  are  widely  used  in many
#       systems, but are not portable to all  implementations.   The
#       inclusion  of  any  extension  that  may  cause  a  strictly
#       conforming   program   to   become   invalid   renders    an
#       implementation  nonconforming.   Examples of such extensions
[...]
#       J.5.1  Environment arguments
#
#       [#1] In a hosted environment, the main function  receives  a
#       third  argument,  char  *envp[],  that  points  to  a  null-


> > POSIX declares:
> >   int getopt(int argc, char * const *argv, const char *optstring);
>
> More or less.
>
> > However the GNU documentation declares:
> >   int getopt(int argc, char **argv, const char *optstring);
>
> Mine sure doesn't.  Mine says "char * const *argv".  So does the
> header.  I have never seen a Linux system with a different declaration
> than this, so now you have my curiosity piqued, as to what system you're
> running.  

  I'm sorry I posted the documentation reference in another message,
here it is again... 
  http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_514.html#SEC524

  Since the GNU people officially don't maintain manpages anymore in favor
of their "texinfo pages", I was referring that.  I even went through
the "effort" of finding the URL on gnu.org's own machines and verified
the content of the small sections I cared about with the source, so that 
it wouldn't be an old out of date copy I was quoting.  :)

msimons@gabriel:~/src/glibc-2.2.5/manual> ls -l getopt.texi
-rw-r--r--    1 msimons  users       11892 Nov 10 09:16 getopt.texi

> The manpage is dated 8 May 1998, ships with RH 7.1; my glibc
> is currently 2.2.4.  BTW, the manpage gives a reason as to why this is
> the case, I just think it's a very ugly way of doing it.

  Oh yes, I run Debian and my man page is dated the same as yours.
However, we are using glibc 2.2.5.  ;)
  When one installs the 'glibc-doc' package one gets a bunch of html 
which is based off of the texinfo pages which is deemed to be the
official documentation.

> >   The one valid bug I see is that GNU getopt.h and getopt.c both use
> > 'char * const *argv' and that conflicts with the documentation
> > of 'char **argv'.
>
> But not with my documentation, obviously. So it looks like they
> originally had it your way but later changed it for compatibility with
> certain other systems (although why such compatibility is necessary with
> *BSD escapes me - compatibility with POSIX would be a good reason;
> libiberty might be another).

  The modification order may very well be, although oddly the time order 
of file change in the upstream source is header, source, documentation.  ;)

msimons@gabriel:~/src/glibc-2.2.5> 
  ls -l posix/getopt.c posix/getopt.h manual/getopt.texi -tr
-rw-r--r--    1 msimons  users        6458 Sep  7  2001 posix/getopt.h
-rw-r--r--    1 msimons  users       34090 Oct 27 07:21 posix/getopt.c
-rw-r--r--    1 msimons  users       11892 Nov 10 09:16 manual/getopt.texi

    Cheers,
      Mike