Re: relax license of cloexec, fcntl

[Eric Blake]

On 12/13/2010 10:04 AM, Eric Blake wrote:
> Yes, this point has been raised in the past.  I certainly agree that a
> process with no children doesn't need the overhead of guaranteeing an
> open() wrapper that supports O_CLOEXEC, so definitely splitting things
> into two modules is worthwhile.  In fact, I'm wondring if the best
> approach might even be to just have the existing cloexec module be the
> key for whether O_CLOEXEC is guaranteed to be supported in open.
> 
> At any rate, all contributors have replied, so I'm pushing this:

Also worth converting from LGPLv3+ to LGPLv2+:

dup3
pipe2
accept4

I'm guessing they were created LGPL at the time because fcntl() and
cloexec modules were not at v2+.  Any objections to relaxing those three
modules?

In fact, relaxing dup3 would allow me to implement fcntl(FD_SETFD) on
mingw by using dup_cloexec to a temporary, then dup3 to clone the
temporary on top of the target fd, and thus fix the problem where
cloexec's set_cloexec_flag() doesn't currently work on mingw.

I also found the thread was where I first laid out a plan for O_CLOEXEC
support (has it really been more than a year, and I still haven't
finished it?):
http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00260.html

I also see that I already asked about the cloexec license once before,
and seemed to have consensus that LGPLv2+ wasn't an issue:
http://lists.gnu.org/archive/html/bug-gnulib/2009-12/msg00106.html

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

signature.asc
Description: OpenPGP digital signature