On Sun, 23 Feb 2020 at 08:40, Ian Stapleton Cordasco graffatcolmingov@gmail.com wrote:
Forgive me if I'm missing something but doesn't license-file provides this functionality (see https://stackoverflow.com/a/48691876) for an example.
I surmise not enough people use it although it's readily available?
This is likely to be the case, as license-file[s] is a setuptools feature aimed at ensuring the license file ends up in the sdist/wheel archive, rather than a published metadata field aimed at allowing other tools to *find* that license file within the sdist/wheel archive.
There's a pre-draft PEP in discussion at https://github.com/pombredanne/spdx-pypi-pep/pull/2 and https://discuss.python.org/t/improving-license-clarity-with-better-package-m... that looks at clarifying licensing metadata through the use of SPDX classifiers. That draft PEP also formalises the "License-File" field.
The approach I'm currently taking to this problem is to combine https://github.com/nexB/scancode-toolkit/blob/develop/README.rst for finding component licenses with https://github.com/nexB/aboutcode-toolkit to generate an open source attribution bundle for those components. The one key caveat on that approach is that the initial scancode output requires some non-trivial cleanup before you can feed it into the aboutcode ABOUT file generator when first applying it to a project: https://github.com/nexB/aboutcode-toolkit/issues/416
Cheers, Nick.
P.S. As with a lot of distribution related issues, the key challenge with making improvements in this space is that developers really need tools that work *today* to meet their open source attribution obligations (such as nexB's scancode & aboutcode toolkits), while metadata level improvements (like Philippe's draft PEP) will take years to cover a significant proportion of published packages (and there's a long tail of rarely updated projects that may never catch up).