On Thu, Jul 02, 2020 at 11:27:25 +0200, Laszlo Ersek wrote:
> This likely comes from BaseTools commit a4cfb842fca9
> ("BaseTools/PatchCheck.py: Add LicenseCheck", 2020-06-12).
>
> One approach would be to remove "VbeShim.h" from the tracked files under
> OvmfPkg, replacing it with a PREBUILD command in the OVMF DSC files.
> (Then Bhyve could do the same.)
>
> However, the generator, namely "VbeShim.sh", is not written in Python,
> but in (POSIX) shell, and so it can't be called from PREBUILD (I think
> it would break OVMF builds on Windows).
>
> I don't know what to tell you, other than the blanket license
> enforcement from commit a4cfb842fca9 is likely wrong.
*Reads patch*
*Figuratively spits coffee all over keyboard*
No, this is not OK.
We *STILL* have no agreed process for accepting non bsd+patent content
since we dropped the contribution agreement. I have tried to raise
this issue several times in the past, and there has never been any
outcome from resulting discussions.
So now I'm going to send out a two-patch set consisting of:
- Reverting a4cfb842fca9. (Doing nothing is better than implying that
anything !bsd+patent can currently be added to the tree.)
- Deleting the statement in ReadmMe.rst erroneously claiming that the
includion of these other licenses are acceptable until such a point
an active decision has been taken, approved by the community, that
this is permitted.
> The generated include file *must* be a ".h" file, otherwise the INF file
> reference won't be able to trigger an incremental build, if I understand
> correctly. So replacing the ".h" suffix with something else, such as
> ".genh" (for "generated header") won't work, I believe.
>
> Modifying the printf invocations in the generator script to also output
> a license header would not be right either, IMO. A license tag makes no
> sense (I think) without a copyright (C) statement. And what copyright
> (C) notice should we put on a generated file?
>
> Furthermore, although "ReadMe.rst" in the project root states
>
> """
> Contributions of code put into the public domain can also be accepted.
> """
>
> I don't see how the license check implemented in commit a4cfb842fca9
> would accommodate a public domain contribution. (I think it would be
> fine to place the the generated header file in the public domain, *if*
> (a) we could express that somehow (is there an SPDX tag for that?),
> *and* (b) if that would eliminate the need for a (C) notice / authorship
> mark.)
Public domain is not an OSI-compatible license:
https://opensource.org/node/878
The public domain statement is also one that needs to be re-evaluated
in light of the dropped contribution agreement.
/
Leif
> Note that this generator use case is not unique to QemuVideoDxe; see for
> example commit 1e9d6b0f98b5 ("OvmfPkg/OvmfXen: Creating an ELF header",
> 2019-08-21).
>
> I've now filed a bug for BaseTools:
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=2833
>
> Once that bug is solved -- that is, once we standardize a tag for
> marking generated source files as such --, we can update "VbeShim.sh" to
> produce the tag, in "VbeShim.h". Then OvmfPkg/Bhyve can do the same.
>
> Thanks
> Laszlo
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#61972): https://edk2.groups.io/g/devel/message/61972
Mute This Topic: https://groups.io/mt/75255538/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
