Use BSD-2-Clause license identifier

[mschoettle]

BSD is ambiguous. Since the license is BSD 2 Clause, the SPDX identifier for this license can be used here.

[merwok]

The license field is actually free text, there is an ongoing PEP to use SPDX identifiers.
But the current official way to specify license is to use classifiers.

[mschoettle]

True. PEP 639 will improve the current situation. The disadvantage of only classifiers is that in the case of BSD it is ambiguous since it maps to multiple possible licenses.

[j4mie]

Thanks for the PR. Does this actually matter if the full and correct license is in the repo? I'm happy to merge this if it's the right thing to do, but I'm not familiar with the situation regarding PyPI and licenses at all.

[merwok]

It matters in that PyPI artifacts are independent from this github repo!

This doesn’t change anything functionally: when you upload to PyPI, you are granting it a license to distribute your files.

The impact is on people reviewing their dependencies’ metadata, possibly not by manual inspection but using scanning tools, so there is value in having consistent and correct information. These could be individual developers or OS packagers (downstream in Debian, Fedora, Conda, etc).

[mschoettle]

That's basically where this occurred for us. We run dependency scanning in the pipeline (the one from GitLab on GitLab). Besides checking for vulnerable packages/package versions it can also detect the license.

I was told by GitLab's support that they rely on the license field returned by the PyPI API (e.g., https://pypi.org/pypi/django-forms-dynamic/json, and see Django: https://pypi.org/pypi/django/json) although there are still some that show up as unknown on GitLab. The assumption it seems is that it is a valid SPDX identifier.

At the same time, that field gets shown on PyPI on the left-hand side under Meta -> License. I noticed that if it is a valid identifier PyPI shows the name with the identifier in parentheses. (compare Django and django-forms-dynamic).

[mschoettle]

setuptools has support for PEP 639 now (pypa/setuptools#4629). I don't see a pinned setuptools version in this repo so it would use the the latest version the next time it is built. I haven't tested building this with the latest version. But in theory it should be good to merge now (unless there are any other requirements with the new format).

[merwok]

Here is a guide on current best practices: https://hugovk.dev/blog/2025/improving-licence-metadata/

[mschoettle]

Thanks! While it looks right, I don't think it works as is:

$ pip show django-forms-dynamic
Name: django-forms-dynamic
Version: 1.0.1
Summary: Resolve form field arguments dynamically when a form is instantiated, not when it's declared.
Home-page: https://github.com/dabapps/django-forms-dynamic
Author: DabApps
Author-email: [email protected]
License: BSD-2-Clause
Location: /usr/local/python/3.12.1/lib/python3.12/site-packages
Requires: 
Required-by:

Built using setuptools==78.1.0. Based on the shared article it should show License-Expression.

I suspect because the use of setup.py is deprecated.

[merwok]

No, running commands like python setup.py sdist directly is deprecated.

setup.py and setup.cfg are still perfectly usable configuration files for the setuptools build backend.

Do you have pip 25.0 or newer? ref: pypa/pip@41c807c

[merwok]

This is the old free-form license field, not the recent SPDX licence-expression field

[mschoettle]

Ah, right. Good catch! It still passed the license to the license argument in setup. pip show shows License-Expression after changing the argument to license_expression.

[mschoettle]

No, running commands like python setup.py sdist directly is deprecated.

That's what the pypi workflow in this repo uses. Eventually it would be good to convert to pyproject.toml.