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

[Eric Blake <eblake@redhat.com>]

On Thu, Mar 24, 2022 at 12:07:24PM -0400, John Snow wrote:
...
> > 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+)

That plan works for me.  I'm happy for any of my contributions to be
widened to LGPLv2+, but not with the thought of abandoning copyleft by
going all the way to MIT.

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

I'm happy to relicense any of my contributions as needed (did I
actually write any, or just provide reviews?), but as you say,
sidestepping the process may get to the same end goal even faster.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org