[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v2 0/8] qapi: add generator for Golang interface
From: |
Daniel P . Berrangé |
Subject: |
Re: [RFC PATCH v2 0/8] qapi: add generator for Golang interface |
Date: |
Thu, 7 Nov 2024 13:35:45 +0000 |
User-agent: |
Mutt/2.2.12 (2023-09-09) |
On Thu, Nov 07, 2024 at 01:06:36PM +0000, Daniel P. Berrangé wrote:
> 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 .... :-)
> 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.
> None the less, we have raised this position/viewpoint with experts
> for a second opinion.
Another thought or two...
>From a QEMU community POV we have no license problem no matter what,
so from a legal POV this risk free for us.
The licensing question is purely one for application developers consuming
our work who want to avoid GPL for some reason.
Lets say my interpretation is wrong, or even that it is right, but the
app developers disagree, or are none the less unhappy in some way. What
impact would this have for QEMU ?
Code generation is practically free once the generator is written, so we
just run it twice, storing the output in git on different branches with
parallel tags, once with comments and once without. eg
The "main" branch (and associated versioned vX.Y.Z tags) in qemu-go-qapi.git
provide the full QAPI go source + copied QAPI comments under MIT-0 AND
GPL-2.0-or-later
The "minimal" branch (and associated vX.Y.Z-minimal tags) in qemu-go-qapi.git
provide only the QAPI go source, without any comments under MIT-0 only.
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 :|