On 04/04/2013 06:58 AM, Philipp Thomas wrote: > I'm trying to package git-merge-changelog as a stand alone tool for openSUSE > but the tool itself is GPL 2.0 or later while some parts of gnulib are GPL > 3.0 or later and so our legal folks are blocking its checkin. > > My problem is determining whether git-merge-changelog will in all possible > cases only use gnulib components licensed under 2.0+. Is this possible at > all?
Sorry, but checking the modules used by git-merge-changelog: $ ./gnulib-tool --extract-license git-merge-changelog $(./gnulib-tool --extract-dependencies git-merge-changelog) GPL LGPLv2+ LGPLv2+ LGPLv2+ GPL LGPL LGPLv2+ GPL GPL GPL GPL GPL GPL GPL GPL LGPLv2+ LGPL GPL LGPLv2+ LGPLv2+ shows a large dependency on GPLv3+ (the gnulib documentation mentions that "GPL" as a license means the current GPL version or later, in this case GPLv3+). Gnulib intentionally avoids GPLv2+ except in the case of LGPL compatible code (that is, only modules labeled LGPLv2+ or LGPL [LGPLv3+] can be used in GPLv2 code). We are unlikely to relicense git-merge-changelog to a more permissive license, because we feel that there is value in enforcing GPLv3+ if something is worth protecting under the GPL at all. In particular, one of the dependencies of git-merge-changelog is xalloc, which will never be licensed as LGPL, because it is inappropriate for a library to call exit(); and rewriting git-merge-changelog to avoid the use of xalloc just for licensing reasons is counterproductive. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
