Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Sep 19, 2019 at 01:54:40PM +0200, Philippe Mathieu-Daudé wrote:
> On 9/19/19 1:41 PM, Daniel P. Berrangé wrote:
> > On Thu, Sep 19, 2019 at 01:18:57PM +0200, Stefan Weil wrote:
> >> Am 19.09.2019 um 12:59 schrieb Philippe Mathieu-Daudé:
> >>> Add a job to cross-build QEMU with WHPX enabled.
> >>>
> >>> Use the Win10SDK headers from the Android Project, as commented
> >>> in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03842.html
> >>>
> >>> Based-on: <20190918121101.30690-1-philmd@redhat.com>
> >>> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03844.html
> >>>
> >>> Philippe Mathieu-Daudé (2):
> >>>   tests/docker: Add fedora-win10sdk-cross image
> >>>   .shippable.yml: Build WHPX enabled binaries
> >>>
> >>>  .shippable.yml                                |  2 ++
> >>>  tests/docker/Makefile.include                 |  1 +
> >>>  .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
> >>>  3 files changed, 24 insertions(+)
> >>>  create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
> >>>
> >>
> >> Please note that the required header files are part of the Win10SDK
> >> which is not published under a free license, so I am afraid that they
> >> cannot be used with QEMU code to produce free binaries.
> > 
> > Can you elaborate on why you think that is the case ?
> > 
> > Looking at the 3 header files used, all they contain are struct
> > definitions and integer constants, fortunately no functional
> > code in macros or inline functions. As such, it is questionable
> > whether the headers alone can be considered copyrightable material.
> > Any compatible implementation that follows the WHPX API/ABI will by
> > neccessity be the same, modulo code style.
> > 
> > Further, from a GPL POV, these headers should fall under the system
> > libraries exception, as WHPX is core low level operating system
> > functionality.
> > 
> > There's a valid legal question as to how to we got access to the
> > files in the first place. Assuming they are freely distributable
> > though, given their hosting on Google Android downloads.
> > 
> > So the fact that the headers are not under an open source / free
> > license doesn't look like it should impact the ability to distribute
> > the resulting QEMU binaries.
> 
> Are we distributing the resulting binaries?
> I don't think so, we only build until linking in a scratch container and
> discard its content, we don't have access to the container storage via
> Shippable (also Travis). We only use the exit code and the console
> output from the build.
> 
> We are not distributing those headers neither, as we currently do not
> distribute the docker images.

No, but I think its none the less useful to consider what impact is
on distribution of binaries. Currently Stefan builds & distributes
the QEMU Windows binaries for each release. I think the ideal would
be for Windows builds to be a core deliverable of the upstram release
process. So this docker CI job can be viewed as a stepping stone to
that point, especially if it is made to run the full NSIS installer
build, not just standalone binary build.

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