Re: [edk2-devel] [PATCH v3 4/6] Add BhyvePkg, to support the bhyve hypervisor

["Laszlo Ersek" <lersek@redhat.com>]

On 04/23/20 22:08, Rebecca Cran wrote:
> 
>> On Apr 23, 2020, at 3:19 AM, Laszlo Ersek <lersek@redhat.com> wrote:
>>
>> (2) If you are contributing this new file in "Pluribus Networks, Inc"
>> colors, then please extend the year to 2020 on that line. Otherwise, if
>> you are contributing this on your own behalf (as work derived from
>> Pluribus Networks's earlier work), then please add your own (C) on top
>> as well, marking the year 2020.
>>
>> My point is that the year is 2020, when this file is being introduced in
>> edk2. Thus, there should be a (C) notice naming the year 2020.
> 
> Unfortunately I’m not contributing for Pluribus Networks — that’s why we have to keep some files are BSD-2-Clause.
> Should I add my own copyright line for _all_ files I’m adding under BhyvePkg, or just those that have new/changed content? For example there are several files such as BhyvePkg/PlatformPei/AmdSev.c that I copied verbatim from OvmfPkg that I’d feel especially uncomfortable with claiming copyright over.

If you're 100% sure that you are copying a file from elsewhere in the
tree, as it was at some particular commit of the git history, without
any changes introduced at all as part of the copying, then I guess it's
OK to not add your own copyright.

Normally, this is not difficult to verify for a reviewer, as the
"--find-copies-harder" option of "git show" can find the origin (the
file) of the copy, and display the copy (the new file) in terms of
changes to the origin.

However, the above only works in reference to the *direct pre-patch
state* of the tree. In other words, "--find-copies-harder" cannot
identify a file that, checked out at an *earlier* commit, could be
considered the origin of the copy you are creating *now*.

And given that some of these files were forked from edk2 master in 2014
or so (?), it's not easy to tell whether any difference *now* flagged by
"--find-copies-harder" is

- a difference introduced genuinely by your forking,
- or a more recent change to the *original* that has not been
forward-ported to your fork.

In such cases the ideal solution is to rebase the work; in other words,
re-fork the bhyve stuff from current edk2 / OvmfPkg content. But, I'm
not sure you have capacity for that; it may not be necessary even
functionally speaking; and even to me as the initial reviewer of
BhyvePkg content as one of the stewards, it only matters because of the
copyright notices. (And obviously I'm not a lawyer...)

So, if you are *completely* sure you didn't change anything on those
copies, relative to their fork-off point originals, then I guess it's OK
to not add your (C).

Thanks,
Laszlo

>> (9) I think we should delete the MIT license. At this stage, I can't see
>> anything MIT-covered under BhyvePkg. Do you agree?
> 
> Yes, I agree. I’ll proceed with that change.
> 
> — 
> Rebecca Cran
> 
>