Re: [PATCH 01/10] python/aqmp: add explicit GPLv2 license to legacy.py

[John Snow]

On Thu, Mar 24, 2022 at 11:25 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Thu, Mar 24, 2022 at 11:03:12AM -0400, John Snow wrote:
> > On Thu, Mar 24, 2022, 5:03 AM Daniel P. Berrangé <berrange@redhat.com>
> > wrote:
> >
> > > On Thu, Mar 24, 2022 at 09:00:05AM +0000, Daniel P. Berrangé wrote:
> > > > 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.
>
> Let us contemplate two scenarios
>
>  - GPL vs LGPL  *does* make a legal difference for Python, in the
>    same way it does for C
>
>       => Using LGPL over GPL is therefore a benefit for QEMU users
>
>  - GPL vs LGPL does *not* make  a legal difference for Python, in
>    the same way it does for C
>
>       => Using LGPL over GPL makes zero differnce for QEMU users
>
> In the absence of information that can confidently predict
> which scenario applies, then the right answer is to pick LGPL.
> It might be a benefit, and if no, it has no downside [1].
>
>
> [1] Yes, there could be some subtle reason why LGPL is worse
>     than GPL in Python than in C, but I've not seen sign of
>     that being raised, and I have seen plenty of POVs saying
>     LGPL is still a benefit.
>
> > (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.)
>
> Yep, as I mentioned, I don't want to see us abandon copyleft either.
>
> Of course everyone has their own preferred license, so I'm sure
> people who write apps with MIT, will think we should use MIT
> too. Ultimately though, if we choose LGPL, they can still use
> our module from an MIT licensed app, or any other licensed app
> for that matter.
>

OK, thanks for your input here. My plan right now, then, is:

(1) Relicense aqmp as LGPLv2+
(2) Fork into new repo as discussed previously on qemu-devel
(3) Work on dropping legacy.py (GPLv2) in favor of sync.py (LGPLv2+)

I plan to version the fledgling forked repo as 0.0.z until I drop
legacy.py, and then I'll version as 0.y.z for "a while", (A release or
two for QEMU?), and then tag v1.0.0.
(As we discussed earlier, with a non-finalized API, I'll be pinning
QEMU to use specific versions until it stabilizes.)

I think you're right that we probably could relicense legacy.py
without too much fuss, I think the most significant contributions that
didn't come from Luiz or myself were made to docstrings, and only
extremely few contributions came from non-RH addresses. Still, I plan
to drop the whole file anyway, so I figured I'd side-step the
relicensing justification there, even if it's doable.

--js