posix_spawn* license change request

[Adam Stokes]

Hi Bruno,

Is it possible to have posix_spawn* licenses relaxed to LGPLv2+?

Thank you,
Adam

Re: findutils on interix

[Eric Blake]

On 10/28/2010 06:43 AM, Markus Duft wrote:
> On 10/28/2010 12:08 PM, Markus Duft wrote:
>> On 10/28/2010 12:03 PM, James Youngman wrote:
>> [snip]
>>> In so far as we're likely ever to fix this problem I'd be inclined to
>>> go for the 32K limit that Eric suggested.   And perhaps treating
>>> ENOMEM like E2BIG when execve fails, for Interix.
>>
>> mhm - that'd be ok with me.
>>
>> another solution that came to my mind: i'm maintaining a library, who's sole 
>> purpose is to fix the incorrect behaviour of libc in some regards on interix 
>> (libsuacomp [1]). it does some "bad" things already ( ;p ), so maybe i could 
>> override the sysconf() function (it already overrides approx 70 
>> functions...), and make it return a sane value in the _SC_ARG_MAX case. that 
>> would make the whole problem disappear, and even the first (pushed) patch 
>> unnecessary.

That's exactly what gnulib is - a library of source code workarounds for
broken platform functions.  Are you interested in porting your
libsuacomp fixes into gnulib, so that more GNU programs can support
Interix out of the box?

> this is IMHO the best solution, as it takes the responsibility from findutils 
> to work around existing OS bugs,

Agreed - that is the approach that most GNU projects take - isolate the
platform bugs into wrapper function fixes, so that the rest of the
project can assume sane POSIX semantics.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: findutils on interix

[Markus Duft]

On 10/28/2010 04:16 PM, Eric Blake wrote:
[snip]
> 
> That's exactly what gnulib is - a library of source code workarounds for
> broken platform functions.  Are you interested in porting your
> libsuacomp fixes into gnulib, so that more GNU programs can support
> Interix out of the box?

(i'll take findutils out of the CC on the next message, and continue (if we 
continue) on gnulib only ;))

yeah, right. it would be really cool to see this all merged into gnulib. 
however i
see some slight problems (i don't know if we can manage to get around them...). 
i'll
briefly describe what i'm doing, and you can decide on your own whether that 
fits 
somehow into gnulib (as i have not enough knowledge on how gnulib is 
used/built/etc.)

suacomp tries to "fix" functions from the SUA libc by overriding them. this 
means in
the static case to define the symbol and make suacomp link in before the libc. 
in the
shared library case, this is a little more complicated (i'll use fork() as 
example):

 *) libc.so provides both fork() and _fork().
 *) fork() calls _fork().
 *) fork() is a weak external, which resolves to the suacomp _fork() if it is 
there.
 *) suacomp uses dlopen/dlsym to route to the real functions and modify/fix 
input/output.

suacomp is linked in before libc, by installing a libc.a and libc.so file to 
the PREFIX
(so better don't install suacomp in /usr ;) ), which are ld linker scripts, 
assuring
suacomp before libc in all cases.

the only use case i designed all this for, is gentoo prefix (which ought to not 
install
into /usr, etc.). i think you heard of it? the initial purpose was to fix 
multi-core
cpu problems with make, python, etc. however it grew a little further, so it 
has it's
own poll() (select() based).

thinking of gnulib, i can see a lot of potential problems, starting fex, that 
gnulib
modules are copied into the packages, rather than gnulib beeing an installed 
library
that is linked against (is this true always?).

in gentoo prefix (gentoo main too? idk) there is a "gnulib" ebuild, which 
builds a
library of gnulib to fix some system deficiencies, but IIRC it's static only. 
i'd
rather like suacomp to be static wherever possible to ease bugfixing, upgrades, 
etc.

phew. i'm done ;) hope you didn't fall asleep somewhere on the way ;p

now, do you see any chance to merge the two concepts of gnulib and suacomp (or 
isn't
there any need to merge concepts?)?

regards, and thanks for the proposal!
markus

> 
>> this is IMHO the best solution, as it takes the responsibility from 
>> findutils to work around existing OS bugs,
> 
> Agreed - that is the approach that most GNU projects take - isolate the
> platform bugs into wrapper function fixes, so that the rest of the
> project can assume sane POSIX semantics.
> 

Re: posix_spawn* license change request

[Bruno Haible]

Hi Adam,

> Is it possible to have posix_spawn* licenses relaxed to LGPLv2+?

For what package is this?

Have you considered releasing this package under LGPLv3+ instead of LGPLv2+?
You know about the advantages of GPLv3+ and LGPLv3+ versus version 2:
  

Bruno

Re: posix_spawn* license change request

[Adam Stokes]

On Thu, 28 Oct 2010 20:34:11 +0200
Bruno Haible  wrote:

> Hi Adam,
> 
> > Is it possible to have posix_spawn* licenses relaxed to LGPLv2+?
> 
> For what package is this?
> 
> Have you considered releasing this package under LGPLv3+ instead of
> LGPLv2+? You know about the advantages of GPLv3+ and LGPLv3+ versus
> version 2: 
> 
> Bruno
> 

The modules are posix_spawn and posix_spawnp which I need for the windows port 
of http://fedorahosted.org/netcf. They are at LGPL currently and show's you as 
the maintainer.

Thanks,
Adam

Re: [libvirt] [PATCH] show compiled in options in virsh --version

[Eric Blake]

[adding bug-gnulib]

On 10/28/2010 01:25 PM, Daniel Veillard wrote:
>>>  case 'v':
>>> -/* FIXME - list a copyright blurb, as in GNU programs?  */
>>> -puts(VERSION);
>>> +vshShowVersion(ctl);
>>>  exit(EXIT_SUCCESS);
>>
>> Pre-existing bug - we don't detect write failure to stdout to exit with
>> non-zero status.  Unchanged by your patch.
> 
>   Not sure it's really a problem, but okay I will look.

The gnulib module closeout can automatically take care of this, but it
is currently licensed as GPL.  Jim, Bruno, are you okay with relicensing
closeout and close-stream as LGPLv2+?

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: posix_spawn* license change request

[Adam Stokes]

On Thu, 28 Oct 2010 14:40:39 -0400
Adam Stokes  wrote:

> On Thu, 28 Oct 2010 20:34:11 +0200
> Bruno Haible  wrote:
> 
> > Hi Adam,
> > 
> > > Is it possible to have posix_spawn* licenses relaxed to LGPLv2+?
> > 
> > For what package is this?
> > 
> > Have you considered releasing this package under LGPLv3+ instead of
> > LGPLv2+? You know about the advantages of GPLv3+ and LGPLv3+ versus
> > version 2: 
> > 
> > Bruno
> > 
> 
> The modules are posix_spawn and posix_spawnp which I need for the
> windows port of http://fedorahosted.org/netcf. They are at LGPL
> currently and show's you as the maintainer.
> 
> Thanks,
> Adam
> 

CC'ing Laine Stump for input on netcf licensing

Re: posix_spawn* license change request

[Eric Blake]

On 10/28/2010 12:40 PM, Adam Stokes wrote:
> On Thu, 28 Oct 2010 20:34:11 +0200
> Bruno Haible  wrote:
> 
>> Hi Adam,
>>
>>> Is it possible to have posix_spawn* licenses relaxed to LGPLv2+?
>>
>> For what package is this?

netcf, which is currently one of the libraries directly linked into the
LGPLv2+ libvirt.

>>
>> Have you considered releasing this package under LGPLv3+ instead of
>> LGPLv2+? You know about the advantages of GPLv3+ and LGPLv3+ versus
>> version 2: 

For good or for bad, both netcf and libvirt are managed by Red Hat
rather than FSF, so the political battle to relicense these libraries
lies with Red Hat management.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [libvirt] [PATCH] show compiled in options in virsh --version

[Jim Meyering]

Eric Blake wrote:
> [adding bug-gnulib]
>
> On 10/28/2010 01:25 PM, Daniel Veillard wrote:
  case 'v':
 -/* FIXME - list a copyright blurb, as in GNU programs?  */
 -puts(VERSION);
 +vshShowVersion(ctl);
  exit(EXIT_SUCCESS);
>>>
>>> Pre-existing bug - we don't detect write failure to stdout to exit with
>>> non-zero status.  Unchanged by your patch.
>>
>>   Not sure it's really a problem, but okay I will look.
>
> The gnulib module closeout can automatically take care of this, but it
> is currently licensed as GPL.  Jim, Bruno, are you okay with relicensing
> closeout and close-stream as LGPLv2+?

They're both relatively thin wrappers.
Fine by me.

Re: posix_spawn* license change request

[Eric Blake]

On 10/28/2010 01:42 PM, Eric Blake wrote:
> On 10/28/2010 12:40 PM, Adam Stokes wrote:
>> On Thu, 28 Oct 2010 20:34:11 +0200
>> Bruno Haible  wrote:
>>
>>> Hi Adam,
>>>
 Is it possible to have posix_spawn* licenses relaxed to LGPLv2+?
>>>
>>> For what package is this?
> 
> netcf, which is currently one of the libraries directly linked into the
> LGPLv2+ libvirt.
> 
>>>
>>> Have you considered releasing this package under LGPLv3+ instead of
>>> LGPLv2+? You know about the advantages of GPLv3+ and LGPLv3+ versus
>>> version 2: 
> 
> For good or for bad, both netcf and libvirt are managed by Red Hat
> rather than FSF, so the political battle to relicense these libraries
> lies with Red Hat management.

On re-reading this, I see that my remarks could be taken out of context.
 I know of no battle between Red Hat and the FSF, nor did I mean to
imply one.  In fact, I am grateful that both organizations are on good
terms.  Rather, I was trying to express these points:

It is Red Hat management in charge of the licensing of netcf and
libvirt, therefore the licensing decision does not necessarily have the
same goals, when compared with the FSF goals for GNU projects.

I'm not sure what level of effort it would take to convince Red Hat
management to change the license, so it could fall anywhere on the scale
between rubber stamp approval vs. a full political battle, depending in
part on how many other clients of these two libraries might also have to
be relicensed.

To date, I have not been personally bothered enough by the current
license choice to warrant my own attempt to raise a relicensing request
with Red Hat.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: posix_spawn* license change request

[Bruno Haible]

Eric Blake wrote:
> >> For what package is this?
> 
> netcf, which is currently one of the libraries directly linked into the
> LGPLv2+ libvirt.

And you have already explained that libvirt needs to stay LGPLv2+, in
  
  
  

Since the posix_spawn sources in gnulib come actually from glibc, there's
no problem with going back to LGPLv2+. Patch below.

> For good or for bad, both netcf and libvirt are managed by Red Hat
> rather than FSF, so the political battle to relicense these libraries
> lies with Red Hat management.

I don't wish to start a political battle. I only asked the question whether
you have considered LGPLv3+. You say "yes, but we choose LGPLv2+". Fine.


2010-10-28  Bruno Haible  

posix_spawn*, getdtablesize: Relax license.
* modules/posix_spawn (License): Change to LGPLv2+.
* modules/posix_spawnp (License): Likewise.
* modules/posix_spawn-internal (License): Likewise.
* modules/posix_spawnattr_init (License): Likewise.
* modules/posix_spawnattr_getflags (License): Likewise.
* modules/posix_spawnattr_setflags (License): Likewise.
* modules/posix_spawnattr_getpgroup (License): Likewise.
* modules/posix_spawnattr_setpgroup (License): Likewise.
* modules/posix_spawnattr_getschedparam (License): Likewise.
* modules/posix_spawnattr_setschedparam (License): Likewise.
* modules/posix_spawnattr_getschedpolicy (License): Likewise.
* modules/posix_spawnattr_setschedpolicy (License): Likewise.
* modules/posix_spawnattr_getsigdefault (License): Likewise.
* modules/posix_spawnattr_setsigdefault (License): Likewise.
* modules/posix_spawnattr_getsigmask (License): Likewise.
* modules/posix_spawnattr_setsigmask (License): Likewise.
* modules/posix_spawnattr_destroy (License): Likewise.
* modules/posix_spawn_file_actions_init (License): Likewise.
* modules/posix_spawn_file_actions_addclose (License): Likewise.
* modules/posix_spawn_file_actions_adddup2 (License): Likewise.
* modules/posix_spawn_file_actions_addopen (License): Likewise.
* modules/posix_spawn_file_actions_destroy (License): Likewise.
* modules/getdtablesize (License): Likewise.
Requested by Adam Stokes  for use in netcf.

--- modules/getdtablesize.orig  Thu Oct 28 23:19:29 2010
+++ modules/getdtablesize   Thu Oct 28 23:18:02 2010
@@ -18,7 +18,7 @@
 
 
 License:
-LGPL
+LGPLv2+
 
 Maintainer:
 Bruno Haible
--- modules/posix_spawn.origThu Oct 28 23:19:29 2010
+++ modules/posix_spawn Thu Oct 28 23:18:53 2010
@@ -24,7 +24,7 @@
 
 
 License:
-LGPL
+LGPLv2+
 
 Maintainer:
 Bruno Haible, glibc
--- modules/posix_spawn-internal.orig   Thu Oct 28 23:19:29 2010
+++ modules/posix_spawn-internalThu Oct 28 23:18:54 2010
@@ -21,7 +21,7 @@
 Include:
 
 License:
-LGPL
+LGPLv2+
 
 Maintainer:
 Bruno Haible, glibc
--- modules/posix_spawn_file_actions_addclose.orig  Thu Oct 28 23:19:30 2010
+++ modules/posix_spawn_file_actions_addclose   Thu Oct 28 23:18:54 2010
@@ -25,7 +25,7 @@
 
 
 License:
-LGPL
+LGPLv2+
 
 Maintainer:
 Bruno Haible, glibc
--- modules/posix_spawn_file_actions_adddup2.orig   Thu Oct 28 23:19:30 2010
+++ modules/posix_spawn_file_actions_adddup2Thu Oct 28 23:18:54 2010
@@ -25,7 +25,7 @@
 
 
 License:
-LGPL
+LGPLv2+
 
 Maintainer:
 Bruno Haible, glibc
--- modules/posix_spawn_file_actions_addopen.orig   Thu Oct 28 23:19:30 2010
+++ modules/posix_spawn_file_actions_addopenThu Oct 28 23:18:54 2010
@@ -25,7 +25,7 @@
 
 
 License:
-LGPL
+LGPLv2+
 
 Maintainer:
 Bruno Haible, glibc
--- modules/posix_spawn_file_actions_destroy.orig   Thu Oct 28 23:19:30 2010
+++ modules/posix_spawn_file_actions_destroyThu Oct 28 23:18:54 2010
@@ -23,7 +23,7 @@
 
 
 License:
-LGPL
+LGPLv2+
 
 Maintainer:
 Bruno Haible, glibc
--- modules/posix_spawn_file_actions_init.orig  Thu Oct 28 23:19:30 2010
+++ modules/posix_spawn_file_actions_init   Thu Oct 28 23:18:54 2010
@@ -24,7 +24,7 @@
 
 
 License:
-LGPL
+LGPLv2+
 
 Maintainer:
 Bruno Haible, glibc
--- modules/posix_spawnattr_destroy.origThu Oct 28 23:19:30 2010
+++ modules/posix_spawnattr_destroy Thu Oct 28 23:18:54 2010
@@ -23,7 +23,7 @@
 
 
 License:
-LGPL
+LGPLv2+
 
 Maintainer:
 Bruno Haible, glibc
--- modules/posix_spawnattr_getflags.orig   Thu Oct 28 23:19:30 2010
+++ modules/posix_spawnattr_getflagsThu Oct 28 23:18:54 2010
@@ -23,7 +23,7 @@
 
 
 License:
-LGPL
+LGPLv2+
 
 Maintainer:
 Bruno Haible, glibc
--- modules/posix_spawnattr_getpgroup.orig  Thu Oct 28 23:19:30 2010
+++ modules/posix_spawnattr_getpgroup   Thu Oct 28 23:18:54 2010
@@ -23,7 +23,7 @@
 
 
 License:
-LGPL
+LGPLv2+
 
 Maintainer:
 Bruno Haible, glibc
--- modules/posix_spawnattr_gets

Re: [libvirt] [PATCH] show compiled in options in virsh --version

[Bruno Haible]

Hi Eric,

> >>>  case 'v':
> >>> -/* FIXME - list a copyright blurb, as in GNU programs?  */
> >>> -puts(VERSION);
> >>> +vshShowVersion(ctl);
> >>>  exit(EXIT_SUCCESS);
> 
> The gnulib module closeout can automatically take care of this, but it
> is currently licensed as GPL.  Jim, Bruno, are you okay with relicensing
> closeout and close-stream as LGPLv2+?

In gnulib we have a rule of thumb which says that anything that calls exit()
or xmalloc() is likely to end up only in executables, not in libraries, and
code in executables can just as well be relicensed under GPL instead of LGPL.

In the libiconv and gettext packages, for example, the executables are all
under GPL, although other parts of the package are under LGPL. Have you
(and the management and lawyers behind libvirt) considered this approach for
libvirt?

I ask because 'closeout' may be only the beginning. Then comes 'xalloc',
'quotearg', and 'avltree-list', and at the end these high-value modules could
be used by proprietary programs (assuming appropriate LGPL compliant packaging).
We need a borderline between what can go LGPL and what needs to stay GPL, and
the rule of thumb mentioned above is a good guiding line.

Btw, for the modules 'closeout' and 'close-stream', a look at
  $ gitk lib/closeout.h lib/closeout.c lib/close-stream.h lib/close-stream.c
reveals that you have to ask also Paul, not only Jim and me.

Bruno

Re: findutils on interix

[Paolo Bonzini]

On 10/28/2010 04:59 PM, Markus Duft wrote:

thinking of gnulib, i can see a lot of potential problems, starting fex, that 
gnulib
modules are copied into the packages, rather than gnulib beeing an installed 
library
that is linked against (is this true always?).


It is true that gnulib is usually copied into packages.  However, it is 
possible to put multiple gnulib modules into a single statically linked 
library.  This is what gentoo does with its ebuild; you can search 
recent archives for "libposix", too (which is just a selection of gnulib 
modules improving the POSIX-ness of a system).



in gentoo prefix (gentoo main too? idk) there is a "gnulib" ebuild, which 
builds a
library of gnulib to fix some system deficiencies, but IIRC it's static only. 
i'd
rather like suacomp to be static wherever possible to ease bugfixing, upgrades, 
etc.


There's something inconsistent here. :)

Paolo

Re: [libvirt] [PATCH] show compiled in options in virsh --version

[Jim Meyering]

Bruno Haible wrote:
> Hi Eric,
>
>> >>>  case 'v':
>> >>> -/* FIXME - list a copyright blurb, as in GNU programs?  */
>> >>> -puts(VERSION);
>> >>> +vshShowVersion(ctl);
>> >>>  exit(EXIT_SUCCESS);
>>
>> The gnulib module closeout can automatically take care of this, but it
>> is currently licensed as GPL.  Jim, Bruno, are you okay with relicensing
>> closeout and close-stream as LGPLv2+?
>
> In gnulib we have a rule of thumb which says that anything that calls exit()
> or xmalloc() is likely to end up only in executables, not in libraries, and
> code in executables can just as well be relicensed under GPL instead of LGPL.

Of course.  Thanks for the reminder, Bruno.
That is indeed a slippery slope.  I was too hasty in saying "ok".

Eric, one option is to use the GPLv3 for programs like virsh,
then to have a second gnulib library that they would use.

> In the libiconv and gettext packages, for example, the executables are all
> under GPL, although other parts of the package are under LGPL. Have you
> (and the management and lawyers behind libvirt) considered this approach for
> libvirt?
>
> I ask because 'closeout' may be only the beginning. Then comes 'xalloc',
> 'quotearg', and 'avltree-list', and at the end these high-value modules could
> be used by proprietary programs (assuming appropriate LGPL compliant 
> packaging).
> We need a borderline between what can go LGPL and what needs to stay GPL, and
> the rule of thumb mentioned above is a good guiding line.

Re: findutils on interix

[Markus Duft]

On 10/29/2010 01:11 AM, Paolo Bonzini wrote:
> On 10/28/2010 04:59 PM, Markus Duft wrote:
>> thinking of gnulib, i can see a lot of potential problems, starting fex, 
>> that gnulib
>> modules are copied into the packages, rather than gnulib beeing an installed 
>> library
>> that is linked against (is this true always?).
> 
> It is true that gnulib is usually copied into packages.  However, it is 
> possible to put multiple gnulib modules into a single statically linked 
> library.  This is what gentoo does with its ebuild; you can search recent 
> archives for "libposix", too (which is just a selection of gnulib modules 
> improving the POSIX-ness of a system).

mhm, so at least ATM, it's most of the time static. would it be much of a 
problem to
build things both shared and static? also, is there a chance i'm able to 
install libc.a
and libc.so in a way that i never destroy anything on any system? is it wanted 
for
gnulib at all to install such scripts?

> 
>> in gentoo prefix (gentoo main too? idk) there is a "gnulib" ebuild, which 
>> builds a
>> library of gnulib to fix some system deficiencies, but IIRC it's static 
>> only. i'd
>> rather like suacomp to be static wherever possible to ease bugfixing, 
>> upgrades, etc.
> 
> There's something inconsistent here. :)

hah, lol - of course, suacomp should be shared wherever possible ;)

> 
> Paolo
> 
> 

Re: [libvirt] [PATCH] show compiled in options in virsh --version

[Justin Clift]

On 10/29/2010 04:43 PM, Jim Meyering wrote:

> Of course.  Thanks for the reminder, Bruno.
> That is indeed a slippery slope.  I was too hasty in saying "ok".
> 
> Eric, one option is to use the GPLv3 for programs like virsh,
> then to have a second gnulib library that they would use.

Cue "making it more difficult for packagers", and that extra bit
harder for people wanting to figure out licensing for use with
their app.  ;>

In this specific instance, probably the best route is the easiest one,
and keep on using our existing (less optimal, but already license
compatible) code. :)