On 04/23/20 22:08, Rebecca Cran wrote: > >> On Apr 23, 2020, at 3:19 AM, Laszlo Ersek <ler...@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 > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#58049): https://edk2.groups.io/g/devel/message/58049 Mute This Topic: https://groups.io/mt/73165367/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
