Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 16/09/2016 13:41, "Boris Ostrovsky" <boris.ostrovsky@xxxxxxxxxx> wrote:

>On 09/16/2016 02:45 AM, Jan Beulich wrote:
>>
>>>> And then there's the question of whether excluding things from the
>>>> build, but having them present in the sources actually helps.
>>> The main reason for this whole relicensing debacle is to prevent
>>>non-GPL
>>> binaries from linking against GPL objects, and this patch allows us to
>>> do that. Yes, there will be be two non-LGPL files (dsdt.asl amd
>>> mk_dsdt.c, which I will revert back to GPL) in an otherwise LGPL
>>> directory but that's an in-convenience and not a license violation.
>> Well, if linking is all this is about, then it's fine of course. I'm
>>just
>> not a license expert, so we'd need this acked by someone who is
>> more familiar with the differences and implications.
>
>I think Ian and Lars (added both here) would be the most experienced in
>this matter.

It is all about linking. The terms of the GPL "spread" to derivative works
through both “dynamic” and “static” linking of binaries only. So you can
have one directory, which contains GPL and non-GPL licensed files, and not
suffer GPL-contagion as long as you can guarantee that the binaries
produced are of a specific license and you only link compatible binaries
with each other. Of course that is brittle and error prone.

> So I looked again at commit 801d469ad8b2b88f669326327df03d03200efbfb
> (which is the patch from Lenovo) and it only does 2 things (assuming I
> parsed ASL correctly):
> * Adds _PIC method
As far as I can tell, only lines 30-43 of the original code remains.
Is this correct?

> * Controls and describes legacy PCI interrupt routing. This
> functionality has actually been moved into mk_dsdt.c and so this ASL
> code is now generated.


Has it been 
a) moved, 
b) re-implemented in a different language using the ASL code as template,
or 
c) implemented in C based on the ACPI spec?

Given that mk_dsdt.c is C and the original contribution is entirely ASL
(note that acpi_dsdt.c was generated from the ASL), a) does not appear to
be the case.

b) can probably not be excluded, in which case it may be safer to keep
mk_dsdt.c as GPL. But it would be a grey area.

If we knew for sure or it is plausible enough that it was c), then
mk_dsdt.c does not need to be GPL. And then the remaining Lenovo code in
dsdt.asl may be simple enough to not be copyrightable.

Whatever the answer, I would like to get Ian's opinion.
And it is still preferable though to have the entire component in LGPL and
to get a Lenovo ACK.

>I could move these two files into tools/libacpi/gpl subdirectory to
>emphasize their special licensing.

That would definitely make things easier and avoid any future mistakes
which lead to licensing issues.

Another general comment is that the component should have a COPYING file
and maybe a README.source file in the new component (that will make future
forensics easier). 

Regards
Lars

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