Re: Request to relicense hash gnulib module to LGPLv2+

[Eric Blake]

[dropping libguestfs]

On 09/12/2013 10:51 AM, Paul Eggert wrote:
> Eric Blake wrote:
>> It may be time to ask rms if the FSF can do
>> the relicensing, rather than our current policy of tracking down all
>> contributors and asking them to use their grant-back clause of their FSF
>> copyright assignment as our backdoor of not having to involve the FSF.
> 
> It wouldn't hurt to ask rms this once, but
> I wouldn't want to bother him with minor requests
> like this every time they comes up.  We have
> a general guideline that it's ok to relicense
> gnulib libraryish code using the LGPL,
> and all that's arguably needed is for rms
> to review the guideline.

Ideas for such a guideline:

Relaxing a license from GPLv3+ to LGPLv3+, and/or from LGPLv3+ to
LGPLv2+, is okay if:

The function with the license being changed is already available on a
GNU system under the looser license (for example, any gnulib function
that is also present in glibc).

For modules not mirroring glibc: Relaxing the license will not expose
libraries to code that will call exit() on failure (thus, xalloc would
never be relicensed as LGPL).  It is possible to modify some modules
that currently use xalloc to provide a mode of operation where they are
safe for library use; where the modified .c file can then be part of
separate modules.  For example, in the past, we have split 'dirname' vs.
'dirname-lgpl' distinguished by whether failure will exit() or return
NULL to the caller.

For any license change, the request is made to the bug-gnulib list and
cc'd to module owners, to allow for any rebuttal (that is, the request
has to be publicly archived, with enough consent on list explaining why
the list agreed to the action, rather than something done in private).



Anything else we should add to to this list before presenting it to rms?
 I agree that if we have a documented policy in place for license change
requests, and rms/FSF agree to that policy, then we do not need to
involve rms on every individual request when it already fits in with the
policy.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature