Daniel P. Berrangé <berra...@redhat.com> writes: > 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.
[...] > To recap the situation > > * The license of the code generator itself does not determine the > license of the output generated code For instance, GNU Bison is GPLv3+, but the parts the generator emits (the parser skeleton) come with a special exception. Such exceptions need to be granted by the copyright holder. As long as the code generating Go is not a derived work, the copyright holder situation should be simple enough to make this practical. > * 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. Having this argument confirmed by an actual expert seems advisable. > 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. What code do you have in mind? Can you provide an example? > 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.
