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

[Daniel P . Berrangé]

On Thu, Nov 07, 2024 at 01:36:49PM +0100, Markus Armbruster wrote:
> 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.

IANAL, but .... :-)

The distinction of "source code" license vs "combined work" license,
is a quite normal concept. As an example, it is something that is
applied in Fedora RPM packaging when deciding the RPM spec "License:"
tag. The latter is considered to refer to the licenses on the subset
of source is said to be part of the distributed binaries, so we can
exclude licenses of any part of the source that is not compiled, and
of supporting code - eg license of makefiles, meson file, autoconf,
code is excluded from the RPM license tag.


The difference is that in most cases, the excluded part of the source
is in separate files, or less frequently could be in #ifdef sections,
whereas in this case we have two differently licensed parts of work
in the same file.

The question is thus what can you say is "compiled".

Is the whole file "compiled", or are only the souce code constructs
"compiled".

My proposition is that, in most cases, comments are not used by
the "compilation", or "code generation" phase. They are seen by
the "parsing" phase only and thus dont contribute to the contents
of the output binary code.

With C code this is easy to illustrate. Run 'gcc -save-temps' and
look at the '.i' file which is what the compiler uses as input
for code generation after cpp has run. The '.i' file is devoid of
all code comments.

I've not proved the same for golang compilers yet, but my argument
hinges on that being the true.

None the less, we have raised this position/viewpoint with experts
for a second opinion.

> > 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?

I don't have any particular examples. Perhaps 100% of the .go code
in the repo in question will be auto-generated. I can't predict the
future, so there's a decent chance we might end up with some basic
scaffolding and/or layered framework code that is manually written.
If such a situation arises, it is important to have anticipated this,
to make clear it is intended to be under a specific license.

With regards,
Daniel
-- 
|: 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 :|