Re: [edk2-devel] [PATCH] BaseTools/PatchCheck.py: Add LicenseCheck

["Leif Lindholm" <leif@nuviainc.com>]

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