Re: license request: relax pipe2 to LGPLv2+

Eric, > given your above agreement to my broader question I had misread your mail and thought you were only asking about lib/pipe2.c. But relaxing lib/binary-io.h is also fine with me; it was already under LGPLv2+ until 2007. Bruno -- In memoriam The children of Izieu

Re: license request: relax pipe2 to LGPLv2+

On 04/05/2011 05:50 PM, Bruno Haible wrote: > Eric Blake wrote: >> I don't see pipe2 as adding much beyond pipe-posix, cloexec, or >> nonblocking, all of which are LGPLv2+, and libvirt would really like to >> start using atomic fd flag creation routines like pipe2() to avoid data >> races on new en

Re: license request: relax pipe2 to LGPLv2+

On 04/05/2011 04:50 PM, Bruno Haible wrote: > I've made the change, assuming that Paul's commit to lib/pipe.c, which only > removed some lines of code, is not relevant for copyright purposes I expect you're right about copyright, but just in case: the change is fine with me too. And thanks.

Re: license request: relax pipe2 to LGPLv2+

Eric Blake wrote: > I don't see pipe2 as adding much beyond pipe-posix, cloexec, or > nonblocking, all of which are LGPLv2+, and libvirt would really like to > start using atomic fd flag creation routines like pipe2() to avoid data > races on new enough Linux (the race is still present on other OSs

license request: relax pipe2 to LGPLv2+

I don't see pipe2 as adding much beyond pipe-posix, cloexec, or nonblocking, all of which are LGPLv2+, and libvirt would really like to start using atomic fd flag creation routines like pipe2() to avoid data races on new enough Linux (the race is still present on other OSs, but the code is simpler