On 05/01/2013 09:54 AM, Eric Blake wrote:
Qemu has announced that they are delaying their release of 1.5 in part
because of a license problem [1]. I'm wondering if we need to follow
qemu's lead and possibly delay the release of libvirt 1.0.5 if we don't
have a fix in time (at any rate, I'm certainly trying to tackle both
proposed solutions in the near future, starting with the libedit idea
first).
So far, I was only able to start the task of using libedit (I still
don't have a nice way to let ./configure allow manual override of
libedit instead of readline, even if vbox is not in use) - but it should
at least be enough to feel better about releasing 1.0.5 without an
internal license violation.
https://www.redhat.com/archives/libvir-list/2013-May/msg00056.html
DV - if you still want to cut 1.0.5 today before I'm back online, feel
free to ack and push on my behalf if you agree with the patches.
On the other hand, the issue has been around for 4 years, so we
could argue that releasing 1.0.5 with the same problem is no worse than
what we have done in the past, and that we can wait to fix it until
1.0.6. If we do go with the delay for libvirt.so, users still have the
option of configuring --without-vbox to get a libvirt.so that is not
poisoned to be LGPLv2-only. And hopefully the libedit work is simple
enough that at least virsh can be fixed for 1.0.5, even if libvirt.so is
not fixed until 1.0.6.
And given Matthias' comment that vbox is most often used on Windows,
where we still don't have libvirtd working, any motion of vbox code into
libvirtd is definitely worth delaying to 1.0.6 (too bad for external
GPLv3 apps in the meantime, but at least the situation is no worse than
it has been for the last four years).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org