What Do Open Source Maintenance Fees Mean for Your Legacy App?

On July 14, the Polly project announced it was adopting the Open Source Maintenance Fee (OSMF).

Polly is the core resilience library that handles retries, circuit breakers, hedging, timeouts, and fallbacks and underpins a massive footprint of enterprise .NET software, totaling over two billion package downloads. Starting November 16, 2026, any business earning at least $20,000 in revenue from a product using the package is asked to pay $20 a month. That’s per organization, not per application. The underlying source license remains open source.

On August 19, the .NET Foundation released an official statement and a detailed FAQ on open-source maintenance fees. The Foundation declined to take a position for or against them. That’s standard institutional protocol and probably the least interesting detail in the document.

The interesting part is the guidance directed at consumers: stop assuming the LICENSE file in a GitHub repository defines what you are permitted to do with the compiled binary you pulled down.

If you're running a twenty-year-old Visual Basic 6 or PowerBuilder desktop app and weighing a migration to modern .NET and Blazor, this shift affects your roadmap. It isn't a showstopper, but it's an operational reality and your procurement or legal team will flag it if engineering doesn't.

What the Maintenance Fee Attaches To

The Open Source Maintenance Fee doesn't put repo source code behind a paywall. Polly remains under its existing open-source license. Developers can still inspect, fork, compile, and contribute back to the codebase under the same terms as before.

What the fee model does is decouple two assets that .NET engineers have treated as synonymous for fifteen years: the source code and the maintainer-built binary distributed via dotnet add package.

The NuGet binary is a distinct release artifact governed by its own terms. It includes a package-level license expression in the .nupkg, but it can also bundle a dedicated EULA file, link out to repository terms, include a THIRDPARTY.txt notice, or enforce conditions outlined on the maintainer's project site.

Plus, the NuGet client doesn't enforce a single, unified source of truth across those files. The .NET Foundation's guidance states this explicitly: the <license> tag in a package manifest is merely one signal, not the definitive legal agreement.

The WiX Toolset hit this friction in April 2025. WiX v6 introduced a maintenance fee; WiX v7 had to add explicit build-time EULA acceptance mechanisms because package managers don't reliably present commercial terms to developers during installation. The licensing terms existed in v6, but developers blew right past them.

That's the operational risk surface. The issue: the terms governing the compiled artifacts in your build pipeline can diverge from the repository license you checked six months ago and your package manager won't interrupt your build to tell you.

Why Modernization Changes the Dependency Equation

A legacy VB6 application built in 2004 operates on a dependency graph that hasn't changed in two decades. In software architecture, that static graph is usually categorized as technical debt, which it is.

However, it carries one accidental commercial benefit that teams take for granted: the licensing terms are permanently frozen.

The Sheridan, Crescent, and Apex controls in older project files were once commercial third-party components. The 16-bit and 32-bit VBX/OCX ecosystem was an active software market with formal invoices and vendor negotiations. Over time, those component vendors folded, active updates ceased, and the licensing conversation went silent. The risk was never resolved; it just became dormant.

Migrating legacy systems trades a frozen dependency graph for an active one:

 Legacy Desktop Stack (VB6 / PowerBuilder)
└── Frozen Controls (Sheridan / Apex / Crescent)
    └── Zero updates, zero active terms, dormant risk

Modern Target Architecture (.NET / Blazor / Azure)
└── Dynamic NuGet Graph (Polly, EF Core, etc.)
    └── Active maintainers, continuous CVE patches, evolving distribution terms

A target architecture built on modern .NET and Blazor pulls in 40, 80, or 200+ transitive dependencies. These libraries are maintained by active engineering teams who are solving critical reliability problems and establishing sustainable funding models. Some of those maintainers will update their package terms. That's how an active software supply chain functions.

For technology leaders and CIOs, the modernization framing is straightforward: migration moves an organization from a static dependency surface that can't adapt to an active one that requires ongoing governance.

The "Build From Source" Loophole and Why Enterprise Change Control Rejects It

Every debate about the OSMF points to a standard technical fallback: if an enterprise doesn't want to pay the maintenance fee, simply compile the package from the open-source repository.

For .NET Foundation member projects, self-compilation is backed by project criteria: maintainers must provide build scripts capable of producing functional parity with public releases.

There's an explicit exception in that policy: code signing.

As the .NET Foundation FAQ points out, internal builds sacrifice:

1. Maintainer-signed production releases and verifiable cryptographic origin
2. Centralized package distribution via primary registries
3. Maintainer-backed support channels
4. Clear software supply chain chain-of-custody tracking

The Foundation notes plainly that for organizations operating under strict regulatory oversight or compliance standards, self-built binaries may not be viable even when the license permits them.

For organizations in healthcare, banking, insurance, or audited manufacturing environments, telling a Change Advisory Board or compliance auditor that engineering pulled down raw Git repos to compile and internally sign core resilience plumbing introduces unacceptable supply-chain risk. The self-build option is real, but in regulated enterprise environments, it leads straight into a compliance roadblock.

The alternative is freezing the application on older, pre-fee package versions which comes with its own expiration date. While grandfathered rights to older package versions remain intact, maintainers generally don't backport security vulnerability patches to frozen major versions, and long-term package host availability is never guaranteed. Version pinning is a temporary operational patch, not a long-term architecture strategy.

The "Hidden Costs" Argument Against Modernization Doesn't Hold

As these fees gain visibility, some steering committees will inevitably raise an objection: "If .NET libraries are adding fees, why not leave the legacy code alone?"

Compare the actual economics:

Polly's fee is $240 annually per organization, with a $20,000 revenue floor that exempts early-stage products and hobbyists. (The baseline OSMF standard sits at a $10,000 threshold; Polly set its cutoff at $20,000).

Now calculate the real run cost of the legacy alternative. A legacy desktop system carries an ongoing maintenance fee denominated in:

• Retaining the few specialized engineers who still understand procedural legacy codebases
• Premium contractor rates when key maintenance staff retire
• Recurring compliance findings on unsupported runtime environments
• Missed business capabilities delayed by multi-quarter legacy release cycles

That maintenance bill hits the balance sheet every fiscal quarter. It just arrives disguised as overhead rather than a vendor invoice. An explicit, predictable $240 line item from an active dependency maintainer is transparent operational pricing which is the opposite of the hidden liabilities inside a legacy code estate.

5 Steps for Software Supply Chain Governance

To get ahead of shifting open-source distribution models during a modernization initiative, implement these operational steps:

1. Audit Transitive Dependencies with an SBOM
   Run dotnet list package --include-transitive across existing .NET repositories and generate a machine-readable Software Bill of Materials (SBOM). Foundation policies only extend guarantees to mandatory dependencies of member projects; optional or transitive packages from non-member projects operate independently.
2. Inspect the Distributed .nupkg, Not Just GitHub
   Validate the full package artifact during pipeline ingestion. Check the manifest license metadata, embedded EULA files, README links, and legal notices inside the compiled binary.
3. Mandate Dependency Manifests in Vendor SOWs
   If an external modernization vendor is transforming legacy systems into modern architectures, they are selecting the target software supply chain. Require an explicit dependency manifest in the statement of work. (GAPVelocity AI provides full transparency into every generated package graph).
4. Establish Pre-Build Procurement and Legal Routing
   Define clear approval policies for new external dependencies before they are merged into production branches, rather than discovering updated commercial terms during an external security or licensing audit.
5. Align Reviews with .NET Release Windows
   Polly’s fee takes effect November 16, coinciding with the .NET platform release cadence. Rolling dependency license reviews into planned framework upgrade cycles minimizes operational friction.

Managing the Destination Architecture

Maintainers responsible for critical, complex software components need reliable funding mechanisms beyond occasional grants, and enterprise engineering teams need clear visibility into the software licenses they consume. Both realities can exist simultaneously.

Modernization projects generate new software supply chains. When moving core business systems off legacy platforms like VB6, PowerBuilder, Microsoft Access, WinForms, or Delphi, the resulting package manifest requires the same engineering rigor and review as the system architecture diagram.