Thanks to visit codestin.com
Credit goes to GitHub.com

Skip to content

Comments

fixup licensing#10352

Open
esc wants to merge 5 commits intonumba:mainfrom
esc:fix/license-metadata
Open

fixup licensing#10352
esc wants to merge 5 commits intonumba:mainfrom
esc:fix/license-metadata

Conversation

@esc
Copy link
Member

@esc esc commented Nov 26, 2025

Adding LICENSE and LICENSES.third-party files to package via license_files and add LICENSES.third-party to the MANIFEST.in. Also remove the trove classfier as this is deprecated and correct copyright date in the documentation.

Finally list all licenses (includeing third-party ones) as a conjunction of SPDX classfiers.

Adding `LICENSE` and `LICENSES.third-party` files to package via
`license_files` and add `LICENSES.third-party` to the `MANIFEST.in`.
Also remove the trove classfier as this is deprecated and correct
copyright date in the documentation.

Finally list all licenses (includeing third-party ones) as a conjunction
of SPDX classfiers.
As title
setup.py Outdated
install_requires=install_requires,
python_requires=">={}".format(min_python_version),
license="BSD",
license="MIT AND 0BSD AND BSD-2-Clause AND BSD-3-Clause AND Python-2.0",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will it help to keep a comment here to indicate which license is coming from which part?

Or maybe even as:

appdir_license = "MIT"
networkx_license = "MIT
cpython_license = "Python 2.0"
license_set = {appdir_license, networkx_license, cpython_license}
license = ' AND '.join(license_set)

Copy link
Member Author

@esc esc Jan 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I chose a slightly different but similar path in 4aa06b8

In [1]: # License handling
   ...:
   ...: # appdirs jquery.graphviz.svg
   ...: LICENSE_TYPE_MIT = "MIT"
   ...: # pythoncapi_compat
   ...: LICENSE_TYPE_ZERO_BSD = "0BSD"
   ...: # Numba itself
   ...: LICENSE_TYPE_BSD_2_CLAUSE = "BSD-2-Clause"
   ...: # NetworkX cloudpickle NumPy numba-cuda
   ...: LICENSE_TYPE_BSD_3_CLAUSE = "BSD-3-Clause"
   ...: # CPython CPython-unicode
   ...: LICENSE_TYPE_PYTHON_20 = "Python-2.0"
   ...:
   ...: LICENSE_data = " AND ".join((LICENSE_TYPE_MIT,
   ...:                              LICENSE_TYPE_ZERO_BSD,
   ...:                              LICENSE_TYPE_BSD_2_CLAUSE,
   ...:                              LICENSE_TYPE_BSD_3_CLAUSE,
   ...:                              LICENSE_TYPE_PYTHON_20,
   ...:                              ))
   ...:

In [2]: LICENSE_data
Out[2]: 'MIT AND 0BSD AND BSD-2-Clause AND BSD-3-Clause AND Python-2.0'

@gmarkall
Copy link
Member

gmarkall commented Dec 2, 2025

@esc esc force-pushed the fix/license-metadata branch from d93f19b to 4aa06b8 Compare January 9, 2026 11:09
@esc esc added 4 - Waiting on reviewer Waiting for reviewer to respond to author and removed 2 - In Progress labels Jan 9, 2026
@esc
Copy link
Member Author

esc commented Jan 9, 2026

Commit adding the CUDA headers referring to Attachment A of the CUDA EULA: ad931f8#diff-c89f9576dacbf6b7fa07d07780942d62a78b9f09357b499154f9886237656c3f

https://docs.nvidia.com/cuda/archive/11.2.2/eula/index.html#attachment-a

To add some more context here. The CUDA Half precision headers listed here:

https://github.com/numba/numba/blob/main/LICENSES.third-party#L496

appear to be under a proprietary NVIDIA license that has not been SPDX approved. However the license does explicitly permit re-distribution. It is not clear how to declare this inclusion in a https://peps.python.org/pep-0639/ compliant fashion.

@esc esc added the needs triage/maintainer discussion For an issue/PR that needs discussion at a triage/maintainer meeting label Jan 9, 2026
@esc
Copy link
Member Author

esc commented Jan 9, 2026

I received the following suggestions out of band:

CUDA is depreacted in favour of https://github.com/NVIDIA/numba-cuda -- can we just remove headers and their license and send people to the new numba-cuda instead?

@JArndt-WI
Copy link

JArndt-WI commented Jan 12, 2026

...

To add some more context here. The CUDA Half precision headers listed here:

https://github.com/numba/numba/blob/main/LICENSES.third-party#L496

appear to be under a proprietary NVIDIA license that has not been SPDX approved. However the license does explicitly permit re-distribution. It is not clear how to declare this inclusion in a https://peps.python.org/pep-0639/ compliant fashion.

The ScanCode license DB is an important reference for license identification https://github.com/aboutcode-org/scancode-licensedb. It is e.g. explicitely demanded by the German BSI (Federal Office for Information Security) TR-03183-2.

The CUDA stuff has an entry there: LicenseRef-scancode-nvidia-cuda-supplement-2020 (see nvidia-cuda-supplement-2020.*)

@esc
Copy link
Member Author

esc commented Jan 12, 2026

...

To add some more context here. The CUDA Half precision headers listed here:
https://github.com/numba/numba/blob/main/LICENSES.third-party#L496
appear to be under a proprietary NVIDIA license that has not been SPDX approved. However the license does explicitly permit re-distribution. It is not clear how to declare this inclusion in a https://peps.python.org/pep-0639/ compliant fashion.

The ScanCode license DB is an important reference for license identification https://github.com/aboutcode-org/scancode-licensedb. It is e.g. explicitely demanded by the German BSI (Federal Office for Information Security) TR-03183-2.

The CUDA stuff has an entry there: LicenseRef-scancode-nvidia-cuda-supplement-2020 (see nvidia-cuda-supplement-2020.*)

@JArndt-WI thank you for following up on this! Would that be an appropriate string to add to the license metadata field in a setup.py?

@JArndt-WI
Copy link

JArndt-WI commented Jan 12, 2026

...

To add some more context here. The CUDA Half precision headers listed here:
https://github.com/numba/numba/blob/main/LICENSES.third-party#L496
appear to be under a proprietary NVIDIA license that has not been SPDX approved. However the license does explicitly permit re-distribution. It is not clear how to declare this inclusion in a https://peps.python.org/pep-0639/ compliant fashion.

The ScanCode license DB is an important reference for license identification https://github.com/aboutcode-org/scancode-licensedb. It is e.g. explicitely demanded by the German BSI (Federal Office for Information Security) TR-03183-2.
The CUDA stuff has an entry there: LicenseRef-scancode-nvidia-cuda-supplement-2020 (see nvidia-cuda-supplement-2020.*)

@JArndt-WI thank you for following up on this! Would that be an appropriate string to add to the license metadata field in a setup.py?

From now on projects should follow the current specification:

https://packaging.python.org/en/latest/specifications/core-metadata/#license-expression
https://packaging.python.org/en/latest/specifications/license-expression/#license-expression

According to the specs yes, (if that compiled code is part of the distribution).

Does the created METADATA file in an installed package contain the entry "License-Expression"?

When I inspect metadata with Python's distributions/Distribution function/class from importlib.metadata, the entry should appear as "license_expression" in the dict. That is what I see when inspecting packages like urllib3 which bases on pyproject.toml that includes a "license" setting. So it seems that the License-Expression entry is automatically generated at build time. I don't know how setup.py's settings are treated with current tooling.

@esc
Copy link
Member Author

esc commented Jan 14, 2026

...

To add some more context here. The CUDA Half precision headers listed here:
https://github.com/numba/numba/blob/main/LICENSES.third-party#L496
appear to be under a proprietary NVIDIA license that has not been SPDX approved. However the license does explicitly permit re-distribution. It is not clear how to declare this inclusion in a https://peps.python.org/pep-0639/ compliant fashion.

The ScanCode license DB is an important reference for license identification https://github.com/aboutcode-org/scancode-licensedb. It is e.g. explicitely demanded by the German BSI (Federal Office for Information Security) TR-03183-2.
The CUDA stuff has an entry there: LicenseRef-scancode-nvidia-cuda-supplement-2020 (see nvidia-cuda-supplement-2020.*)

@JArndt-WI thank you for following up on this! Would that be an appropriate string to add to the license metadata field in a setup.py?

From now on projects should follow the current specification:

https://packaging.python.org/en/latest/specifications/core-metadata/#license-expression https://packaging.python.org/en/latest/specifications/license-expression/#license-expression

According to the specs yes, (if that compiled code is part of the distribution).

Does the created METADATA file in an installed package contain the entry "License-Expression"?

When I inspect metadata with Python's distributions/Distribution function/class from importlib.metadata, the entry should appear as "license_expression" in the dict. That is what I see when inspecting packages like urllib3 which bases on pyproject.toml that includes a "license" setting. So it seems that the License-Expression entry is automatically generated at build time. I don't know how setup.py's settings are treated with current tooling.

I tried to build Numba but I can't find

...

To add some more context here. The CUDA Half precision headers listed here:
https://github.com/numba/numba/blob/main/LICENSES.third-party#L496
appear to be under a proprietary NVIDIA license that has not been SPDX approved. However the license does explicitly permit re-distribution. It is not clear how to declare this inclusion in a https://peps.python.org/pep-0639/ compliant fashion.

The ScanCode license DB is an important reference for license identification https://github.com/aboutcode-org/scancode-licensedb. It is e.g. explicitely demanded by the German BSI (Federal Office for Information Security) TR-03183-2.
The CUDA stuff has an entry there: LicenseRef-scancode-nvidia-cuda-supplement-2020 (see nvidia-cuda-supplement-2020.*)

@JArndt-WI thank you for following up on this! Would that be an appropriate string to add to the license metadata field in a setup.py?

From now on projects should follow the current specification:

https://packaging.python.org/en/latest/specifications/core-metadata/#license-expression https://packaging.python.org/en/latest/specifications/license-expression/#license-expression

According to the specs yes, (if that compiled code is part of the distribution).

Does the created METADATA file in an installed package contain the entry "License-Expression"?

When I inspect metadata with Python's distributions/Distribution function/class from importlib.metadata, the entry should appear as "license_expression" in the dict. That is what I see when inspecting packages like urllib3 which bases on pyproject.toml that includes a "license" setting. So it seems that the License-Expression entry is automatically generated at build time. I don't know how setup.py's settings are treated with current tooling.

Do mean, like this?

esc@artemis [base] [numba:fix/license-metadata:★★₃:»] ~/git/numba/dist cat numba-0.64.0.dev0+6.g2e306d08e3.dist-info/METADATA | grep License-Expression
License-Expression: MIT AND 0BSD AND BSD-2-Clause AND BSD-3-Clause AND Python-2.0

I modified the setup.py in 2e306d0 -- to suit.

@esc
Copy link
Member Author

esc commented Jan 14, 2026

Using the string LicenseRef-scancode-nvidia-cuda-supplement-2020 the METADATA file would look like:

esc@artemis [numba_3.14] [numba:fix/license-metadata:★★₃] ~/git/numba/dist cat numba-0.64.0.dev0+7.g3e3cf0482a.dist-info/METADATA| grep License-Expression
License-Expression: MIT AND 0BSD AND BSD-2-Clause AND BSD-3-Clause AND Python-2.0 AND LicenseRef-scancode-nvidia-cuda-supplement-2020

@esc esc added 3 - Ready for Review and removed 4 - Waiting on reviewer Waiting for reviewer to respond to author labels Jan 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3 - Ready for Review needs triage/maintainer discussion For an issue/PR that needs discussion at a triage/maintainer meeting skip_release_notes Skip towncrier requirement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants