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:[email protected]] >> Sent: Tuesday, July 25, 2017 6:08 AM >> To: Kinney, Michael D <[email protected]>; edk2- >> [email protected] >> Cc: Leif Lindholm <[email protected]>; Andrew Fish >> <[email protected]>; Justen, Jordan L <[email protected]> >> 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 >> <https://lists.01.org/pipermail/edk2-devel/2017- >> 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
