From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web10.2826.1587723094077016785 for ; Fri, 24 Apr 2020 03:11:34 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JzDm68JQ; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587723093; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HpjN1b88bRCd9dKdWI3icjcfeJ/UfrwzT28pV6P8Odk=; b=JzDm68JQ7skz/Ju1akq5hoXAf/oCU4ud0ohJff7UymPNbvgyFa52mGpZK7k0dHFtnCf4FV I97dYOYtnC881XZH/VFtmnPM0xAvDK58HljIxopTNBAqwgyTbulJdQo0b940iySF8uKDHm fBd8pK9f4dX4qDJBxkWgetzut8Kum0Y= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-207-vSgQX_o2NtSOf8uFZ0rcnA-1; Fri, 24 Apr 2020 06:11:29 -0400 X-MC-Unique: vSgQX_o2NtSOf8uFZ0rcnA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4E0A0102C859; Fri, 24 Apr 2020 10:11:22 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-159.ams2.redhat.com [10.36.113.159]) by smtp.corp.redhat.com (Postfix) with ESMTP id 13E206060D; Fri, 24 Apr 2020 10:11:19 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v3 4/6] Add BhyvePkg, to support the bhyve hypervisor To: Rebecca Cran , devel@edk2.groups.io Cc: Jordan Justen , Ard Biesheuvel , Leif Lindholm , Michael Kinney , Andrew Fish , Peter Grehan References: <20200421030955.114850-1-rebecca@bsdio.com> <20200421030955.114850-5-rebecca@bsdio.com> From: "Laszlo Ersek" Message-ID: <3365d251-e42c-a7ac-d72f-40d97e5e7801@redhat.com> Date: Fri, 24 Apr 2020 12:11:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/23/20 22:08, Rebecca Cran wrote: >=20 >> On Apr 23, 2020, at 3:19 AM, Laszlo Ersek 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. >=20 > Unfortunately I=E2=80=99m not contributing for Pluribus Networks =E2=80= =94 that=E2=80=99s why we have to keep some files are BSD-2-Clause. > Should I add my own copyright line for _all_ files I=E2=80=99m adding und= er BhyvePkg, or just those that have new/changed content? For example there= are several files such as BhyvePkg/PlatformPei/AmdSev.c that I copied verb= atim from OvmfPkg that I=E2=80=99d feel especially uncomfortable with claim= ing 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? >=20 > Yes, I agree. I=E2=80=99ll proceed with that change. >=20 > =E2=80=94=20 > Rebecca Cran >=20 >=20