Markus Armbruster <arm...@redhat.com> writes:
> 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? 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
