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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 09/16/2016 11:22 AM, Lars Kurth wrote:
>
> 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?

_S5 object still exists but it's content has been modified by subsequent
non-Lenovo changes so I think we can not worry about lines 20-30.

But lines 30-43 are still present in current code.

>
>> * 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,

(b) is probably the best description.


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

Both hand-crafted and mk_dsdt-generated ASL file are *conforming* to
ACPI spec but the values (i.e. the topology that the ASL file describes)
are specifically chosen so I don't think (c) is the right answer.

Having said that it is entirely plausible that the author of the patch
ran iasl on his machine and took the output from it to produce the
patch, possibly with minor tweaks. But we, of course, don't know for sure.

> 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). 

I'll add a COPYING file (we already have a README).


-boris



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