From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by mx.groups.io with SMTP id smtpd.web11.1622.1588086108446725790 for ; Tue, 28 Apr 2020 08:01:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=ZDQrGuY1; spf=pass (domain: nuviainc.com, ip: 209.85.221.68, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f68.google.com with SMTP id x18so25016751wrq.2 for ; Tue, 28 Apr 2020 08:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Mf982aXvOIUwR5QEg098TUaGSerLmULC8VSiSVKONtY=; b=ZDQrGuY1T9Ct9D7zrXbSpF8u820qcWM3fm+CzefWHeDHQSco5FGMr6tDiHF7+YowKg aou/hLwXHZHDY3ls8d7Srrluh6wzEcVr7w+gH4vLiBeMApBkpD8RBIikp0axvfSmPvvq B1iuRca7t0yJYEHTQOJlZQjZWhHBK1yUcIiDwvn19VYr03Q66jMJjnGkAwNhRs0FchPP 908toOwxB2fC/I/n+JFpVT9psLaPb/BGtkrndCDgExcPWqzN9RwEXFn+7lX8TJqhx2Fx CbTMpyyPTLp239BCSCNv9FLxChZobers9GwkhAcXeUD/qAjmUXIU/ec6fqjZv27AZImM 8g7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Mf982aXvOIUwR5QEg098TUaGSerLmULC8VSiSVKONtY=; b=p4JKLqvyTXkhnUDmLCDWfXGtL3YlquLDPfDfIoE5bKFojdJkYgfnUbMfzi9d6IlSc9 HmbC4aYrH+F+QVZdoQL0By9spVMyB2zOeFLwPpWOeNc+BpmGSmeNIOmVEXpwycQJh4Rd Ws9wqW8PX1MxPfwK/roXCzPfwBcOf8nVzBjcOaCM7HmIAipHXCJXz3IObNXz8xtXuz3i Nt9sF9g4qEvjnoDJfvSceElF4am4rNoAnLtUFN0bkyL8j7oh01fftFhWTIFkcUy0swEO 3moxVWKKhApk5Z+pS/e7dzkXHvf8fgthgKdiprY8glH1YYnl084NQXO9BzHdtHTQiaLl 8L6g== X-Gm-Message-State: AGi0PuZm5IAqVX+qE2+ptv3Ezn6j+xzYnQdIiHzXgHXXzWXN0vPd2T5x fdtD7rwtoIlfrlX3Xq2PR/bXpg== X-Google-Smtp-Source: APiQypI+zAx+kSm0sXWxT/HlmNMqe4GNuV8k9n2pGyCbKTOhxkgeEGRH6WxTIqO1rAx6ScQx8GxAVw== X-Received: by 2002:a05:6000:110a:: with SMTP id z10mr33493123wrw.389.1588086106916; Tue, 28 Apr 2020 08:01:46 -0700 (PDT) Return-Path: Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id s9sm27566924wrg.27.2020.04.28.08.01.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2020 08:01:46 -0700 (PDT) Date: Tue, 28 Apr 2020 16:01:43 +0100 From: "Leif Lindholm" To: Laszlo Ersek Cc: devel@edk2.groups.io, liming.gao@intel.com, "Kinney, Michael D" , "Zhang, Shenglei" , "Feng, Bob C" , Rebecca Cran Subject: Re: [edk2-devel] [PATCH] BaseTools/PatchCheck.py: Add LicenseCheck Message-ID: <20200428150143.GD21486@vanye> References: <20200422065655.75392-1-shenglei.zhang@intel.com> <21694fd0-aa33-0865-2da8-dec2821deb4c@redhat.com> <20200424162502.GO14075@vanye> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 28, 2020 at 15:59:48 +0200, Laszlo Ersek wrote: > On 04/24/20 18:25, Leif Lindholm wrote: > > On Fri, Apr 24, 2020 at 18:13:58 +0200, Laszlo Ersek wrote: > >> On 04/22/20 18:01, Liming Gao wrote: > >>> Mike: > >>> The checker purpose is to make sure the correct license be used for new added file. If the file has the different license, it should be reviewed carefully. > >>> > >>> I remember we still have one open for third party non bsd+patent > >>> code (the detail can refer to > >>> https://edk2.groups.io/g/devel/message/41639). Now, there is no > >>> non bsd+patent license files to be added in edk2 after edk2 > >>> switches to bsd+patent license. > >> > >> Some files introduced by Rebecca's BhyvePkg patch series come under the > >> 2-clause BSD License, and not the 2-clause BSD + Patent License. And > >> Rebecca cannot relicense them because she's not the (sole) copyright holder. > > > > I disagree. > > BSD+Patent is a pure superset of BSD - this was the logic by which the > > whole EDK2 project was relicensed in the first place. Rebecca can > > definitely add the explicit patent grant as part of the contribution. > > > > The explicit patent grant of course affects only the contributor, and > > users of the contributed code, not the original source (and the > > originating project would not be able to take modifications back > > without accepting the amended license). > > > >> Readme.md states: > >> > >> 4. It is preferred that contributions are submitted using the same > >> copyright license as the base project. When that is not possible, > >> then contributions using the following licenses can be accepted: > >> * BSD (2-clause): http://opensource.org/licenses/BSD-2-Clause > >> * BSD (3-clause): http://opensource.org/licenses/BSD-3-Clause > >> * MIT: http://opensource.org/licenses/MIT > >> * Python-2.0: http://opensource.org/licenses/Python-2.0 > >> * Zlib: http://opensource.org/licenses/Zlib > >> [...] > >> Contributions using other licenses might be accepted, but further > >> review will be required. > >> > >> This seems to imply that the "normal" 2-clause BSDL does not require > >> "further review". > > > > And I still hold the opinion that I held when I posted the message > > referenced above - we do not today have any real policy here. > > > > Now, as per my comment above, I don't think that applies in this > > situation, but it is still somethihg we must resolve (i.e. take an > > active decision about) before we accept any non BSD+Patent content > > into any of our BSD+Patent trees. > > I couldn't be happier to *share* the burden of verification with others, > of licensing questions in new contributions. But for that, others -- > more versed in licensing questions than I am -- have to be willing to > *look* at those contributions. > > Based on the above, I now have no idea what to ask of Rebecca, regarding > the 2-clause BSDL on some of the files she's contributing. Apologies if I was unclear. My suggestion (and opinion) was that this contribution can be completely switched over to SPDX-License-Identifier: BSD-2-Clause-Patent without any conflict with the originating code's SPDX-License-Identifier: BSD-2-Clause since the former is simply a superset of the latter. Had it been (for example) BSD-3-Clause, my suggestion would have been that it should be contributed as SPDX-License-Identifier: BSD-3-Clause AND BSD-2-Clause-Patent as per the "Representing Multiple Licenses" section in appendix V of https://spdx.org/spdx-specification-21-web-version. But we have not as a project explicitly approved the use of SPDX OR and AND operators, and I have heard opinions to the extent that that would be desirable before we start using them. This has however no bearing on the change of BSD-2-Clause to BSD-2-Clause-Patent. > Here's what I know: > > - Microsoft does not want BhyvePkg to be in edk2, because "platform! boo!", This is an open source project, in which companies do not have assigned votes on individual patches or approaches. Hence, inasmuch as an opinion from Microsoft is to be paid attention to beyond that of any other entity, Michael Kubacki is by some margin the employee most involved in core EDK2 development. I have not heard his opinion on the matter. > - I do want BhyvePkg to be in edk2, minimally because that's only fair > and consistent with ArmVirtPkg and OvmfPkg (BhyvePkg is virtual), I agree. > - I as a steward am especially responsible for reviewing new top-level > package additions, and that entails licensing bits too, Sure. > - I'm not particularly good with licensing bits, but thus far noone else > from the stewards has chimed in on the series, at all. AFAIR. Apart from on this patch, I have responded on another thread ... but now that you mention it I realise that thread was off-list. I confess to mostly having ignored this set as 1) I have no experience with bhyve and 2) some quick searching gives me the impression that is is (currently) x86 only. But as per the above: I am of the opinion that based on the rule we applied for keeping ArmVirtPkg, OvmfPkg, and to some extent EmbeddedPkg in edk2, this is also the appropriate location for bhyve. While I understand that dealing with components supplied from many different directions is something that has been "just the way it is" in the BIOS industry since before there *was* a UEFI, I (like you) am not convinced by the arguments I have seen in threads on this topic for keeping things out of EDK2. If anything, they have strenghthened my opinion, since several of them seem to boil down to wanting to push *more* responsibility for updating platform code to adhere to changing core APIs onto the platform maintainers. I feel that tips the balance the wrong way. / Leif