From: "Daniel P. Berrangé" <berrange@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Luiz Capitulino <lcapitul@redhat.com>,
Eric Blake <eblake@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
Andrea Bolognani <abologna@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: License advice for Async QMP
Date: Tue, 13 Jul 2021 19:39:09 +0100 [thread overview]
Message-ID: <YO3dzXb9qhXSb88e@redhat.com> (raw)
In-Reply-To: <CAFn=p-Y_j0fQJCGHrwryk9=7qjPPU6VHYiOSqiAuz==Mn2s4jw@mail.gmail.com>
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 :|
next prev parent reply other threads:[~2021-07-13 18:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-13 18:26 License advice for Async QMP John Snow
2021-07-13 18:39 ` Daniel P. Berrangé [this message]
2021-07-14 14:35 ` Markus Armbruster
2021-07-14 14:40 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YO3dzXb9qhXSb88e@redhat.com \
--to=berrange@redhat.com \
--cc=abologna@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=jsnow@redhat.com \
--cc=lcapitul@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).