On Thu, Mar 24, 2022 at 09:00:05AM +0000, Daniel P. Berrangé wrote:
> On Wed, Mar 23, 2022 at 05:47:48PM -0400, John Snow wrote:
> > On Mon, Mar 21, 2022 at 5:08 PM John Snow <jsnow@redhat.com> wrote:
> > >
> > > The legacy.py module is heavily based on the QMP module by Luiz
> > > Capitulino (et al) which is licensed as explicit GPLv2-only. The async
> > > QMP package is currently licensed similarly, but I intend to relicense
> > > the async package to the more flexible GPLv2+.
> > >
> > > In preparation for that change, make the license on legacy.py explicit.
> > >
> > > Signed-off-by: John Snow <jsnow@redhat.com>
> > > ---
> > > python/qemu/aqmp/legacy.py | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/python/qemu/aqmp/legacy.py b/python/qemu/aqmp/legacy.py
> > > index 46026e9fdc..f86cb29804 100644
> > > --- a/python/qemu/aqmp/legacy.py
> > > +++ b/python/qemu/aqmp/legacy.py
> > > @@ -4,6 +4,17 @@
> > > This class pretends to be qemu.qmp.QEMUMonitorProtocol.
> > > """
> > >
> > > +#
> > > +# Copyright (C) 2009-2022 Red Hat Inc.
> > > +#
> > > +# Authors:
> > > +# Luiz Capitulino <lcapitulino@redhat.com>
> > > +# John Snow <jsnow@redhat.com>
> > > +#
> > > +# This work is licensed under the terms of the GNU GPL, version 2. See
> > > +# the COPYING file in the top-level directory.
> > > +#
> > > +
> > > import asyncio
> > > from typing import (
> > > Any,
> > > --
> > > 2.34.1
> > >
> >
> > Anyone have any strong feelings on me doing this? CC'ing people with
> > known strong feelings on licenses.
> >
> > I'm:
> >
> > (1) Re-affirming that the legacy interface for async QMP is GPLv2
> > (like the classic QMP library is), because the interface and
> > docstrings here are largely copy-pasted from that library. It's
> > heavily remixed and modified, but it is undeniably derivative. (This
> > patch)
>
> If this is going to live for any length of time it is desirable to
> relience the legacy code to GPLv2+ too.
I do intend to drop legacy.py, replacing it with a sync.py module that's similar, but provides an API that resembles the async API more closely.
I have patches, so it shouldn't be *too* far out, but I wanted to fork the repo first, since it's kind of involved and fiddly.
It's genuinely a question of "What can I achieve faster?"
It's unclear, but before I fork the async code out into its own repository, I wanted a better license on it while I'm still the sole author. So I figured "Mostly new license, tiny bits of old" would be the best, quickest way to prevent a backslide.
>
> I've not fully audited the git history, but what little I've looked
> at, the relicensing doesn't look too hard. The overwhealming majority
> of code was by @redhat.com authors, so we can cope with that fairly
> easily. There are a handful of other contributors still around in
> QEMU, and some of the patches are so trivial you couldn't claim
> copyright on them ie where adding 1 parameter to a method call is
> literally the only possible way you could implmenent the change.
> It is never fun to contact everyone, but it looks viable.
>
> > (2) Re-licensing async QMP as GPLv2+. (Next patch)
> >
> > (3) Someday, eventually, adding a different sync interface that
> > doesn't re-mix this specific compatibility interface and will provide
> > better event-waiting primitives and so on. legacy.py will get dropped
> > at that point and the sub-project will become wholly GPLv2+. Until
> > then, it will be mixed.
>
> Overall making it *all* GPLv2+ compat is going to be important if you
> want people to be comfortable using it. If it has a mix of GPLv2+
> and GPLv2-only code in the source tarball, then the overall combined
> work will have to be considered GPLv2-only and that will put people
> off using it. Even if they could theoreticallly restrict their usage
> to only the GPLv2+ parts, many won't get that far before moving on.
I agree. Just a matter of which intermediate states we'll see enroute.
Actually I'll go furthuer and suggest that if we're going to do a
relicensing at all, and your goal is to encourage usage, then GPLv2+
is the wrong choice. Use LGPLv2+ if you want to facilitate usage, while
retaining a copyleft license.
Same question as Andrea. Does the linking exception matter for Python? (The lawyer seemed to intuit to me that it was somewhat untested. I don't think the answer was clear.)
I have no opposition towards LGPL whatsoever, so I guess if it doesn't hurt anything I can just do that instead.
(The lawyer did suggest that MIT was likely the absolute most compatible license I could choose here; but I'm unsure I want to open the floodgates that wide without strong reason. MIT feels like an off-ramp out of open source, and I like to avoid it when possible. That said, the point of this package is to get people to use QEMU and drive them towards our GPL project and ecosystem, so... Maybe MIT would be reasonable. Still, if this component grows in complexity and becomes integrated into a commercial product, I'd be *pretty upset* if any improvements were not published for everyone to benefit from. I think that's why I lean GPL, even though I want to maximize use.)
Thanks,
--js