bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: license relaxation request


From: Eric Blake
Subject: Re: license relaxation request
Date: Mon, 17 Oct 2011 18:39:04 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.15

On 10/17/2011 05:58 PM, Bruno Haible wrote:
Hi Eric,

Can we relax the license of the following modules from LGPLv3+ down to
LGPLv2+, so that libvirt can use them, and on the grounds that they are
shipped as part of LGPLv2+ glibc?

grantpt
unlockpt
pt_chown
ptsname
ttyname_r

This is fine with me. ttyname_r is written by me, not from glibc, and I'm
not sure the code in glibc would help if someone would want to reimplement it.
But fine with me.

I'm also planning on adding a posix_openpt module.

This is not needed. As you can see from the code in lib/openpt.c,
posix_openpt() is one part of openpty(). Since we have an openpty() that
works on all Unix platforms, and openpty() comes from the glibc API,
why should anyone want to use posix_openpt()?

Libvirt is currently using open("/dev/ptmx", flags), which is great on Linux but not portable. posix_openpt() is the portable alternative to this, which works when you want to do things with just the master side without opening the slave side; and while openpty() is available and relatively portable, it is not POSIX, and the gnulib version is currently LGPLv3+. Besides, openpty needs -lpty on some platforms, while posix_openpt() should not.

On the other hand, you have a point - there's not much to do with the master side unless you also plan on opening the slave side, at which point openpty() abstracts away a lot of the pieces in building up the pair.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]