Re: [Xen-devel] [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code

[Wei Liu <wei.liu2@xxxxxxxxxx>]

CC Lars

More licence stuff. Do you have contact(s)?

Wei.

On Fri, Jul 08, 2016 at 11:57:59AM -0400, Boris Ostrovsky wrote:
> On 07/08/2016 11:50 AM, Ian Jackson wrote:
> > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH v1 02/20] 
> > acpi/hvmloader: Move acpi_info initialization out of ACPI code"):
> >> Having different licenses will invite the lawyers in the conversation
> >> which can drag things out.
> > We don't want libxl to have some confusing combination of
> > alleged-licences.
> >
> >> A quick read says one can add an exception to GPLv2 license to allow it
> >> to be linked (see 
> >> https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs)
> >> but that would require Copyright OK from the original holders.
> >>
> >> It would be far easier to ask the copyright holders:
> > Yes.  That seems to be Citrix, Intel, Sun (Oracle), IBM, and:
> >
> >>  Tobias Geiger <tobias.geiger@xxxxxxxxx>
> 
> 
> Do we need to get consent from companies only or (also) from individuals
> listed in the files? Which means Keir and Kamala Narasimhan (who works,
> or at least used to work) for Citrix.
> 
> For IBM --- whom can we contact?
> 
> >>
> >> If they would be OK making the code (this is from
> >> tools/firmware/hvmloader/acpi/acpi2_0.h) lGPL.
> > Right.
> >
> >> Or is there some other technical way around this?
> > No.
> >
> >> I can't recall whether the 'dlopen' (so runtime loading
> >> vs linking) of an GPL library is from Lesser GPL is OK.
> >> (so proprietary code linking with libxl, and libxl dlopen'ing
> >> the libacpi code').
> > This kind of attempt at licence workaround by some kind of technical
> > bodge is not legally effective.
> 
> We don't build files in libacpi as a dynamic library. The object files
> are linked against whoever wants to use the functionality, just like
> what we do for libelf.
> 
> -boris
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel