Aspire was never fully open source. Now it is.

In November 2023, the day after .NET Aspire’s first preview shipped, I opened an issue in the Aspire repository. Not a bug report. A licensing question, because something felt off: the project was marketed as free and open source, MIT license in the repo root, community-driven development in the readme. But the component that actually did the orchestrating, a binary called dcp.exe, was nowhere in that repository. It sat in the .NET SDK’s packs directory, closed-source, governed by its own EULA.

This is the story of that binary, the two years it took to fix, and the happy ending from January 2026. But it’s also a story with a transferable lesson: “open source” is a property of everything that runs, not of the repository you happen to be looking at.

What DCP actually is

When you press F5 on an Aspire AppHost, something has to start your projects, spin up your containers, wire the service discovery, and expose the dashboard’s view of it all. That something is the Developer Control Plane, or DCP. It ships as dcp.exe (written in Go, of all things) inside the SDK workload, and Aspire’s Aspire.Hosting talks to it over an API.

What kind of API? Six days after my issue, Anthony Simmon published a technical deep dive that answered it beautifully: DCP is, in his words, a sort of miniature Kubernetes. It speaks the Kubernetes API protocol. Aspire generates a kubeconfig, and you can point plain kubectl at it:

kubectl api-resources
# Containers, Executables, ExecutableReplicaSets,
# Services, Endpoints, ContainerVolumes

kubectl describe containers cache

Your “simple local dev experience” was a private API server modeling your app as custom Kubernetes resources. Technically delightful. And entirely closed: the source lived in a private repository (microsoft/usvc-apiserver), and the binary came with license terms of its own.

The EULA in the machine

Buried next to the binary was a “Microsoft Developer Control Plane” EULA, and its clauses were what prompted my question. The core grant was narrow:

You may install and use any number of copies of the software to develop and test your applications.

Develop and test. So what about the gray zones where Aspire looked genuinely attractive: on-premise setups, single-node “local cloud” scenarios, places where the line between a test environment and a small production one blurs? That was my literal question in the issue. Other people read further and found sharper edges. The license was explicitly temporary:

These license terms are effective by you using the software and terminates following first availability of a commercial release of the software or upon termination by Microsoft.

A termination clause keyed to a future commercial release reads like a plan, or at least an option Microsoft wanted to keep open. And there was a data collection section stating the software “may collect information about you and your use of the software, and send that to Microsoft”. To be fair on that last point: a Microsoft team member replied in the thread that “DCP does not currently collect any data or telemetry”, and I have no reason to doubt it. But that’s exactly the trouble with EULAs: you don’t get to rely on the current behavior, only on what the text permits.

None of this made Aspire’s team villains. It made Aspire a project whose marketing said “open source” while its most load-bearing runtime component said “proprietary, dev-only, terms may change.” Those two statements can’t both be the whole truth.

Two years of polite pressure

What happened next is unglamorous, which is rather the point. My issue was converted into a discussion in early 2024 and kept collecting comments. Anthony’s analysis circulated. Official DCP documentation eventually appeared as Aspire matured. The question never became a scandal; it just refused to go away, because a paper trail with verbatim EULA quotes is hard to argue with.

Then, in late 2025, the topic caught a second wind. Ed Andersen published a video titled “Is .NET Aspire Actually Open Source? (I don’t think so)”, Reddit picked the thread up, and the two-year-old question was suddenly current again, at exactly the moment Aspire was repositioning itself as a bigger, polyglot platform. Credibility on the “open” claim started to matter commercially.

The fix

On January 8, 2026, github.com/microsoft/dcp went public: “Developer Control Plane API server and CLI.” Go code, MIT license, actively developed in the open since. The proprietary EULA era is over; Ed’s follow-up video title said it plainly: “.NET Aspire is now ACTUALLY open source!”

I’ll claim a very small slice of credit for keeping the question on the record since day one, and hand the rest to the people who did the work: David Fowler and the Aspire team, who took community feedback seriously and closed the gap between the marketing and the license. Shipping a component like DCP under MIT was never free for Microsoft; it forecloses the commercial option that old termination clause kept open. They did it anyway. That is how open source stewardship should look.

How to audit “open source” yourself

The transferable lesson isn’t about Aspire. It’s a checklist for any project whose homepage says open source:

1. License the artifacts, not the repo. The repository’s LICENSE file covers the code in the repository. Check what actually lands on your disk: SDK packs, bundled binaries, downloaded tools. Each can carry its own terms.
2. Grep for EULAs where the binaries live. In Aspire’s case the telling file sat in packs/Aspire.Hosting.Orchestration.<RID>/…/tools/, one directory listing away from the marketing claim.
3. Read the grant, not the vibe. “Develop and test your applications” is a scope, and your use case either fits it or doesn’t. If you have to squint, the answer is no.
4. Watch for termination and commercialization clauses. A license that ends “upon first availability of a commercial release” tells you about the vendor’s option space, whatever their current intent.
5. File the boring issue. Not a hot take, just the question with quotes and links. It costs you twenty minutes, it creates the public record, and two years later it’s the thread everyone points at when the fix ships.

The rule of thumb: treat “open source” as a claim about your entire dependency chain, verify it at the level of files on disk, and when you find a gap, put the question on the record politely and durably. Sometimes the system works. This time it did.