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.gei...@vido.info> > > > 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@lists.xen.org https://lists.xen.org/xen-devel