From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BA1B521D0FE0B for ; Wed, 26 Jul 2017 03:37:21 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B4E1C272B2; Wed, 26 Jul 2017 10:39:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B4E1C272B2 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-75.phx2.redhat.com [10.3.116.75]) by smtp.corp.redhat.com (Postfix) with ESMTP id 52DE570BDC; Wed, 26 Jul 2017 10:39:22 +0000 (UTC) To: "Kinney, Michael D" , "edk2-devel@lists.01.org" Cc: Leif Lindholm , Andrew Fish , "Justen, Jordan L" References: <20170724234516.12552-1-michael.d.kinney@intel.com> <17429ffe-6b32-4b0c-8ec2-669372253d59@redhat.com> From: Laszlo Ersek Message-ID: Date: Wed, 26 Jul 2017 12:39:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 26 Jul 2017 10:39:23 +0000 (UTC) Subject: Re: [Patch V4 0/6] Update to Tiano Contribution Agreement 1.1 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 10:37:22 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/25/17 18:06, Kinney, Michael D wrote: > Laszlo, > > If you look at patch V4 #6, you will see the Readme.md has been > added that lists all the licenses in use. There are more than > just the default BSD license and the 3 components in the OvmfPkg. > I prefer the idea of using Readme.md to provide an clear inventory > of the licenses in use in the entire repository. Thanks, sorry for missing this -- from other parts of the discussion I think I understood the "inventory thing", but I missed that it actually mapped each non-default license to the code that was covered by it. Jordan's suggestion (which you seem to be OK with) under v4 6/6 looks fine to me as well. Thank you, Laszlo > > +The majority of the content in the EDK II open source project uses a > +[BSD 2-Clause License](License.txt). The EDK II open source project contains > +the following components that are covered by additional licenses: > +* [AppPkg/Applications/Python/Python-2.7.2/Tools/pybench](AppPkg/Applications/Python/Python-2.7.2/Tools/pybench/LICENSE) > +* [AppPkg/Applications/Python/Python-2.7.2](AppPkg/Applications/Python/Python-2.7.2/LICENSE) > +* [AppPkg/Applications/Python/Python-2.7.10](AppPkg/Applications/Python/Python-2.7.10/LICENSE) > +* [BaseTools/Source/C/BrotliCompress](BaseTools/Source/C/BrotliCompress/LICENSE) > +* [MdeModulePkg/Library/BrotliCustomDecompressLib](MdeModulePkg/Library/BrotliCustomDecompressLib/LICENSE) > +* [OvmfPkg/Include/IndustryStandard/Xen](OvmfPkg/License.txt) > +* [OvmfPkg/XenBusDxe](OvmfPkg/License.txt) > +* [OvmfPkg/XenPvBlkDxe](OvmfPkg/License.txt) > +* [CryptoPkg/Library/OpensslLib/openssl](CryptoPkg/Library/OpensslLib/openssl/LICENSE) > > The placement of the license files is not consistent at this > point and I would prefer to make them consistent. My earlier > proposal to change OvmfPkg was my first attempt to make everything > consistent and with the addition of Readme.md, easily discoverable. > > I also found the following statement in the TianoCore Contribution > Agreement on this topic: > > "Certain other content may be made available under other licenses as > indicated in or with such Content (for example, in a License.txt file)." > > Thanks, > > Mike > >> -----Original Message----- >> From: Laszlo Ersek [mailto:lersek@redhat.com] >> Sent: Tuesday, July 25, 2017 6:08 AM >> To: Kinney, Michael D ; edk2- >> devel@lists.01.org >> Cc: Leif Lindholm ; Andrew Fish >> ; Justen, Jordan L >> Subject: Re: [Patch V4 0/6] Update to Tiano Contribution >> Agreement 1.1 >> >> On 07/25/17 01:45, Michael D Kinney wrote: >>> https://bugzilla.tianocore.org/show_bug.cgi?id=628 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=629 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=642 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=643 >>> >>> New in V4 >> >>> * Revert change to remove commit message details from >>> Contributions.txt. Instead, this section has been updated to >> support >>> both code and documentation patches. >> >>> This new agreement does not have any changes for code >> contributions. >>> It adds content to cover open source documentation >> contributions. >> >> I was a bit confused why updating the source tree to 1.1 was then >> justified, but "Patch v4 3/6" explains it well in the commit >> message. >> >> I have one suggestion for patch 3: it says that CodeModule should >> be >> omitted from docs patches. However, I suggest that we keep the >> same >> format for docs patches as well; "CodeModule" (or rather >> "DocModule" >> could refer to the chapter or section of the gitbook that is >> being >> modified (chapters and appendices are kept in separate files -- >> sometimes even in multiple files in separate directories -- in >> the >> docbook source trees anyway, and I think "DocModule" could be a >> logical >> match). >> >> Just my opinion of course. >> >> Regarding patch 5, and the special handling of the OvmfPkg >> license file >> -- today I commented on that in >> > July/012547.html>: >> >>> perhaps one root license file with a default license, and >> pathname >>> patterns that cumulatively cover all of the exceptions. Or one >> license >>> file per package, with a default license for the package, plus >>> pathname patterns, where the patterns cumulatively cover all of >> the >>> exceptions within the package. >> >> IIUC, patch #5 would leave two license files in the tree, the >> tree-wide >> default, and OVMF's with some exceptions (identified by >> pathnames). I >> feel that representing exceptions with two methods ((a) separate >> license >> files that override each other, and (b) pathnames in said license >> files) >> is a bit confusing. >> >> So I think we should *either* (1) have one core license file that >> spells >> out all of the exceptions in the tree (by pathname), *or* (2) >> have >> package-level, independent license files that spell out >> exceptions in >> their own respective, containing packages. Currently patch 5 >> seems to be >> a mix of the two. >> >> (Note: I use *bold* above in an attempt to make myself clear; it >> certainly doesn't mean that I "insist" on this. I don't feel very >> strongly about this, so if you or Jordan disagree with my point, >> I'm >> fine. In particular I seem to recall that Jordan disagrees with >> option >> (1), and you likely disagree with option (2), because that's what >> we >> have right now.) >> >> Thanks >> Laszlo