Re: --lock-flags now configurable, and some mu_argp reorg

[Alain Magloire]

> 
> Quoteing address@hidden, on Thu, Apr 11, 2002 at 06:46:55PM +0300:
> > 
> > > mailutils/COPYING is the LGPL
> > 
> > No, it is not. First stanza from mailutils/COPYING is:
> > 
> >                     GNU GENERAL PUBLIC LICENSE
> > 
> > It's plain GPL
> 
> Oops, sorry for the confusion, my COPYING is:
> 
>                   GNU LESSER GENERAL PUBLIC LICENSE
>                        Version 2.1, February 1999
> 
> The wrong one got there, somehow.
> 

There is a COPYING.LIB too.

> OK, so the current situation is:
> 
> - non-GPL apps can use mailbox/*

non-GPL __and__ GPL apps can use mailbox/* if they
respect the license of mailbox/*.

> - non-GPL apps cannot use the mu_argp_parse() configuration
>   mechanism, which includes sieve.

Yes, if they respect the license of mu_argp_parse().

> I have a few questions. Can 
> 
> mail.local is GPL, so it cannot call an LGPL or BSD licenced
> library, or can it?

Yes, it can. 

> > > mailutils/mailbox is LGPL
> > 
> > Yes, it is, except md5-rsa.c The md5-rsa license is incompatible with
> > both GPL and LGPL, since it allows "copy and use [of] this software",
> > but does not allow modifying it. (By the way, I have had certain problems
> > due to this module in Radius project and had to get rid of it in order
> > for the whole package to fall under GPL. I seem to have discussed these
> > issues with Alain).
> > 
> > > lib/*.c EXCEPT mu_argp.c is LGPL, sorry, I assumed all of lib/* was
> > > under the same licence.
> > [...]
> > > So it looks like it isn't possible to use mu_argp_parse under LGPL.
> > 
> > Here's a list of modules from lib which are GPL-ed:
> > 
> > argcv.c
> > basename.c
> > fnmatch.c
> > getopt.c
> > getopt1.c
> > malloc.c
> > md5.c
> > mu_argp.c
> > mu_dbm.c
> > realloc.c
> > strcasecmp.c
> > xmalloc.c
> > xstrdup.c
> > xstrtol.c
> 
> Some of these look like they came from GNU libc. Does this mean we can
> replace them with a LGPLed version recopied from libc?

Sure if they are better and portable.  And if they are use somehow for
mailutils/mailbox/*  except for strcasecmp() which any modern OS should
have mailutils/mailbox/* does not make use of any above.  hmm possibly
fnmatch() .. I will have to check.

> > I'm not a lawyer, but as far as I know the "stronger" (i.e. stricter)
> > license takes precedence over the "weaker", so the whole lib/ should
> > be assumed to fall under GPL. I may be wrong, though...
> 
> I don't know if the whole library comes under the GPL, but certainly
> any functions in lib/ or in mailutils/ that call GPLed code must themselves
> be GPLed.

If a program doing linking with funtions provide by mailutils restricts itself
to mailutils/mailbox/* and mailutils/include/*  it will not be covered by GPL.
But all the terms of LGPL however apply.

> Ouf, this seems a problem.
> 

I do not see any.

> Will we have to rewrite as LGPL or find LGPLed versions of GPLed library
> functions?

Sure but Why?  We made an effort to keep mailutils/{mailbox,include}/* clean and
LGPL(except the fuzzy surrounding md5-rsa.c)

Most commercial vendors do not have any problem using GPL applications, for
example gcc, binutils etc .. are all GPL.  I do not see any problems with GPL
applications.

Is the problem sieve being BSD style and linking with mu_argp_parse() will
make it fall under GPL?  Do you prefer sieve to be under BSD style
license?  in that case you will have to be carefull to what sieve link.  Linking
with functions from mailutils/mailbox/* will not make sieve GPL.