Re: PATCH] Change EDK II to BSD+Patent License

[Laszlo Ersek <lersek@redhat.com>]

On 03/20/19 14:03, Lars Kurth wrote:
> 
> 
> On 15/03/2019, 17:48, "Lars Kurth" <lars.kurth@citrix.com> wrote:
> 
>     
>     
>     On 15/03/2019, 10:18, "Julien Grall" <julien.grall@arm.com> wrote:
>     
>         >      
>         >      EDK2 is converting the full copyright in each file to SDPX identifier. While the
>         >      copyright looks like an MIT license, it has never been confirmed. Andrew Cooper
>         >      suggested you might be able to confirm.
>         >      
>         > Is there a web-link to the files/repos such that I don’t have to clone the repo
>         > Lars
>         
>         Here an example of files from Xen public headers:
>         
>         https://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=xen/include/public;h=0618b0134d2b9babcba71a3f0f86be5a84468b50;hb=HEAD
>         
>     OK, this makes this easy then. Because in all likelihood, the files were copied from xen/include/public and then the COPYING file https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/COPYING applies, which states that everything in this directory is MIT, unless stated otherwise in the file. 
>     
>     So as long as someone confirms that the files in OvmfPkg/Include came from xen/include/public, this is a clear case of a MIT license
>     If they are files from other directories in Xen, check the COPYING file in the original directory (or if there is none in the parent directory) and check the COPYING file
>     
>     I am not so clear about where the files in XenBusDxe came from, but the same principle applies. 
>     
>     If someone groups these files by "original directory in Xen" to File ... I am happy to do a final sanity check and sign it off and/or deal with any unclear cases
>     
> Nobody stepped up, sigh.

Sorry, no capacity. I suggested to handle this in a separate TianoCore
BZ, with much more focused context. I asked Mike to file that BZ (he had
offered earlier, if I understood correctly), or else to notify me to
file it.

> I am also VERY confused by this thread. 

Not surprising -- this is a side topic in the thread we're in.

> Is the issue that you don’t trust that the license specified in the files are correct?

No -- the question is whether the license included in the files
mentioned is indeed the MIT license, suitable for a replacement with the
appropriate SPDX license ID.

> 
>     > (2.2.2) Files that seem to be covered by the MIT license.
>     > 
>     >            OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h
> 
> I can't identify where in the Xen tree this file came from. There is no corresponding xen.h file in the Xen tree at [xen.git] / xen / include / public / arch-arm /
> @Julien, @Anthony: can you clarify

This file was first added to edk2 in b94c3ac93d57 ("Ovmf/Xen: implement
XenHypercallLib for ARM", 2015-02-28).

https://github.com/tianocore/edk2/commit/b94c3ac93d57

And from the Xen project (I think), it was Reviewed-by: Stefano
Stabellini <stefano.stabellini@eu.citrix.com>. (I vaguely recall that
Stefano's emai has changed since.)

> 
>     >            OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_32.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_64.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/event_channel.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/grant_table.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/hvm/hvm_op.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/hvm/params.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/io/blkif.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/io/console.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/io/protocols.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/io/ring.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/io/xenbus.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/io/xs_wire.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/memory.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/xen-compat.h
>     >            OvmfPkg/Include/IndustryStandard/Xen/xen.h
> 
> These all appear to originate from [xen.git] / xen / include / public
> In the Xen tree these all have explicit MIT licenses, which implies that the license headers are indeed correct.

Thanks -- so can we replace the license blocks with

  SPDX-License-Identifier: MIT

? (See e.g. <https://spdx.org/ids-how>.)

But, again, this should be discussed in that separate BZ then.

> 
>     >            OvmfPkg/XenBusDxe/XenBus.c
>     >            OvmfPkg/XenBusDxe/XenStore.c
>     >            OvmfPkg/XenBusDxe/XenStore.h    
> 
> I do not know where these files come from. The files do not appear to come from a Xen project repo. 

See commit a9090a94bb4a ("OvmfPkg/XenBusDxe: Add XenStore client
implementation", 2014-10-29), by Anthony.

https://github.com/tianocore/edk2/commit/a9090a94bb4a

The commit message states,

> Origin: FreeBSD 10.0
> License: This patch adds several files under the MIT licence.

> So, unless you trust that the license in the headers are correct, the right thing would be to identify the source and check whether the license text has been imported unmodified

We do trust that the license blocks, as they exist, are correct. Where
we need help & support is the mapping/replacement of those verbose
license blocks to/with SPDX-License-Identifier tags.

> Maybe Anthony can do this, if this indeed is needed

Thanks,
Laszlo