On Thu, Mar 24, 2022 at 11:25 AM Daniel P. Berrangé <berra...@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é <berra...@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
