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

[Alex Bennée]

Markus Armbruster <address@hidden> writes:

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

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.

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

If someone were to do that it would depend on a copyright holder (i.e.
one of us) being willing to challenge that licensing. AIUI GCC used
additional language in the runtime exception clause:

  https://www.gnu.org/licenses/gcc-exception-3.1.html

which only allows use of the runtime exception if the code has gone
through GPL compatible code:

  A Compilation Process is "Eligible" if it is done using GCC, alone or
  with other GPL-compatible software, or if it is done without using any
  work based on GCC. For example, using non-GPL-compatible Software to
  optimize any GCC intermediate representations would not qualify as an
  Eligible Compilation Process.

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

--
Alex Bennée