Re: [Qemu-devel] TCG plugins and the GPL (was: [PATCH v4 00/54] plugins for TCG)

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Sep 12, 2019 at 10:03:48AM +0100, Alex Bennée wrote:
> 
> Markus Armbruster <armbru@redhat.com> writes:
> 
> > Alex Bennée <alex.bennee@linaro.org> writes:
> >
> >> Markus Armbruster <armbru@redhat.com> writes:
> > [...]
> >>> Please advise why TCG plugins don't undermine the GPL.  Any proposal to
> >>> add a plugin interface needs to do that.
> >>
> >> I'm not sure what we can say about this apart from "ask your lawyer".
> >
> > I'm not asking for a legal argument, I'm asking for a pragmatic one.
> >
> >> I'm certainly not proposing we add any sort of language about what
> >> should and shouldn't be allowed to use the plugin interface. I find it
> >> hard to see how anyone could argue code written to interface with the
> >> plugin API couldn't be considered a derived work.
> >
> > What makes that so?  Is writing a plugin without linking with QEMU code
> > impractical?
> 
> The way a plugin works is by linking. The plugin itself would be useless
> unless combined with the QEMU code to do its thing. It is a more
> intimate binding than an IPC interface using some sort of protocol. The
> argument goes that pretty much any kernel module is derived code - but
> again it has never really been litigated in the courts which would be
> the people to set the precedent.

Part of the problem with the kernel is the historical precedent they
had set. The issue of GPL compliance only become prominent much later
after (closed source) loadable modules were already widely in use. They
tried to lock the door after the horse had already bolted by adding
EXPORT_SYMBOL_GPL.

We can avoid this trapped by clearly documenting our license expectations
from the very start. ie state that we consider any plugins to be derived
works and to be bound by the terms of the GPL. This doesn't mean the
plugins themselves have to be GPL, but they have to be under terms that
allow relicensing to the GPL, in order to be license compatible. 

We could even go as far as having the plugin registration API require
that the plugin explicitly declare its license and we can log this
license at time of loading. If people use a non-GPL compatible license
it will be clearly visible as non-compatible, or if they lie and pretend
to be GPL then they would be willfully violating.

> >> There are two use cases I have in mind:
> >>
> >> The first is FLOSS developers writing interesting tools that can take
> >> advantage of QEMU's control of the system to do experiments that are
> >> tricky with other setups (Valgrind is limited to same-arch, Dynamo/Pin
> >> are user-space only). I want these experiments to be easy to do without
> >> having to keep hacking and re-hacking QEMU's core code. I would hope
> >> QEMU developers would up-stream theirs into the QEMU source tree but I
> >> can imagine academics will have open source code that will only ever sit
> >> in their paper's repository.
> >
> > GPL'ed code that's not for upstream is 100% legitimate.

Yep, the code only has to be provided to the people who receive the
plugin binary. Those people can't be prevented from redistributing
it further though.

> >> The other is users who currently maintain hacked up internal copies of
> >> QEMU as a test bed for whatever piece of silicon they are brewing behind
> >> closed doors. This code would never be distributed (hence never be a GPL
> >> issue)
> >
> > Correct.  We can't force anybody to distribute, and that's only proper.
> >

> > Are there any technical difficulties that could make distributing a
> > plugins in binary form impractical?
> 
> Well the first thing will be we are not intending to offer a guaranteed
> ABI. While we don't want to be changing it at a whim there shouldn't be
> an expectation that the plugin interface will maintain backwards
> compatibility (unlike the command line interface ;-). There should be an
> expectation that plugins will likely need to be rebuilt against the
> current source tree from time to time.
> 
> We could implement a more technical measure analogous to the kernels
> module signing that would require the plugin to be rebuilt with
> reference to the current QEMU source tree although that will be a pain
> even for internally distributed blobs. I'm loathed to implement such a
> system from v1 though given the problem of publicly distributed binary
> blobs is currently only a theoretical problem.

The problem with waiting for a problem to arise is that you have set a
precedent that its ok. We are in a stronger enforcement position if we
can set expectations accurately from day one, avoiding the trap the
kernel had which needed to try to enforce after the fact.

So from that POV, I'd be strongly in favour of technical measures that
force the plugin to be rebuilt against each new QEMU version.

This doesn't need to be module signing - it could be as simple as
requiring the plugin to export a symbol "module_version" which must
exactly match the QEMU version, or refuse to load it. If we want to
be even more strict we could generate a random hash in each QEMU
rebuild, which is the similar level of strictness to kernel signing

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|