[Top][All Lists]

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

Re: [Matahari] [PATCH] Adding gnulib to our build environment.

From: Eric Blake
Subject: Re: [Matahari] [PATCH] Adding gnulib to our build environment.
Date: Fri, 18 Jun 2010 08:49:05 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100430 Fedora/3.0.4-3.fc13 Lightning/1.0b2pre Mnenhy/0.8.2 Thunderbird/3.0.4

[adding bug-gnulib]

On 06/18/2010 05:46 AM, Daniel P. Berrange wrote:
> On Fri, Jun 18, 2010 at 01:39:27PM +0200, Andrew Beekhof wrote:
>> On Thu, Jun 17, 2010 at 4:57 PM, Eric Blake <address@hidden> wrote:
>> I think we just need to be careful about what modules we use,
>> otherwise we become gplv3+ by default right?
> There is a configuration option for bootstrap that tells it to restrict
> modules to those satisfying a particular license. eg, in bootstrap.conf
> you can add
>    gnulib_tool_option_extras="--gpl=2"

Right now, gnulib does not support GPLv2.  Or, put another way, some
gnulib modules are under LGPL (whether version 2 or version 3 depends on
the module), but all remaining modules under the GPL assume that GPLv3+
is good enough, since it tends to be final executables and not libraries
that will be using GPL.  Since you won't be linking a final executable
into another product, you might as well use the latest and greatest
license - the primary use case for LGPL instead of GPL is so that others
can link in your library without affecting their licensing.

Gnulib DOES provide --lgpl=2 (limit to modules that are LGPLv2+ only)
and --lgpl=3 (limit to modules that are LGPLv2+ or LGPLv3+ only).  I'm
not sure whether it is okay to link an LGPLv3+ library into a GPLv2+
app, but you are certainly safe sticking with --lgpl=2 if you choose not
to upgrade to GPLv3+.

But if you have a good use case for adding gnulib-tool --gpl=2, to keep
your app at GPLv2+ rather than upgrading to the latest and greatest, it
is probably something that gnulib can accommodate.  It's just that we
need a bit more explanation why you think sticking to GPLv2+ is in your
best interest.

> and it'll now refuse to pull in gplv3 modules. We use this in libvirt to
> restrict it even further, to only lgplv2+ modules 

True, but libvirt is a library specifically released under LGPLv2+,
while, if I understand correctly, matahari is an executable currently
released under GPLv2+.

And while we are at this, it would be nice to patch gnulib/users.txt to
list matahari as another client - welcome aboard!

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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