qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 04/10] meson: option to build as shared library


From: Joelle van Dyne
Subject: Re: [PATCH 04/10] meson: option to build as shared library
Date: Tue, 13 Oct 2020 08:16:46 -0700

I will start a separate conversation of UTM's license compatibility.

Regarding the patch, would some sort of warning message in configure
(if building as a shared library) regarding the license be wise? Or
would it pollute the output logs?

-j

On Tue, Oct 13, 2020 at 7:46 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Tue, Oct 13, 2020 at 04:41:06PM +0200, BALATON Zoltan wrote:
> > On Tue, 13 Oct 2020, Daniel P. Berrangé wrote:
> > > On Mon, Oct 12, 2020 at 04:29:33PM -0700, Joelle van Dyne wrote:
> > > > From: osy <osy86@users.noreply.github.com>
> > > >
> > > > On iOS, we cannot fork() new processes, so the best way to load QEMU 
> > > > into an
> > > > app is through a shared library. We add a new configure option
> > > > `--enable-shared-lib` that will build the bulk of QEMU into a shared 
> > > > lib.
> > > > The usual executables will then link to the library.
> > >
> > > Note that QEMU as a combined work is licensed GPLv2-only, so if an app is
> > > linking to it as a shared library, the application's license has to be
> > > GPLv2 compatible. I fear that shipping as a shared library is an easy way
> > > for apps to get into a license violating situation without realizing.
> >
> > Please don't let that be an obstacle in merging this series. They'll do it
> > anyway as seen here so having it upstream is probably better than having a
> > lot of different/divergent forks.
>
> "They'll violate the license anyway" is not a compelling argument.
>
> > In case of UTM it seems to be licensed under Apache License 2.0:
> >
> > https://github.com/utmapp/UTM/blob/master/LICENSE
> >
> > which FSF says not compatible with GPLv2 but it is with GPLv3:
> >
> > http://www.gnu.org/licenses/license-list.html#apache2
> >
> > Not sure however if that's for using Apache licenced part in GPLv2 code or
> > the other way around like in UTM in which case I think the whole work will
> > effectively become GPLv3 as most parts of QEMU is probably GPLv2+ already or
> > BSD like free that should be possible to combine with only files explicitely
> > GPLv2 in QEMU remaining at that license and UTM parts are Apache 2.0 when
> > separated from QEMU. I have no idea about legal stuff whatsoever but
> > combining two free software components should be legal some way (otherwise
> > it's not possible to combine GPLv2 with GPLv3 either).
>
> You need to distinguish between GPLv2-only and GPLv2-or-later.
>
> GPLv2-or-later is fine as that upgrades to GPLv3 when used in a
> combined work with Apache License or GPLv3 software.
>
> GPLv2-only will, by design, *not* upgrade to newer GPL versions
> when combined - it is simply license incompatible.
>
> QEMU unfortunately has a bunch a GPLv2-only code present that we
> cannot eliminate.
>
> 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 :|
>



reply via email to

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