Re: [RFC PATCH v2 0/8] qapi: add generator for Golang interface

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@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.