Re: request for license change
On 07/19/2013 11:24 PM, Nikos Mavrogiannopoulos wrote: > Hello, > Would it be possible that the following modules are licensed under > LGPLv2.1+ instead of LGPLv3+? They are (conditionally) used by the > gnutls library and would be nice if we could avoid the LGPLv3+ switch. > > opendir > readdir > closedir Revisiting this request, since the glob module is also impacted (https://lists.gnu.org/archive/html/bug-gnulib/2013-09/msg3.html) > iconv_open-utf For this one, I'm not as sure. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Request to relicense hash gnulib module to LGPLv2+
On 08/28/2013 11:51 AM, Richard W.M. Jones wrote: > libguestfs (an LGPLv2+ library) uses the 'hash' module, which turns > out to be "GPL". > > Actually this happened because we started to use it in a separate > GPL'd utility program, but later on included this functionality in the > core library, copying the same code from the utility but not checking > the license of 'hash'. > > We'd therefore like to request that 'hash' is relicensed as LGPLv2+. > If this is not possible, we will have to rewrite the code, probably > implementing our own hash table, which would be a shame because hash > works well for our needs. > > Notes: > > - the code doesn't appear to call exit (it does call abort), and so > seems to be suitable for a library > > - hash-pjw which we also use is already licensed as LGPLv2+ > > - it looks like the original author was Jim Meyering (CC'd) Adding all other authors based on git history, to try and spur this along (Paul, Simon, Bruno, and myself). I give consent for the patches I've made. > > - the dependencies are all LGPLv2+ The fact that Bruno has been notably silent on this list for several months may be a problem; we have several outstanding requests for a looser license on these and other modules where Bruno has made non-trivial contributions. 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. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[PATCH] configmake: support new --runstatedir option
http://lwn.net/Articles/436012/ documents that many distros
are now preferring to use /run rather than /var/run for
storage of pid files and other per-process temporary files
that must not be cleaned out during arbitrary TMPDIR sweeps.
As such, the GNU Coding Standards were recently changed to
recommend a new configure option to make it easy to choose
this directory at configure time, and autoconf 2.70 will
support the new directory by default. This patch adds support
for propagating results of the new option (for new enough
autotools) or providing a sane default (for older autotools)
into C code.
* m4/configmake.m4 (gl_CONFIGMAKE_PREP): Substitute runstatedir
even if autoconf was too old to provide the command line option.
* modules/configmake (Makefile.am): Propagate it to .h file.
Signed-off-by: Eric Blake
---
Just as with the autoconf patch, I'm not pushing this gnulib
patch until the make-stds.texi change goes live.
ChangeLog | 7 +++
m4/configmake.m4 | 11 ---
modules/configmake | 3 ++-
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 0007e17..2145596 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2013-09-12 Eric Blake
+
+ configmake: support new --runstatedir option
+ * m4/configmake.m4 (gl_CONFIGMAKE_PREP): Substitute runstatedir
+ even if autoconf was too old to provide the command line option.
+ * modules/configmake (Makefile.am): Propagate it to .h file.
+
2013-09-09 Eric Blake
glob: fix compilation
diff --git a/m4/configmake.m4 b/m4/configmake.m4
index 823ffc0..330f98d 100644
--- a/m4/configmake.m4
+++ b/m4/configmake.m4
@@ -1,4 +1,4 @@
-# configmake.m4 serial 1
+# configmake.m4 serial 2
dnl Copyright (C) 2010-2013 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -7,8 +7,9 @@ dnl with or without modifications, as long as this notice is
preserved.
# gl_CONFIGMAKE_PREP
# --
# Guarantee all of the standard directory variables, even when used with
-# autoconf 2.59 (datarootdir wasn't supported until 2.59c) or automake
-# 1.9.6 (pkglibexecdir wasn't supported until 1.10b.).
+# autoconf 2.59 (datarootdir wasn't supported until 2.59c, and runstatedir
+# in 2.70) or automake 1.9.6 (pkglibexecdir wasn't supported until 1.10b,
+# and runstatedir in 1.14.1).
AC_DEFUN([gl_CONFIGMAKE_PREP],
[
dnl Technically, datadir should default to datarootdir. But if
@@ -43,6 +44,10 @@ AC_DEFUN([gl_CONFIGMAKE_PREP],
if test "x$localedir" = x; then
AC_SUBST([localedir], ['${datarootdir}/locale'])
fi
+ dnl Added in autoconf 2.70
+ if test "x$runstatedir" = x; then
+AC_SUBST([runstatedir], ['${localstatedir}/run'])
+ fi
dnl Automake 1.9.6 only lacks pkglibexecdir; and since 1.11 merely
dnl provides it without AC_SUBST, this blind use of AC_SUBST is safe.
diff --git a/modules/configmake b/modules/configmake
index 845e0f4..5a60f4f 100644
--- a/modules/configmake
+++ b/modules/configmake
@@ -11,7 +11,7 @@ gl_CONFIGMAKE_PREP
Makefile.am:
# Listed in the same order as the GNU makefile conventions, and
-# provided by autoconf 2.59c+.
+# provided by autoconf 2.59c+ or 2.70.
# The Automake-defined pkg* macros are appended, in the order
# listed in the Automake 1.10a+ documentation.
configmake.h: Makefile
@@ -27,6 +27,7 @@ configmake.h: Makefile
echo '#define SYSCONFDIR "$(sysconfdir)"'; \
echo '#define SHAREDSTATEDIR "$(sharedstatedir)"'; \
echo '#define LOCALSTATEDIR "$(localstatedir)"'; \
+ echo '#define RUNSTATEDIR "$(runstatedir)"'; \
echo '#define INCLUDEDIR "$(includedir)"'; \
echo '#define OLDINCLUDEDIR "$(oldincludedir)"'; \
echo '#define DOCDIR "$(docdir)"'; \
--
1.8.3.1
Re: Request to relicense hash gnulib module to LGPLv2+
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.
Re: Request to relicense hash gnulib module to LGPLv2+
I'm fine relicensing hash, I don't recall doing anything significant in it. /Simon Eric Blake skrev: >On 08/28/2013 11:51 AM, Richard W.M. Jones wrote: >> libguestfs (an LGPLv2+ library) uses the 'hash' module, which turns >> out to be "GPL". >> >> Actually this happened because we started to use it in a separate >> GPL'd utility program, but later on included this functionality in >the >> core library, copying the same code from the utility but not checking >> the license of 'hash'. >> >> We'd therefore like to request that 'hash' is relicensed as LGPLv2+. >> If this is not possible, we will have to rewrite the code, probably >> implementing our own hash table, which would be a shame because hash >> works well for our needs. >> >> Notes: >> >> - the code doesn't appear to call exit (it does call abort), and so >> seems to be suitable for a library >> >> - hash-pjw which we also use is already licensed as LGPLv2+ >> >> - it looks like the original author was Jim Meyering (CC'd) > >Adding all other authors based on git history, to try and spur this >along (Paul, Simon, Bruno, and myself). I give consent for the patches >I've made. > >> >> - the dependencies are all LGPLv2+ > >The fact that Bruno has been notably silent on this list for several >months may be a problem; we have several outstanding requests for a >looser license on these and other modules where Bruno has made >non-trivial contributions. 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.
Re: Request to relicense hash gnulib module to LGPLv2+
[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
Re: Request to relicense hash gnulib module to LGPLv2+
On 09/12/13 10:05, Eric Blake wrote: > 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). A nit: I'd change "the looser" to "a looser". It should be OK, for example, for us to change a license from GPLv3+ to LGPLv3+ if it's available under LGPLv2+ in a GNU system. > 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). This part needs some motivation, if only to explain matters to rms. It's not obvious from the text what exit-on-failure has to do with LGPL vs GPL, for example. Maybe you could work something like the following into the text: Some Gnulib modules are intended for use only in standalone applications, and their licenses are therefore intended to be GPL rather than LGPL. These modules call 'exit' on failure, an action that would be inappropriate for a library.
