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