OSMF adoption

[Tychus]

I read somewhere that Polly is adopting OSMF but can't find anything on github to verify that claim. Is tha true ?

[martincostello]

thepollyproject.org - Introducing the Open Source Maintenance Fee for Polly

[Tychus]

So to confirm this takes effect November 16. And according to the OSMF page, the payment will be done through github sponsoring ?

[martincostello]

Yes.

[scottrudy]

Just for clarification, if a project is using Microsoft.Extensions.Http.Resilience, which has a dependency on Polly and comes wired out of the box with an Aspire project in dotnet, that means a company is now required to pay a fee assuming they have annual revenue of more than $20K?

[LuciferSam8086]

https://opensourcemaintenancefee.org/consumers/faq/#q-if-i-use-a-project-and-that-project-depends-on-other-projects-do-i-need-to-pay-all-of-them

[brettstedford]

Am I right in thinking that, in @scottrudy's case of using the Microsoft.Extensions.Http.Resilience, then no, the fee doesn't apply?

[martincostello]

That is my understanding, yes.

[LiorBanai]

or just Microsoft.Extensions.Resilience

[delreluca]

Note that the NuGet packages state BSD-3-Clause. The next release should change that, if you want the artefact to be under a different licence:

Polly/eng/Library.targets

Line 29 in 47e3b41

<PackageLicenseExpression>BSD-3-Clause</PackageLicenseExpression>

[martincostello]

I don’t see how you can apply it to already published packages

You can't - licenses in a version are immutable.

To my knowledge, this isn't being applied retroactively (which is also impossible to do anyway).

In November the license will change, and a new version with that license will be published at that time, as I already said above.

[LuciferSam8086]

My understanding is that the license will be changed at the point that the OSMF will apply (which is in November, as noted in the blog post) and a new version with the license change will be published at that point.

which would be the opposite written here:
The source code remains free and open. Polly stays under its existing open source license. Nothing about your right to read, fork, build from, and contribute to the source changes.

https://thepollyproject.org/2026/07/14/polly-osmf-announcement.html

[martincostello]

@joelhulen @carlfranklin Care to chime in here?

[LuciferSam8086]

From what I read only the packages themselves will require the "mandatory" sponsorship, source code will be not interested in this, so anyone could fork Polly, call it another way and keep it updated from the upstream.

Of course Polly team could change its license to protect their work if they notice too many people forking or building from source skipping the sponsorship, but I would like to see a clear answer and avoid a license rug pull, that's not pleasant at all.

For me, at the office it's not a problem to pay 20$ / month, we even pay even more expensive libraries, but 20$ here, 20$ there, might be a problem to explain to the boss, and we might just decide to drop a library, even if it's useful.

I hope I have been clear, my English is a bit rusty :)

[delreluca]

I was talking about the licence of the packages uploaded to NuGet, so I thought the sentence about licence change was referring to that specifically.

The blog post talks about the licence of the source code.

You can still build your own binary or NuGet package from source as long as the source code stays under the same licence.

But at the same time, the BSD-3-Clause licence does not prevent the maintainers from distributing the package under a more restrictive licence, as long as the conditions (copyright statement, disclaimer, etc.) are met.

I think communication should ideally be a lot clearer: Distinguish between what exactly is distributed under what terms, and when saying something like ‘licence change’ it’s better to refer to it as a change for future packages (or future contributions, but that should not apply here), to not confuse people scared of retroactive changes.

[slang25]

Just floating ideas - what if the OSMF was targeted specifically at the Polly nuget package, and not Polly.Core. That would give a clean path for other frameworks like Brighter and ASP.NET Core to build on, but to your average enterprise "We use Polly, we'll pay".

My understanding was that Polly.Core was a collaborative effort, so it seems reasonable that it remain free and a core piece of infrastructure for the dotnet ecosystem.