Re: Licensing issues

[Juergen Gross <jgross@xxxxxxxx>]

On 13.09.22 17:52, Roger Pau Monné wrote:
> On Fri, Jul 22, 2022 at 02:31:28PM +0000, Andrew Cooper wrote:
> > I've been cross-checking licensing details, and we have some problems.
> >
> > 1) We install xen/include/public/COPYING into /usr/include/xen/COPYING,
> > which is not common practice.  The installed file is mostly useless
> > because it discusses files based on their xen.git paths.
> >
> > 2) We actually use the MIT header for the public interface, but we don't
> > actually call it by it's common name anywhere.
> >
> > 3) The following files are missing the MIT header:
> >
> > /usr/include/xen/foreign/x86_32.h
> > /usr/include/xen/foreign/x86_64.h
> > /usr/include/xen/foreign/arm32.h
> > /usr/include/xen/foreign/arm64.h
> > /usr/include/xen/sys/gntalloc.h
> > /usr/include/xen/device_tree_defs.h
> > /usr/include/xen/errno.h
> >
> > Foreign are autogenerated from headers with MIT licences, so that's an
> > easy fix.
> >
> > errno.h was an oversight when we added it.  There's no problem fixing
> > it, as it is covered by multiple statements elsewhere in the tree.
> >
> > device_tree_defs.h is problematic.  It came into existence in c/s
> > 1c898a9fec7e4 when some LGPL code was moved out of libxl, and some GPL
> > code was copied out of Xen.  So there's currently an GPL+LGPL vs MIT
> > licensing violation.
> >
> > I have not looked through history, but it's likely that the copyright is
> > covered by individuals/companies who are still active members of Xen,
> > and I don't anticipate any problem getting it formally relicensed (it's
> > just a few constants), but this does need fixing.
> >
> > sys/gntalloc.h is more complicated.  It's stated as public domain which
> > is fine for our purposes, but inconsistent with everything else, and we
> > need to adjust the various files we've got which state that the full
> > public API is MIT.
> >
> > But it does raise a different bug.  Why do we have random linux headers
> > committed in the tree, used by some userspace libraries?
> I would guess this is because in the past (pre Linux pvops kernels) we
> wanted distros to be able to build Xen packages on boxes that did not
> run Xen patched kernels, and hence didn't have the user-space headers,
> that's why we had to add them to xen.git.
It isn't so easy.

Those are headers of Xen-specific kernel drivers.

Especially in case new features are added to the upstream kernel drivers,
we want to be able to build the Xen tools using them without requiring a
bleeding edge kernel installed.

This whole scheme requires to not remove any features from the headers,
of course, similar to the handling of our public Xen headers.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature