Missing license file in `pymsalruntime` wheel

[janjagusch]

I'm opening this issue here as, to the best of my knowledge, there is no public repository for pymsalruntime. If there is a better place to raise this issue, please let me and and I'll happily move it.

There is no separate license file in the pymsalruntime wheel files, only a license classifier.

Here an example for the v0.18.1 Python 3.13 manylinux wheel:

$ curl -o pymsalruntime.whl https://files.pythonhosted.org/packages/82/48/7ce57351f7267b42d59e928a2656138c27c73dd27c869b5b8df7660deeda/pymsalruntime-0.18.1-cp313-cp313-manylinux_2_35_x86_64.whl
$ unzip pymsalruntime.whl -d pymsalruntime
$ cd pymsalruntime
# License defined as MIT.
$ grep -i '^license\|^classifier: license' pymsalruntime-0.18.1.dist-info/METADATA
License: MIT
Classifier: License :: OSI Approved :: MIT License
# But no license file included.
$ ls -lha pymsalruntime-0.18.1.dist-info/
total 28K
drwxr-xr-x 1 root root  64 Mar 13 09:20 .
drwxr-xr-x 1 root root 122 Jun  9 07:15 ..
-rw-r--r-- 1 root root 380 Mar 13 09:20 METADATA
-rw-rw-r-- 1 root root 15K Mar 13 09:20 RECORD
-rw-r--r-- 1 root root 113 Mar 13 09:20 WHEEL
-rw-r--r-- 1 root root  14 Mar 13 09:20 top_level.txt

Please add a license file to the wheel file.

Ref.: conda-forge/staged-recipes#30279
Ref.: #811

[rayluo]

to the best of my knowledge, there is no public repository for pymsalruntime.

Indeed. PyMsalRuntime repo is not open source. Not sure whether it still makes sense to use MIT license for PyMsalRuntime. I will defer to my teammate Iulian C. (@iulico-1) .

[janjagusch]

Thanks for your response, Ray Luo (@rayluo). Iulian C. (@iulico-1), what's your take on this?

[janjagusch]

Friendly ping, Ray Luo (@rayluo), Iulian C. (@iulico-1). Regardless of they license you want to distribute this package under, it feels necessary to ship a license file in the wheel.

[janjagusch]

Hi Ray Luo (@rayluo), Iulian C. (@iulico-1) — following up on this again.

Beyond the conda-forge packaging issue I originally raised, I want to highlight that this also affects Microsoft's own Azure CLI. The dependency chain is:

azure-cli
  → azure-cli-core
    → msal[broker] (on Windows)
      → pymsalruntime

On Windows, pymsalruntime is a transitive dependency of azure-cli. Since pymsalruntime declares MIT in its metadata but ships no actual license file, the license chain for Azure CLI has a gap — the full MIT license text (with copyright holder, permission grant, and warranty disclaimer) is missing from this dependency.

This means enterprise users running license compliance scans on their Azure CLI installations will flag pymsalruntime as a package with an unsubstantiated license. It also means Microsoft isn't technically meeting the MIT license's own requirement that the permission notice be included in all copies of the software.

Given that both azure-cli and pymsalruntime are published by Microsoft, this seems like something that should be straightforward to resolve. Adding a LICENSE file to the wheel build would fix it for everyone downstream.