Hi, On Thu, Nov 07, 2024 at 10:43:06AM +0000, Daniel P. Berrangé wrote: > Bringing this thread back from the dead, since I had an > in-person discussion on a key question below at KVM Forum this > year and want to record it here.
Thanks for that. > On Fri, Jun 17, 2022 at 02:19:24PM +0200, Victor Toso wrote: > > Hi, > > > > This is the second iteration of RFC v1: > > https://lists.gnu.org/archive/html/qemu-devel/2022-04/msg00226.html > > > > > > # What this is about? > > > > To generate a simple Golang interface that could communicate with QEMU > > over QMP. The Go code that is generated is meant to be used as the bare > > bones to exchange QMP messages. > > > > The goal is to have this as a Go module in QEMU gitlab namespace, > > similar to what have been done to pyhon-qemu-qmp > > https://gitlab.com/qemu-project/python-qemu-qmp > > > > > > # Issues raised in RFC v1 > > > > The leading '*' for issues I addressed in this iteration > > > > * 1) Documentation was removed to avoid License issues, by Daniel > > Thread: > > https://lists.nongnu.org/archive/html/qemu-devel/2022-05/msg01889.html > > > > It is important for the generated Go module to be compatible with > > Licenses used by projects that would be using this. Copying the > > documentation of the QAPI spec might conflict with GPLv2+. > > > > I have not proposed another license in this iteration, but I'm > > planning to go with MIT No Attribution, aka MIT-0 [0]. Does it make > > sense to bind the generated code's license to MIT-0 already at > > generator level? > > > > [0] https://github.com/aws/mit-0/blob/master/MIT-0 > > To recap the situation > > * The license of the code generator itself does not determine the > license of the output generated code > > * The license of the inputs to the code generator, may or may > not, determine the license of the output generated code depending > on use context > > The primary input to the code generator is the QAPI schema, which is part > of QEMU and thus licensed GPL-2.0-or-later. > > The QAPI schema includes both the API definitions AND the API documentation > text. > > We can make the case that as the QEMU public interface, consuming the > API definitions in the QAPI schema for the purpose of generating code > is "fair use", and thus the output generated code does NOT need to > match the GPL-2.0-or-later license of the QAPI schema. We can choose > the code license, and a maximally permissive license looks appropriate. > > We want to have API documentation for the Golang bindings and the obvious > way to achieve this is to copy the API docs from the QAPI schema into the > Golang code. It is NOT reasonable to class such *direct copying* of docs > "fair use". IOW, copied docs will be under GPL-2.0-or-later. > > Thus if we pick MIT-0 for the Golang code, and copy across the QAPI docs, > the resulting Golang QAPI project code would be under a compound license > term "MIT-0 AND GPL-2.0-or-later". > > The concern was that this will limit the ability of downstream > applications to consume the Golang bindings, if they don't want their > combined work to contain GPL-2.0-or-later. > > Ignoring whether this fear of GPL-2.0-or-later is sane or not, > in retrospect I believe that this concern in fact has no legal > basis. > > The license of a compiled application binary is the union of all > the object files linked into it. > > Notice I said "Object file" there, **NOT** "Source file". > > This is the crucial distinction that makes the presense of > GPL-2.0-or-later docs a non-issue from a licensing POV. > > > When the compiler takes the "MIT-0 and GPL-2.0-or-later" license > .go source file, and builds an object file, it will be discarding > all the API documentation comments. IOW, all the parts that were > under GPL-2.0-or-later are discarded. The only parts of the source > file that get "compiled" are the Go language constructs which were > MIT-0 licensed [1]. > > IOW, we have a "MIT-0 and GPL-2.0-or-later" .go source file, > and an "MIT-0" object file. > > Thus while there may be a human perception problem with the Golang > bindings being "MIT-0 and GPL-2.0-or-later", there are no legal > licensing limitations, as the combined work for a library or > application linking the bindings will only contain the MIT-0 part. > > The GPL-2.0-or-later docs won't influence the license of the > combined work. > > Note, this interpretation applies only to languages which are > compiled, not interpreted. > > If we are generating python code for example, the there is > no "source file" vs "object file" distinction for licensing. > The combined work in a python app is under the union of all > the source file licenses. > > > TL;DR: I think you can re-add the documentation comments to > the Golang code generator, declare the resulting code as being > "MIT-0 AND GPL-2.0-or-later". Yes. I think so too. I plan to add it back and address Andrea's last review and submit it in the next week or so. > In the README.md file we need todo two important things: > > * Document our interpretation of the "combined work" license > situation for applications consuming the project. > * Declare that *ALL* manually written code contributions > are exclusively MIT-0. > > With regards, > Daniel > > [1] NB, there are languages where some code comments can have semantic > impacts on the compiled out. I don't believe that to be the case for > any human targetted API docs that we would be copying over from the > QAPI schema though in the Golang case. Cheers, Victor
signature.asc
Description: PGP signature
