# PEP 639, Round 2: Improving license clarity with better package metadata

**URL:** <https://discuss.python.org/t/pep-639-round-2-improving-license-clarity-with-better-package-metadata/12622>\
**Category:** Standards\
**Created:** [December 17, 2021, 10:47pm UTC](https://discuss.python.org/t/pep-639-round-2-improving-license-clarity-with-better-package-metadata/12622 "2021-12-17T22:47:27Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![ofek](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ofek/32/1033_2.png) [@ofek](https://discuss.python.org/u/ofek)\
**Post date:** [December 18, 2021, 9:35pm UTC](https://discuss.python.org/t/pep-639-round-2-improving-license-clarity-with-better-package-metadata/12622/17 "2021-12-18T21:35:15Z")

</div>

> [@CAM-Gerlach](#):
>
> […] new build system which will become the default in PEP 676. This will cut the PEP’s total length by well over half

That sounds very neat!

Did you happen to see my question here? [PEP 639, Round 2: Improving license clarity with better package metadata - #14 by ofek](https://discuss.python.org/t/12622/14)

I really think that’s the only critique being expressed by anyone i.e. that the cost/benefit analysis described in [https://www.python.org/dev/peps/pep-0639/#source-metadata-license-key](https://www.python.org/dev/peps/pep-0639/#source-metadata-license-key) does not justify the rejection of the idea.

---

_[View the full topic](https://discuss.python.org/t/pep-639-round-2-improving-license-clarity-with-better-package-metadata/12622)._