Alex Bennée <alex.ben...@linaro.org> writes: > Markus Armbruster <arm...@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? > 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?