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

[Daniel P . Berrangé]

On Thu, Mar 24, 2022 at 11:03:12AM -0400, John Snow wrote:
> On Thu, Mar 24, 2022, 5:03 AM Daniel P. Berrangé <berrange@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.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|