From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0F39C2194EB70 for ; Wed, 20 Mar 2019 11:25:22 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 331D93078AAC; Wed, 20 Mar 2019 18:25:22 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-169.rdu2.redhat.com [10.10.120.169]) by smtp.corp.redhat.com (Postfix) with ESMTP id CE56760852; Wed, 20 Mar 2019 18:25:16 +0000 (UTC) To: Lars Kurth , Julien Grall , "Kinney, Michael D" Cc: "edk2-devel@lists.01.org" , Ard Biesheuvel , Jordan Justen , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , Stefan Berger References: <6de07821-a05e-9446-7ef6-c178eaf2fdfb@arm.com> <8F40F2BF-B40F-4338-A832-70AE84B26408@citrix.com> <6FBC013D-4BC9-454C-9D4D-87C96F435704@citrix.com> <720E0EE9-2AED-4110-827D-B87DE5F52862@citrix.com> From: Laszlo Ersek Message-ID: <2439277a-b103-50d4-4de2-f1d3e17c53a3@redhat.com> Date: Wed, 20 Mar 2019 19:25:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <720E0EE9-2AED-4110-827D-B87DE5F52862@citrix.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Wed, 20 Mar 2019 18:25:22 +0000 (UTC) Subject: Re: PATCH] Change EDK II to BSD+Patent License X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 18:25:23 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 03/20/19 14:03, Lars Kurth wrote: > > > On 15/03/2019, 17:48, "Lars Kurth" wrote: > > > > On 15/03/2019, 10:18, "Julien Grall" 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 . (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. .) 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