[Top][All Lists]

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

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

From: BALATON Zoltan
Subject: Re: [PATCH 04/10] meson: option to build as shared library
Date: Tue, 13 Oct 2020 16:41:06 +0200 (CEST)

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.

In case of UTM it seems to be licensed under Apache License 2.0:


which FSF says not compatible with GPLv2 but it is with GPLv3:


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

I hope this does not turn into a legal bike shedding thread that results in finding out there are other than technical problems in the way to accept this series but the contrary, I'd say let the legal problems be handled by those using QEMU and don't reject patches based on maybe possible legal problems. Stating the licence clearly and maybe providing links to further resources to resolve licence problems in QEMU docs should be enough.


reply via email to

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