License advice for Async QMP

License advice for Async QMP

[John Snow]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 1516 bytes --]

Re: License advice for Async QMP

[Daniel P. Berrangé]

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:

   https://www.gnu.org/licenses/gpl-faq.en.html#GPLCompatInstaller

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
stuff.

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

Re: License advice for Async QMP

[Markus Armbruster]

John Snow <jsnow@redhat.com> writes:

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

In addition to what Daniel wrote: I'd recommend GPLv2+ over GPLv2.

[...]

Re: License advice for Async QMP

[Daniel P. Berrangé]

On Wed, Jul 14, 2021 at 04:35:17PM +0200, Markus Armbruster wrote:
> John Snow <jsnow@redhat.com> writes:
> 
> > 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.
> 
> In addition to what Daniel wrote: I'd recommend GPLv2+ over GPLv2.

Yep, that'd be my pref too generally.

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