Re: [Qemu-devel] [PATCH v4 00/54] plugins for TCG

[Alex Bennée]

Aaron Lindsay OS <address@hidden> writes:

> On Sep 06 20:52, Alex Bennée wrote:
>>
>> 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 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.
>
> I am not a lawyer, but I would not have expected software merely using a
> well-defined API to be considered a derivative work of the software
> defining it. Unless, of course, it is a derivative work of another
> plugin using the same interface in a way that is not necessitated by the
> structure of the API.
>
> What's your reasoning for why it would be a derivative work? Is your
> belief that the plugin API is complex enough that anything using it has
> to be a derivative work, or something else?

Well it's derivative if the code couldn't have been written on it's own
- so is "derived" from a design in GPL code. The endless arguments about
derivation w.r.t the nvidia kernel drivers hinge on the fact the drivers
are multi-OS and shimmed to into the kernel - not explicitly written for
Linux. However no one really knows where the line is because it's the
courts that will ultimately decide.

OTOH the kernel has explicit language about the syscall layer:

   NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".

Anyway I don't really care either way and don't intend to become an arm
chair lawyer as the arguments can become rather circular and tedious. We
might want to make an explicit statement in the QEMU tree about
reserving the right to change the API in the future and the best way to
keep plugins in sync is to have them in the upstream source tree.

> That said, I'm not sure I understand in what way adding a plugin
> interface would undermine the GPL, so maybe I'm missing the point.

I suspect there is a similar concern as GCC had when they were asked to
expose their IR to tools. They were explicitly concerned that people
would ship proprietary compilers consisting of a GPL GCC shell with all
the clever optimisations in proprietary plugins that glued the front and
backends together. I don't think this is a problem for QEMU because at
the moment plugins can't be used to improve code generation - just
observe it. You could theoretically implement device models this way but
there are definitely easier more efficient ways of doing it - as shown
by other 3rd party forks of QEMU.

As I mentioned in the other message I'm sure there will be proprietary
- or rather secret behind closed doors plugins but I don't view them any
differently to all the various secret and external forks of the main
QEMU source.

>
> -Aaron


--
Alex Bennée