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.
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". 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. -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
