Re: HAVE_STDBOOL_H, AC_HEADER_STDBOOL, and AM_STDBOOL_H

[Russ Allbery]

(Please cc me on responses as I'm not a member of the bug-gnulib mailing
list.)

Simon Josefsson <address@hidden> writes:
> Ralf Corsepius <address@hidden> writes:

>> For real-world projects, gnulib often is not a viable alternative.

> Could you explain why?  There are several real-world projects that use
> gnulib, so I'm curious what the perceived reasons against it are.  I'm
> genuinely interested in the answer to the question, it is not just
> rethoric because I happen to disagree.

Most of the code in gnulib is covered by the LGPL.  All of my projects are
released under the MIT/X Consortium/Expat license or a two-clause BSD
license.  Including LPGL code in such a project is possible, but it's
rather annoying on multiple fronts: I have to include a long and complex
license that only applies to a small handful of files in the tree but has
the potential to confuse users, it's somewhat unclear with some small
gnulib modules to what extent they're really a separate library (in
particular, it's quite difficult to meet the LGPL requirements to allow
relinking with a modified version of the gnulib files), and it causes a
lot of mental overhead and analysis impact for anyone who wants to use my
software in other ways.

I release my software under those licenses precisely because I don't want
people to have to spend a lot of time thinking about how they can and
can't use my software.  I realize this is a philosophical difference, and
I do fully respect the goals of copyleft and am *not* opposed to copyleft.
I've just chosen to take an even more permissive approach for my
particular projects.  Incorporating LGPL-covered code like gnulib makes my
life considerably more complex for only marginal gain (I already have a
portability layer of my own that, while not as comprehensive, is
sufficient for my needs).

Autoconf is released under an excellent license for my purposes.  I know
that I can use any Autoconf macros in whatever way I need in BSD-licensed
software without any additional impact.

I'm *not* asking gnulib contributors to stop contributing to gnulib or
improving it.  People certainly can release code under any license they
choose.  I'm only asking that macros already included and working in
Autoconf continue to be maintained there at least in the sense that if
people contribute improvements, those improvements wouldn't be rejected
because the macro is obsolete and gnulib should be used instead.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>