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

[John Snow <jsnow@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4894 bytes --]

On Fri, Mar 25, 2022, 10:55 AM Eric Blake <eblake@redhat.com> wrote:

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

Thanks, it's helpful to know where people sit on this; it makes me feel
more comfortable with the choice.

In the future, we're probably going to work on Apache/MIT licensed QMP
libraries for other languages, but for a lib that is used in and grew out
of the QEMU tree itself, it didn't feel right to abandon copyleft, even for
a library.


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

Yeah. Part of it is that I intend to drop legacy.py *anyway*, as I had
always intended not to support this exact API - I have always considered it
compat glue for iotests.

(Increasingly off-topic below this point,)

The reason I haven't done this *yet* is because:

(1) I wanted to avoid even more churn in iotests, and I only recently got
aqmp fully stable as a replacement. I didn't want to move too much around
all at once.

(2) I am still waffling a little bit on the design of the sync interface. I
am planning to base my initial design of it based on "what comes up" as I
now wean machine.py off of legacy.py. I expect there will be cases where
some things that are very easy in asyncio will be cumbersome in the sync
interface, and I'll learn a lot just by *doing the replacement*.

Easier to make changes now than later, so ... even if I don't upstream the
switchover right away, the exercise will be informative.

(The goal is actually similar to the qemu_img and qemu_io changes: make qmp
stuff error by default, but add nice facilities for declaring anticipated
errors. This delves into json structure matching, event handling/waiting,
etc. I wanna make it *really* painless to write very thorough and rigorous
tests that give very good feedback on failure.)

(3) There are still a few design bugs in aqmp itself; we just avoid them.
There's a few loose ends and rough edges here and there. I'm not sure what
will happen to the overall design as I embark on fixing them. Maybe
nothing, maybe significant changes; It's too early for me to tell. I just
know where there's some ugly spots that I want to take a serious crack at
fixing before v1.0.

[If anyone is wondering what the flaws are, they're in my qemu fork issues
tracker. They'll be moved when I fork qemu.qmp out of qemu.git. I track
both ideas and actual bugs here.
https://gitlab.com/jsnow/qemu/-/issues?sort=created_date&state=opened ]

That said, I do have a prototype; I add a sync.py and then rebase legacy.py
on top of sync.py. It seems to work fine, but for due diligence I want to
try the exercise of doing a full native replacement without any compat
shims to see what I can learn about what patterns will be helpful and where
the ugly spots are.

(Maybe I should give a micro-talk and walk people through how to write
async native tests and really try to encourage participation there. This
obviously has uses outside of just "io"tests.

Do you think this is useful outside of / ahead of KVM Forum? I want to get
people writing lots and lots of tests.)


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

[-- Attachment #2: Type: text/html, Size: 6815 bytes --]