Re: [Xen-devel] [PATCH v4 28/33] tools/libxl: Check if fdt_{first, next}_subnode are present in libfdt

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Ian,

On 09/04/15 13:16, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH v4 28/33] tools/libxl: Check if 
> fdt_{first,next}_subnode are present in libfdt"):
>> On Tue, 2015-03-31 at 13:46 +0100, Julien Grall wrote:
>>> After speaking with Ian J. I will:
>>>     - Drop the GPL license from the header as we use the BSD one
>>>     - Add the libxl header license
>>>     - Specify in the commit message why we chose the BSD license.
>>
>> One downside to dropping the GPL bit is that any fixes which we get to
>> this code cannot then easily be upstreamed.
> 
> That's not the case.
> 
> AIUI upstream's version of this file is  BSD(2-clause) \union GPLv2.

Right.

> Our copy of the file will be  BSD(2-clause) \union LGPLv2.1.
> 
> We write LGPLv2.1 in it only to be clear that when anyone distributes
> libxl_libfdt.c as part of libxl they must comply with the terms of the
> LGPLv2.1 for the whole of libxl including libfdt.
> 
> But the dual licence means that anyone who finds something in our
> version that they want to send upstream, this is easy: they choose the
> BSD(2-clause) option in the licence of our version, which (because
> BSD(2-clause) is GPL*-compatible) grants the ability to distribute as
> GPLv2.
> 
> I think that leaving the GPL licence notice in is simply confusing.
> The GPLv2 doesn't grant any additional permissions not covered by
> BSD(2-clause), and the extra restrictions implied by GPLv2 are
> irrelevant in the context of libxl because we are relying entirely on
> the BSD(2-clause) option from upstream.
> 
>> TBH I think it would be find to include both the GPL and BSD and to
>> include a comment that within the context of libxl we have chosen BSD
>> and so the overall license of the work remains LGPL. Ian may disagree
>> though.
> 
> I would say something like this:

I will reuse the text below and add your signed-off-by for the license part.

Regards,

-- 
Julien Grall

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