[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:1.9.1.9) 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
signature.asc
Description: OpenPGP digital signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Matahari] [PATCH] Adding gnulib to our build environment.,
Eric Blake <=