As a developer working extensively on license_scanner, I’ve encountered numerous Python packages with outdated license metadata. Understanding PEP 639 is crucial, as it introduces significant changes to how licenses are managed in Python packages.

Key Changes in PEP 639

Python now adheres to the SPDX (Software Package Data Exchange) standard, moving away from using classifiers. The recommended approach is to use only two fields in your pyproject.toml file: license and license_files.

• license: This field should be a string.
• license_files: This field can be a string or a list of strings.

Choosing the Right License

There are numerous licenses available, many with similar names. For example, if a package is published under the “BSD License,” it could refer to any of over 30 different BSD licenses, each with varying requirements. To avoid confusion, use a license name from the SPDX list, which you can find here: SPDX Licenses.

Here is an example of how the black package (version 25.9.0) uses this new standard: black’s pyproject.toml.

Including License Files

Including the full text of the license in your package can be beneficial. You can do this by adding the paths to the licenses in the license_files field. Multiple files can be included if necessary. For example, see how numpy handles this: numpy’s pyproject.toml.

Using Multiple Licenses

If you need to use multiple licenses for your package, use SPDX names along with brackets, the OR operator, and the AND operator. The order of operations for SPDX is: brackets first, then the AND operator, and finally the OR operator.

For instance, if you have (Apache-2.0 OR BSD-3-Clause) AND PSF-2.0, it means you must always accept PSF-2.0, but you can combine it with either Apache-2.0 or BSD-3-Clause. Here is an example from the cryptography package (version 40.0): cryptography’s setup.cfg.

Handling Exceptions

The WITH operator can be used to add exceptions to a license. For example, PyInstaller version 6.16.0 includes the following: “GPLv2-or-later with a special exception which allows to use PyInstaller to build and distribute non-free programs (including commercial ones)”. This indicates that the GPLv2 does not apply to products made with PyInstaller. This exception is resolved at the highest level in the SPDX operator order. See the example here: PyInstaller’s pyproject.toml.

By following these guidelines, you can ensure that your Python packages have clear and up-to-date license metadata, making it easier for users to understand and comply with your licensing terms.

Conclusion

Adopting modern license metadata practices for Python packages, as outlined in PEP 639 and the SPDX standard, is essential for maintaining clarity and compliance. By using the license and license_files fields in your pyproject.toml file, you can provide precise and understandable licensing information. Choosing the correct license from the SPDX list helps avoid confusion, while including full license texts and handling multiple licenses and exceptions ensures comprehensive coverage. These practices not only streamline the licensing process but also enhance transparency and trust among users and contributors.