Re: c-ctype, inttostr, intprops module license

[Yoann Vandoorselaere]

On Wed, 2006-11-15 at 21:33 +0100, Jim Meyering wrote:
> Simon Josefsson <address@hidden> wrote:
> > Yoann Vandoorselaere <address@hidden> writes:
> >
> >> warning: getaddrinfo is LGPL but depend on intprops which is GPL
> >> warning: inttostr is LGPL but depend on intprops which is GPL
> >
> > Jim, Paul, is it possible to have intprops be under LGPL?  The
> > alternative solution I see is to revert the patch for getaddrinfo that
> > made it use inttostr (which needs intprops), and use sprintf instead.
> 
> Here's a work-around: remove the inclusion of intprops.h
> and add a simpler, slightly pessimistic definition instead:
> 
> #define INT_BUFLEN_BOUND(t) ((sizeof (t) * CHAR_BIT) * 146 / 485 + 1 + 1)

If that's the way we're going to fix LGPL modules dependencies to GPL
modules, I'd like to ask if you volunteer to fix the others 37 invalid
dependencies. ;-)

Seriously, don't you think that tackling the problem this way will
result in code duplication, dependencies nightmare, more bugs, and a
harder to maintain project?

As an example of such a failure, the fts-lgpl module has 18 dependencies
to GPL modules... The GPL fts modules has 23 dependencies to other GPL
modules. In the end the fts-lgpl is a failure and bring more complexity
to the code.

>From an LGPL library maintainer point of view, this is also kind of
frustrating: I'm not sure if it also happened to Simon with Gnutls, but
I can remember many time where I updated GnuLib only to find out that
some existing LGPL modules were now in broken state due to newly added
GPL dependencies. 

You're then left with the choice of reverting to an older (and hence
more buggy) version of GnuLib, stop using the broken module and develop
your own instead, or raising the issue on the Gnulib mailing list in the
hope that the problem would be fixed quickly. 

Considering the above reaction, and unless we can find a technically
viable way of fixing the problem, maybe removing the Gnulib --lgpl
feature should be considered (although I really don't like that idea).
Maybe then an LGPL version of Gnulib should be forked from the current
LGPL module base.

-- 
Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies
Tel: +33 (0)8 70 70 21 58                  Fax: +33(0)4 78 42 21 58
http://www.prelude-ids.com