bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sam Roberts
Subject: Re: --lock-flags now configurable, and some mu_argp reorg
Date: Fri, 12 Apr 2002 00:53:01 -0400
User-agent: Mutt/1.3.16i

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.

OK, so the current situation is:

- non-GPL apps can use mailbox/*

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

I have a few questions. Can 

mail.local is GPL, so it cannot call an LGPL or BSD licenced
library, or can it?

> > 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?

> 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.

Ouf, this seems a problem.

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

> > No objections to the ~/.mailutils as a directory, then?
> 
> Of course, no. It's a splendid idea.

Ok, sorry for losing the .mu.

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]