Redistribution of renamed MSVC runtime DLLs in commercial Python applications

Hi walker aruyo, :)

This comes up a lot with Python wheels on Windows. I'm not from Microsoft licensing and this isn't legal advice, but here is what the published terms say and how I would approach it.

Where the hash suffix comes from

NumPy and Shapely build their Windows wheels with delvewheel. It copies the DLLs a package depends on into the wheel and renames them with a content hash. Without that, two packages shipping different copies of the same DLL could collide in one Python process. It then rewrites the import table of the package's own .pyd/.dll files to point at the new name. The Microsoft DLL itself is not edited.

You can check this yourself. An Authenticode signature covers the file contents, not the file name, so a valid Microsoft signature means the bytes are what Microsoft shipped. To compare against your own install:

$dll = ".\msvcp140-a4c2229bdc2a2a630acdc095b4d86008.dll"

$sig = Get-AuthenticodeSignature $dll

$sig.Status; $sig.SignerCertificate.Subject

(Get-Item $dll).VersionInfo.FileVersion

(Get-FileHash $dll).Hash

# From a Developer PowerShell for VS 2022:

$ref = "$($env:VCToolsRedistDir)x64\Microsoft.VC143.CRT\msvcp140.dll"

(Get-Item $ref).VersionInfo.FileVersion

(Get-FileHash $ref).Hash

If both files have the same version, the hashes should match.

1. Redistributing under a hash-suffixed name

The Visual Studio 2022 Distributable Code list lets you distribute the files under VC\redist with your program, and states "You may not modify these files." It says nothing about the file name. Renaming does not change the binary and the signature stays valid, so my reading is that this is not a modification of the Distributable Code. The terms don't address renaming explicitly, though, so this is an interpretation and not a statement from Microsoft.

2. Files that came from a third-party wheel

Your right to redistribute comes from your own Visual Studio 2022 license, not from NumPy or Shapely. The same page ties that right to having a valid Visual Studio license and to distributing the listed files unmodified. It also says that runtime binaries downloaded from Microsoft's VC++ Redistributable pages fall under the same Visual Studio terms, so the right is not limited to copies taken from your own VC\Redist folder. What matters is that the file is identical to the listed one, which is what the check above confirms. The general conditions in the Distributable Code section of the VS 2022 license terms (Help > About Microsoft Visual Studio > License Terms) still apply. Those include shipping it as part of an application that adds significant functionality, and having your end-user terms protect it at least as much as the VS license does.

3. If you want to avoid the question entirely

• Keep the wheels as they are. This is the least effort and works today, but it relies on the interpretation in point 1.
• Central deployment (Microsoft's recommended approach). Run vc_redist.x64.exe /install /quiet /norestart from your installer. Then point the packages back to the standard name with delvewheel replace-needed <file> -change msvcp140-<hash>.dll msvcp140.dll. Do this for every .pyd/.dll in the package and its .libs folder that imports the hashed name (delvewheel needed <file> lists a binary's imports). After that, delete the hashed copies.
  • Benefit: Windows Update services the runtime.
  • Trade-offs: you are patching third-party binaries, you have to repeat it on every upgrade, and you lose the isolation delvewheel added. Test carefully, and make sure the runtime the process loads is at least as new as the one the wheels were built against.
• Rebuild the wheels yourself with delvewheel repair --exclude msvcp140.dll, and deploy the runtime through vc_redist. This gives you the most control but takes the most effort.

The same reasoning applies to vcruntime140.dll and vcruntime140_1.dll, which the python.org runtime and freezers like PyInstaller place next to python.exe.

For a definitive answer before a commercial release, confirm with Microsoft licensing or your own legal counsel.

If this helped, please consider accepting the answer so others can find it.