tl:dr; summary: It was pointed out to me off-list that libvirt has a licensing issue depending on how it is configured, present since 0.6.3 (introduction of vbox:// URI in commit 10d16508 in April 2009), and which has caused at least libvirt itself to risk shipping non-compliant binaries (at least virsh in Fedora 12 and later is non-compliant, thanks to GPLv3 libreadline 6.0 since mid-2009; although RHEL 6 is immune). The licensing issue can be avoided by configuring --without-vbox, and/or virsh can be fixed by configuring lv_use_readline=no. Meanwhile, we have a plan of attack that would allow future releases of libvirt to provide vbox support to GPLv3 apps, and so that virsh is no longer legally prevented from using GPLv3 readline. Details: The problem stems from the fact that various files in src/vbox (such as vbox_XPCOMCGlue.c) have an explicit LGPLv2-only license. That means that any binary that includes code based on these files is also LGPLv2-only. At least Fedora distributes libvirt.so with vbox support enabled, which means ANY application that links against such a libvirt.so must be compatible with LGPLv2-only. But there is at least one popular license that is definitely incompatible with LGPLv2-only: GPLv3. This means that it is impossible to use Fedora's libvirt.so in a GPLv3 (or GPLv3+) binary, even if that binary will not be directly using vbox:// URIs. (Note that RHEL 6 ships without vbox:// URI support, and therefore its libvirt.so is not poisoned.) Meanwhile, the libvirt package itself usually ships a binary that wants to use GPLv3 code. virsh defaults to compiling against libreadline if it is present (you can avoid it with the undocumented './configure lv_use_readline=no', but to date we have never added a --without-readline configure switch). Prior to 2009, libreadline 5.x was GPLv2+; but in 2009, with the release of readline 6.0, it's license was changed to GPLv3+. Therefore, ever since Fedora 12, virsh has been in license violation - it links against two incompatible libraries (libvirt.so with vbox support is LGPLv2-only, and libreadline 6.0 is GPLv3+). With regards to libreadline, we have a couple of sneaky backdoors: The first is a liberal interpretation of the GPLv2 exception that allows you to use standard system libraries regardless of their licensing - if you can succesfully argue that libreadline is a system library (on the same par as libc) then even though it is GPLv3, using it in a GPLv2 project under the system library clause does not constitute a license violation. I'm not a lawyer, but trying to use this exception feels sleazy; and while it may hold up to scrutiny on GNU/Linux (where libreadline really is present on all installs thanks to bash), it's harder to argue that it will work on all other systems (BSD systems come to mind, which try hard to provide the option of getting a running system without the need for installing GPLv3 libraries). The second backdoor is the existence of libedit, a BSD-licensed library that provides the same API as (at least some versions of) libreadline. If virsh is not using any libreadline features beyond what libedit provides, we could link virsh against libedit instead of libreadline, at which point virsh would no longer be using GPLv3 code, and can be distributed under GPLv2-only as needed according to whether libvirt.so is poisoned to be LGPLv2-only. I'm hoping to patch configure.ac to probe for libedit, and if present, to prefer that over libreadline if vbox is enabled. We'd also want to add a configure --with-readline=... to give the user a documented way to choose which backend they want for interactive virsh (libedit, libreadline, or none) rather than forcing the decision via undocumented cache variables. The /usr/libexec/libvirt_parthelper binary is another potential binary that needs auditing. It exists because we need to interact with libparted, but that library is GPLv3, and thus cannot be linked into libvirt.so proper. By creating a separate application, our goal was to have libvirt_parthelper be a GPLv3 app (thanks to parted) but reuse libvirt code (exercising the "or later" clause of all libvirt LGPLv2+ code used in that binary). At the moment, ldd says that libvirt_parthelper is not linked against libvirt.so (but rather just statically includes other libvirt files such as "virutil.h"), so we can argue that this binary is immune to the problem with vbox code. Note that libvirt's intent has always been to ship LGPLv2+ code, precisely because we want libvirt to be usable in both GPLv2 and GPLv3 projects (anyone wanting to use an LGPLv2+ library in a GPLv3 project merely exercises their "or later" rights of LGPLv2+ to use that library under LGPLv3). But since we are currently falling short of that goal, we need to make a change. Unfortunately, the copyright holder (Sun) that exerted the restrictive LGPLv2-only license no longer exists, and it is not obvious whether their successor Oracle is legally able to relax the license. Even if they are, there is then the question of whether Oracle would choose to relax the license, and how much time it would take to pursue the legal paperwork to get a license change authorized. But we have another possibility, by using what we have already done with the libvirt_parthelper as our guide. That is, as long as we can isolate poisoned licenses out of libvirt.so, and ensure that they are only compiled into standalone binaries, those standalone binaries can have a more restrictive license. We can go in either direction so long each individual binary never mixes both GPLv3 and LGPLv2-only code. Obviously, libvirt_parthelper chose to restrict things to GPLv3, but so far, the libvirtd executable has not been poisoned in either direction. Furthermore, since we have already gone to the efforts of creating a libvirt_parthelper to keep GPLv3 code out of libvirtd, it seems reasonable to assume that we can create other helper apps for any future tasks that libvirtd may want to perform that require GPLv3 code. Therefore, I propose that we poison libvirtd into being [L]GPLv2-only, by linking the vbox support into libvirtd instead of in libvirt.so. Implementation wise, this would mean that we compile the vbox driver as an independent module (much the same as we do for qemu or lxc), and link that module into libvirtd rather than into libvirt.so directly. In libvirt.so, attempts to use a vbox:// URI would then be forwarded over RPC to libvirtd, instead of directly using vbox code. vbox would then be a remote instead of a local protocol. Since existing vbox:// connections are local, vbox users have not previously had to ensure that the system libvirtd daemon is running. Therefore, I suspect that it would be nicer to reuse the qemu://session code that auto-spawns a session libvirtd, so that from the user standpoint, they can continue to connect to vbox without having to have a libvirtd system daemon running. The initial connection time will take slightly longer as a session libvirtd is autospawned, but that should not be too much impact. 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). 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. [1] qemu license issue first identified: https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg02096.html Efforts to fix it: https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg05807.html qemu release delay, in part because of license issue: https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg06042.html -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list