Navigating .NET library licensing changes.

Affected Libraries

Summary

• 2026-08-29

  Fences: a BSD-3-Clause community fork of Polly ships to NuGet

  After opening a "Forking Polly" discussion on 18 August 2026, Ian Cooper and the Brighter Command team published Fences — a fork of Polly 8.7.0 that keeps the BSD-3-Clause terms and carries no maintenance-fee EULA. Packages ship under the Paramore.Fences.* prefix (9.0.0 stable on 29 August 2026) and the v8-era API mirrors Polly's exactly. It is not affiliated with or endorsed by App vNext.

  polly
• 2026-08-29

  Coding Bolt: The Polly Drama Explained

  A walkthrough of the reaction to Polly's Open Source Maintenance Fee. The argument made is that the $20/month is not the real cost — the friction is legal review, procurement and dependency-policy overhead once commercial terms enter the dependency tree. Covers the Fences fork and the .NET Foundation's clarification that consumers must review terms beyond the source license.

  polly
• 2026-08-29

  Renato Golia: Free software never promised free labour

  Golia argues an open source license is a backward-looking promise about code already published, not a commitment to perpetual free maintenance — which is why fee models that leave existing releases untouched sit differently from retroactive relicensing. Draws parallels with Elasticsearch/OpenSearch and Redis/Valkey alongside the AutoMapper, MediatR and Polly changes.

  pollyautomappermediatr

FAQ

• Tell me about this website

  This website is a resource hub for developers seeking to understand and manage open-source licenses. It offers information on various licenses, their usage, and project management. The goal is to provide the reasoning behind licenses, enabling informed decisions. It does not discourage paid licenses but aims to foster understanding for better choices. This website is an independent project by a single developer and is not affiliated with any specific license.

• Library X has gone commercial. What are my options?

  Don't panic! 😎 First, review the pricing and consider paying if you value the library and plan to continue using it. Often, you can stick with the last free version by pinning its version (e.g. `[1.0.0]` or `[1.0.0,2.0.0)`). If the license permits, forking the library for personal maintenance is another option. Finally, explore open-source alternatives.

• Why is there negative sentiment towards some libraries that have become commercial?

  Negative sentiment towards commercializing libraries arises mainly from how it's done. Moq's secret email collection and network calls via SponsorLink caused backlash. FluentAssertions' abrupt, costly license change also drew criticism, including questions about past contributions. Key issues are: lack of transparency, sudden changes, questionable privacy (Moq), and perceived disrespect. Positive examples like MassTransit's clear versioning and future plans, ImageSharp's fair dual-licensing, and Jimmy Bogard's (MediatR, AutoMapper) transparent, non-punitive approach show that clear communication, grandfathering, and community respect lead to better reception. The process of commercialization must be handled carefully to avoid negative reactions.

• How can I contribute to this project?

  If you'd like to propose changes, add information, or contribute in any way to the project, please visit the GitHub repository at https://github.com/dariusz-wozniak/fossed. There, you can create issues for suggestions or problems, or create a pull request. All contributions are welcome and appreciated!

• OSS, binary distribution and CRA: where does responsibility change?

  The Cyber Resilience Act (CRA) does not draw the line between open-source and proprietary software. For free and open-source software (FOSS), the Commission's guidance on Regulation (EU) 2024/2847 https://ec.europa.eu/newsroom/dae/redirection/document/131456 makes the decisive test whether the software is placed on the market — i.e. supplied in the course of a commercial activity, which in practice means monetised by the person responsible for it. FOSS that is not monetised is outside the CRA, except that a legal person publishing it may still bear the lighter obligations of an open-source software steward (Article 24); a natural person publishing an unmonetised version is fully out of scope. Where components are consumed "as-is" from public source repositories, the upstream publisher is generally not placing a product on the market, and the organisation that integrates those components into its own monetised product is the manufacturer of that product: it does not become responsible for each component's individual CRA compliance, but it is responsible for its own product and carries a due-diligence obligation under Article 13(5) plus a duty to report vulnerabilities in integrated components and share fixes upstream under Article 13(6). When the same software is instead obtained as priced pre-built binaries (e.g. under a EULA), the trigger is the price, not the EULA: charging a price for "the pre-compiled binaries" means placing a product with digital elements on the market, so the supplier is a manufacturer under the CRA with the full manufacturer obligations for that binary product. The guidance treats the paid version and the free "community" version as different products even where the codebases are almost identical or the paid one is an "enhanced"/"open-core" build, and a legal person supplying both is a steward for the community version and a manufacturer for the paid one. In practice this changes the governance model from a purely source-driven dependency (backed at most by a steward, or by no CRA-regulated entity) to a vendor-mediated component backed by an identifiable manufacturer accountable for vulnerability handling and updates — a distinction that should be reflected explicitly in SBOM generation, dependency tracking and compliance processes.