(Please cc me on responses as I'm not a member of the bug-gnulib mailing list.) Simon Josefsson <simon@xxxxxxxxxxxxx> writes: > Ralf Corsepius <ralf.corsepius@xxxxxxxxx> 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 (rra@xxxxxxxxxxxx) <http://www.eyrie.org/~eagle/> _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
