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

[Markus Armbruster]

Alex Bennée <address@hidden> writes:

> Markus Armbruster <address@hidden> 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?

> 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.

> 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.

>        and is generally kept private because it's IP sensitive
> (e.g: experimenting with different cache models). If we can provide an
> interface that allows them to keep their experiments private and
> separate from changes to the core code then maybe apart from making
> their lives a bit easier we will see some non-IP sensitive contributions
> come back to the upstream. I live in hope ;-)

I'm concerned about a third case: imlementing stuff as a plugin so you
can distribute it with a GPL-incompatible license.  Particularly
pernicious when that stuff could be useful upstream.

Are there any technical difficulties that could make distributing a
plugins in binary form impractical?