Thanks for the suggestion! However, I think the semantics are a little bit different, XXX in your example would be the actual license text, so "Apache-2.0 OR MIT" wouldn't be the correct value. There's no way to specify that currently, but hopefully there will be with PEP 639, which adds a License-Expression core metadata field and assigns the value of project.license in pyproject.toml to the expression. So, this is another issue where we are blocked until that PEP, or an alternative, lands.

It's unfortunate this wasn't thought of earlier when the pyproject.toml was designed. Seems so fundamental, but hopefully the PEP is accepted.

For now, I'll just leave it as is since I see no better way to express dual licensed software.

My recommendation for that case would be to have a single license file with both licenses, and specifying it in pyproject.tml. But I agree, it's unfortunate, hopefully the PEP will land though and fix this.

Unfortunately that wouldn't be REUSE compliant from what I understand.

https://reuse.software/

I didn't know about REUSE, thank you for pointing it out. I've only skimmed it a bit, but I can't tell how it wouldn't be compliant? You can still have the SPDX headers, you'd just have an extra license file for the Python tooling to read. In fact, using the REUSE spec you should even be able to automatically generate this file! Am I missing something here? 🤣

Hmm touch LICENSE in the root doesn't seem to cause the tool to fail. Oh well. Just throw REUSE on the pile of reasons that PEP should be advanced.

Agreed. I have pinged the discourse thread. Let's see if we can get it to move forward.

(cc @CAM-Gerlach)

Thanks for your efforts.

Sorry, finishing what is hopefully the last major update got stuck beyond a pile of other things that came up over the past few months, but I've now got most of the next rewrite complete and it's near the top of my priority list to finish, hopefully in the next few days 🤞 I can also mention REUSE compliance and this issue in the rationale and on the thread.

@CAM-Gerlach no problem whatsoever. At least someone thought about it in the first place!

Thanks, but to be fair that person with the original idea wasn't me—credit for that is due to @pombredanne

Could one of y'all link to the discourse thread where I presume discussion of the referenced PEP is? I am not familiar with the Python PEP process.

It's here 😊

https://discuss.python.org/t/pep-639-round-2-improving-license-clarity-with-better-package-metadata

Meson 1.1 now has license_files, which it would be nice to automatically distribute as a set of license files (especially if you have a dependency subproject that may be bundled in a wheel, but not if built in, e.g., a Linux distro).

Thanks @QuLogic. That does look potentially useful, especially for the subproject case you mention, since that cannot be done from pyproject.toml. I think we're still waiting for PEP 639 to land first though? Not sure what we'd do with license_files right now.

You can install them to *.dist-info/licenses, regardless of the availability/usefulness for Metadata-Version: 2.1

PEP639 is now provisional, i.e., waiting for two build backends to implement it. meson-python could be one of those two.