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 <michael.d.kinney@intel.com>; edk2-
>> devel@lists.01.org
>> Cc: Leif Lindholm <leif.lindholm@linaro.org>; Andrew Fish
>> <afish@apple.com>; Justen, Jordan L <jordan.l.justen@intel.com>
>> 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
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel