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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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