_Check your solution in one command, along with MediatR, AutoMapper, MassTransit and FluentAssertions._ On 14 July 2026 the Polly project announced that it's adopting the **Open Source Maintenance Fee (OSMF)**. Payment requests start on **16 November 2026**. Polly is everywhere in .NET. The `Polly` package alone has more than 1.7 billion downloads, and Microsoft's own resilience packages are built on it. So the question many teams are asking right now is simple: **do we have to pay?** For most teams the answer is no, but it depends on two details that are easy to miss. In this post I'll explain both, then show how to check every project in your solution in one command. ## What actually changes Here's what the Polly announcement says, quoted directly: * **Price and threshold:** "The Maintenance Fee is US $20 per month and applies to any company that earns at least US $20,000 from at least one product or project that uses Polly." * **Which versions:** "The fee applies only to the next major version of Polly released after November 16, 2026." And: "Existing versions of Polly are not subject to the fee." * **Which references:** "Only direct references to Polly are subject to the fee. If Polly is a dependency of a different library, such as Microsoft.Extensions.Resilience or Microsoft.Extensions.Http.Resilience, the fee does not apply." The source code stays open under its existing BSD-3-Clause licence. Individuals, students, hobbyists and organisations below the revenue threshold don't pay. ## The two details that decide whether you're affected **1. Version.** Polly 8.x, which is what you're almost certainly using today, is not affected. The fee applies to the next major version (Polly 9) released after 16 November. So upgrading carelessly is the real risk, especially with Dependabot, Renovate or a casual `dotnet add package Polly`. **2. Direct vs transitive.** If you only get Polly through Microsoft's resilience packages, the fee doesn't apply. A typical example is `AddStandardResilienceHandler()` from `Microsoft.Extensions.Http.Resilience`. Your app still loads `Polly.Core`, but you don't reference it yourself. Both are hard to see by eye in a real solution: * **Using statements don't tell you.** The official OSMF guidance warns about this itself: `using Polly;` compiles whether Polly comes in directly or through another package. * **References hide in many places.** They can be in `Directory.Build.props`, in `Directory.Packages.props` with Central Package Management, or in one test project nobody looks at. * **Licence scanners won't flag it.** Polly's licence label stays BSD-3-Clause, so tools that compare licences against an allowed list see nothing unusual. The OSMF website's advice for .NET is to open every `.csproj`, collect the package references and check each one by hand. ## Check it in one command I built a small open-source tool for exactly this: **PackageTerms**. It reads the restore output NuGet already produces (`obj/project.assets.json`), so it sees the exact versions your projects resolve, including transitive ones, and tells you which packages changed their terms. dotnet tool install -g PackageTerms package-terms scan MySolution.sln Here's a sample solution with an API project and a test project: Scanned 2 project(s). [COMMERCIAL] MediatR 13.1.0 (direct) From v13, MediatR is dual-licensed under RPL-1.5 and the Lucky Penny Software commercial licence. Earlier versions keep their original Apache-2.0 terms. Last free version: 12.5.0 Alternative: Mediator.SourceGenerator: Source-generated mediator by Martin Othamar (MIT). Projects: Shop.Api.csproj [COMMERCIAL] MediatR 13.1.0 (transitive via Shop.Api (project)) ... Projects: Shop.Tests.csproj [UPGRADE RISK] Polly 8.9.0 (direct) Your version is still free, but Polly 9.0.0 and later carries a maintenance fee (from 2026-11-16). Check the terms before upgrading. Who pays: Companies earning at least US$20,000 from a product or project that uses Polly: US$20 per month. Direct references only; Polly brought in by another library (for example Microsoft.Extensions.Http.Resilience) is exempt. Projects: Shop.Api.csproj And here's a project that only uses Microsoft's resilience package: [NO ACTION] Polly.Core 8.4.2 (transitive via Microsoft.Extensions.Http.Resilience → Microsoft.Extensions.Resilience → Polly.Extensions) Polly's new terms cover direct references only, so this transitive reference is exempt. For each package, the output tells you three things: * **Are you affected?** It shows your exact version and whether the reference is direct, or the chain of packages or projects it comes through. * **What changed and when** , with a link to the official announcement. * **What to do** : the last free version and free alternatives. ## It's not just Polly Polly is the newest change, but several popular .NET libraries changed their terms in the last two years. PackageTerms checks these too: Package | What changed | Covered versions | Last free version ---|---|---|--- Polly | Maintenance fee, direct references only | 9.0 and later | 8.x MediatR | Commercial licence (free Community edition under US$5M revenue) | 13.0 and later | 12.5.0 AutoMapper | Commercial licence (free Community edition under US$5M revenue) | 15.0 and later | 14.0.0 MassTransit | Commercial (Massient licence) | 9.0 and later | 8.5.12 FluentAssertions | Paid licence for commercial use (Xceed) | 8.0 and later | 7.2.2 Every entry links to the project's own announcement or licence, and the data is open on GitHub. If you know of a package that's missing, please open an issue with a link to the official source. ## Catch it in CI, before it reaches main Upgrades usually arrive through automated pull requests. Add one step to your pipeline and the build fails if an affected package slips in: - run: dotnet tool install -g PackageTerms - run: package-terms scan --fail-on affected Use `--fail-on upgrade-risk` to be stricter, or `--format markdown` to post the result as a pull-request comment. ## What to do if you are affected * **Polly, direct reference, organisation above US$20K revenue:** stay on Polly 8.x (it's not subject to the fee), budget US$20 per month when you move to Polly 9, or use `Microsoft.Extensions.Http.Resilience` for HTTP resilience, which brings in Polly transitively and is exempt. * **MediatR, AutoMapper, MassTransit, FluentAssertions:** check whether you qualify for a free tier, buy a licence, pin to the last free version, or move to an alternative such as Mediator.SourceGenerator, Mapperly, Rebus or Shouldly. Whatever you decide, decide it deliberately rather than finding out from an automated upgrade. ## Try it * Install: `dotnet tool install -g PackageTerms` * Source and dataset: https://github.com/paulap887/PackageTerms * Polly announcement: https://thepollyproject.org/2026/07/14/polly-osmf-announcement.html ## paulap887 / PackageTerms ### Find NuGet dependencies that went commercial or added a maintenance fee (Polly, MediatR, AutoMapper, MassTransit, FluentAssertions). A dotnet tool. # PackageTerms **Find the NuGet packages in your .NET solution that went commercial or added a maintenance fee, before they surprise you.** Several popular .NET libraries have changed their terms: MediatR and AutoMapper went commercial, MassTransit v9 and FluentAssertions v8 need paid licences for commercial use, and Polly adds a maintenance fee for its next major version. Licence scanners that only read a package's licence label can miss these changes. Polly's licence, for example, stays BSD-3-Clause. They also don't tell you which version changed, whether the change applies to you, or what to do about it. `package-terms` scans your solution and tells you, for each affected package: * **Whether you're affected** : the exact version you resolve, and whether you reference it directly or it comes in through another package or project * **What changed and when** , with a link to the official announcement * **What to do** : the last free version… View on GitHub If it saves you a surprise invoice, a ⭐ on GitHub helps other .NET developers find it. If it misses a package or gets something wrong, an issue with a link to the official source is even better.

This repo is currently using FluentAssertions version 6.12.0. Please migrate to using AwesomeAssertions.

This repo is currently using FluentAssertions version 6.7.0. Please migrate to using AwesomeAssertions.

This repo is currently using FluentAssertions version 6.7.0. Please migrate to using AwesomeAssertions.

YouTube video by Claudio Bernasconi

YouTube video by Claudio Bernasconi

Check out fluentassertions/fluentassertions on GitHub

Contribute to kmtchl/FluentAssertionsToShoudlyConverter development by creating an account on GitHub.

Hi 🙋‍♂️. I'm Nico Jansen, a manager at Info Support. For years, we've sponsored FluentAssertions, a comparable assertion library. My colleagues also contributed a lot of code to the project.…

A fork of FluentAssertions controlled by the community. - AwesomeAssertions/AwesomeAssertions