[libvirt] License issues

Wed May 1 15:54:58 UTC 2013

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130501/b7ca3af7/attachment-0001.sig>