On Fri, Mar 25, 2022, 10:55 AM Eric Blake <ebl...@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 > >
