[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: License advice for Async QMP

From: Daniel P . Berrangé
Subject: Re: License advice for Async QMP
Date: Tue, 13 Jul 2021 19:39:09 +0100
User-agent: Mutt/2.0.7 (2021-05-04)

On Tue, Jul 13, 2021 at 02:26:28PM -0400, John Snow wrote:
> Hi,
> I'm deep into writing a new Async QMP library for QEMU, one that I intend
> to ship outside of our castle walls and host on PyPI.
> I need to choose a license for it. I slapped GPLv2 on it in keeping with
> the license on the original library by Luiz Capitulino (And it is generally
> my preference), but I was debating loosening the license to MIT so that it
> plays nicer with Apache-licensed projects. ...Maybe.
> I don't know if that's really necessary, though, and I do generally prefer
> a "copyleft" to "permissive" these days.
> My current understanding:
> 1. Apache-licensed projects probably cannot vendor GPL code of any kind
> (v2, v3, LGPL)
> 2. Apache-licensed projects can *probably* import GPL'd Python code (v2,
> v3, LGPL) at runtime without creating a "derivative work", but it isn't a
> settled matter, legally.
> 3. LGPL has little or no effect on a Python library, because you do not
> link against Python as such to produce a combined work -- The PIP installer
> generally re-acquires the original distribution and uses that at runtime
> instead, which avoids legal hassle from bundling GPL code.
> 4. I would *probably* need a permissive license only if I wanted to allow
> the vendoring of this Python code by non-GPL projects.
> Does that sound about right?

AFAIK, "vendoring" is not relevant as a point to consider from a license
compatibility POV. Vendoring is just a fancy word for bundling 3rd party
software, and this doesn't create a derivative work - they remain separate
entities. I see this as the same situation as the FSF example of an
installer bundling the software it is installing:


The main time I've had people raise questions about bundling GPL code in
an Apache project, the problem wasn't about license compatibility. It was
simply their personal desire to never be hosting & distributing any code
that is GPL licensed themselves. They are certainly entitled to hold that
view, but at the same time I'm disinclined to use that as the only reason
to alter my own license preferences, if the licenses are otherwise
compatible from a legal POV.

IOW, if your preference is to use a copyleft license I don't see a
reason to change it. GPL is a common license choice for a lot of python

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]