May an app embedding Microsoft.PowerShell.SDK redistribute Microsoft.Management.Infrastructure.Runtime.Win 3.0.0, whose licence forbids distribution while its project and siblings are MIT?

Question

We build a commercial Windows application that hosts PowerShell in-process via Microsoft.PowerShell.SDK (7.5.4, MIT). Publishing self-contained brings Microsoft.Management.Infrastructure.Runtime.Win (3.0.0) into the output, so four of its DLLs end up in our installer and therefore on customer machines:

• Microsoft.Management.Infrastructure.CimCmdlets.dll
• microsoft.management.infrastructure.dll
• microsoft.management.infrastructure.native.dll
• microsoft.management.infrastructure.native.unmanaged.dll

That package declares license file=LICENSE.txt, and the file is MICROSOFT SOFTWARE LICENSE TERMS rather than an open-source licence. Two clauses, quoted from the file in the NuGet cache:

• 1(a): "You may install and use any number of copies of the software solely for use with Microsoft PowerShell."
• 3(e): "you will not (and have no right to): ... share, publish, distribute, or lend the software, provide the software as a stand-alone hosted solution for others to use, or transfer the software or this agreement to any third party."

There is no Distributable Code grant anywhere in the file.

What makes this look like a metadata problem rather than an intended restriction. Three sibling packages, same project, same version, same owners (Microsoft and PowerShellTeam), declare different licences:

Package (3.0.0)	projectUrl	licence declaration
Microsoft.Management.Infrastructure	github.com/PowerShell/MMI	expression = MIT
Microsoft.Management.Infrastructure.Runtime.Unix	github.com/PowerShell/MMI	MIT
Microsoft.Management.Infrastructure.Runtime.Win	github.com/PowerShell/MMI	file = LICENSE.txt (Microsoft Software License Terms)

All three point at the same project, and that project's LICENSE is the standard MIT grant including the right to "distribute, sublicense, and/or sell copies".

Timing, which may matter: Runtime.Win 3.0.0 was published 2023-11-03, and github.com/PowerShell/MMI was archived read-only on 2024-06-14 - so the repository was live and was the package's declared project when that version shipped. It is nonetheless still a live transitive dependency of Microsoft.PowerShell.SDK 7.5.4.

Questions

1. Is the Microsoft Software License Terms file in Runtime.Win correct, or is it a packaging artefact where the MIT expression its project and Unix counterpart carry was intended?
2. If it is correct, may an application embedding Microsoft.PowerShell.SDK redistribute those files to end customers, and under which grant? Read literally, 3(e) would mean no self-contained application using the SDK may ship an installer at all.
3. If it may not, what is the supported path for a self-contained .NET application that hosts PowerShell and needs CIM/WMI access - for example, requiring a separate PowerShell 7 installation on the target machine? Note that mi.dll and miutils.dll are present in System32, but the two native shim DLLs are not, so omitting them and relying on the OS does not work.
4. Does the MIT licence at github.com/PowerShell/MMI extend to the 3.0.0 native binaries in Runtime.Win?

We would rather resolve this before shipping than rely on our own reading of the terms.

Also filed on the PowerShell repository as https://github.com/PowerShell/PowerShell/issues/28027 and cross-referenced so the two do not diverge. Raised here as well because the MMI repository is archived and read-only, so its own issue tracker is unavailable.

Answer 1

Welcome to Microsoft Q&A!

Thank you for providing such a detailed description of the issue, along with the investigation and testing you have already completed. The additional context, particularly your runtime dependency testing, is very helpful and highlights an important practical consideration for anyone hosting PowerShell in-process.

Based on the information currently available in public documentation and community discussions, there is still no published Microsoft clarification that definitively resolves the licensing discrepancy surrounding Microsoft.Management.Infrastructure.Runtime.Win 3.0.0.

A few points can be verified:

• Microsoft.Management.Infrastructure (3.0.0) and Microsoft.Management.Infrastructure.Runtime.Unix (3.0.0) are associated with the PowerShell/MMI project, whose repository contains an MIT license. However, Microsoft.Management.Infrastructure.Runtime.Win (3.0.0) ships with a separate LICENSE.txt containing Microsoft Software License Terms rather than an MIT license declaration.
• This licensing discrepancy was previously raised in GitHub issue #20798 ("Confusing licensing in Microsoft.Management.Infrastructure 3.0.0 nugets"), which remains open and, at the time of writing, does not contain an official maintainer response clarifying whether the Windows runtime package was intentionally licensed differently or whether the package metadata is incorrect.
• A related community discussion regarding the status and intended usage of MMI also references the unusual licensing of the Windows runtime package. To date, there has not been an official response explaining the redistribution rights for the native Windows binaries.
• Your testing aligns with reports from other users that System.Management.Automation has a runtime dependency on MMI components. As your results demonstrate, removing the MMI assemblies can prevent PowerShell hosting from initializing successfully. In practice, this means that a self-contained application embedding Microsoft.PowerShell.SDK cannot simply exclude these runtime files and continue to function as intended.

Because Microsoft has not published an authoritative clarification, neither Microsoft Q&A contributors nor the broader community can conclusively determine:

1. Whether the Runtime.Win LICENSE.txt was intentionally packaged as-is.
2. Whether the MIT license in the archived MMI repository extends to the Windows runtime binaries included in the NuGet package.
3. Whether a separate redistribution grant exists for those specific DLLs.

For that reason, any statement that redistribution is definitively permitted or definitively prohibited would be speculative.

At this time, the most supportable conclusion is that the licensing question remains publicly unresolved. Given the lack of an official statement, the safest approach is to continue pursuing clarification through the PowerShell GitHub issue, the NuGet package owners, or Microsoft's licensing channels before making a commercial redistribution decision.

I understand that this may not provide the certainty needed for a shipping decision, especially since the dependency appears to be required for PowerShell hosting scenarios. However, based on the public information currently available, there does not appear to be a Microsoft document that explicitly clarifies redistribution rights for Microsoft.Management.Infrastructure.Runtime.Win 3.0.0.

I appreciate the additional testing details you've shared, as they help clarify that simply excluding the runtime package is not a viable workaround for embedded PowerShell scenarios.

If you find this information helpful, please click Accept Answer. 

Thank you for using Microsoft Q&A.

Answer 2

Thank you Harry - and to be fair to your answer, the post above did not carry the measurement that makes one of its recommendations unavailable. Adding it here so the thread is not misleading to the next person.

Excluding Runtime.Win from the installer is not an option, and this was measured rather than reasoned.

I built a minimal console app referencing Microsoft.PowerShell.SDK 7.5.4, published it self-contained (which reproduces the same four files), ran it as a control, then deleted the four files and ran it again. With them removed the very first probe fails - not a CIM cmdlet, a bare runspace:

runspace + Get-Date  :  FAIL
FileNotFoundException: Could not load file or assembly
'Microsoft.Management.Infrastructure, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.

System.Management.Automation has a load-time dependency on MMI, so PowerShell hosting does not start at all without it. There is no configuration in which an app embeds the SDK and omits these files: it is ship them, or do not embed the SDK.

A second data point, from the same dependency graph. runtime.win-x64.runtime.native.System.Data.SqlClient.sni 4.4.0 is also a Microsoft NuGet package shipping a native Windows binary under a licence file rather than an SPDX expression, and its file carries the identical "MICROSOFT SOFTWARE LICENSE TERMS / MICROSOFT .NET LIBRARY" header. Unlike the MMI file it contains a Distributable Code grant: "You may copy and distribute the object code form of the software", plus Third Party Distribution rights. Across the 211 components in our .NET graph, Microsoft.Management.Infrastructure.Runtime.Win is the only one with no distribution grant of any kind.

On asking Microsoft. We have, by three routes - PowerShell/PowerShell#28027, this question, and NuGet "Contact owners" to Microsoft and PowerShellTeam. Worth noting for anyone arriving here later: PowerShell/PowerShell#20798 raised this same discrepancy on 28 November 2023 and is still open with no maintainer response, and PowerShell/PowerShell discussions#24794 asked about MMI's status in January 2025 with no official reply either. So this is a question that has been asked publicly for over two years without an answer, which is itself useful to know when planning around it.

The out-of-process suggestion is the one genuinely different architecture on the table - invoking pwsh rather than embedding the SDK - and we are costing it. It carries a PowerShell 7 prerequisite and a process boundary, but it does sidestep the question entirely.

Answer 3

Hello Victor,

The MIT license of Microsoft.PowerShell.SDK does not automatically grant redistribution rights for its transitive dependencies. Since Microsoft.Management.Infrastructure.Runtime.Win 3.0.0 contains a Microsoft Software License Terms file restricting distribution, you should not ship its four DLLs commercially without explicit confirmation. The MIT license in the MMI GitHub repository and sibling packages does not automatically override the license packaged with the Windows runtime. The related PowerShell issue #20798 documents the licensing discrepancy, but does not establish Microsoft's final legal interpretation. Please request written clarification from the PowerShell maintainers or Microsoft licensing team confirming whether the MIT license covers the native Windows binaries and permits redistribution. If redistribution is not permitted, the supported alternative is to install PowerShell 7 separately and invoke it out-of-process for CIM/WMI operations. However, this requires validating PowerShell installation, version compatibility, and deployment requirements. Until clarification is obtained, I recommend excluding Runtime.Win 3.0.0 from your commercial installer rather than relying on an assumed MIT grant.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

HP.