Navigating .NET library licensing changes.

Affected Libraries

Summary

• 2026-04-10

  What's New in NPOI 2.8.0: A New Chapter for Sustainable Open Source

  Maintaining an open-source project relied upon by countless independent developers and enterprise giants requires an immense amount of time and resources. To ensure NPOI continues to grow and remains secure for the long term, version 2.8.0 introduces the Open Source Maintenance Fee (OSMF) model. NSax was also removed to resolve the earlier LGPL-3.0 licensing conflict.

  npoi
• 2026-02-04

  Open Source Maintenance Fee v1.1

  The OSMF EULA is updated to v1.1, adding a minimum annual revenue threshold of US $10,000 before the maintenance fee applies — explicitly exempting hobbyists and very small organizations from the WiX Toolset fee.

  wix-toolset
• 2025-09-30

  NSax dependency introduces LGPL-3.0 into Apache-2.0 NPOI (2.7.5)

  From 2.7.4 to 2.7.5, NPOI added a dependency on NSax, which is licensed under LGPL-3.0 — generally incompatible with NPOI's own Apache-2.0 license. This left an Apache-2.0 package transitively pulling in copyleft code, a problem for teams that restrict (L)GPL dependencies. NSax was later removed in 2.8.0.

  npoi

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 primarily distinguish between open source and proprietary software, but focuses on control, distribution, and responsibility for maintaining secure software throughout its lifecycle. In a typical OSS scenario where components are consumed “as-is” from source repositories, the integrating organization is generally responsible for managing dependency selection, updates, and overall supply chain governance within its product. When software is distributed as prebuilt binaries under an End User License Agreement (EULA), an additional contractual layer is introduced on top of the underlying source license. This can affect how binaries are obtained, updated, and reused within an organization, depending on the specific terms of the EULA. From a CRA perspective, this does not remove or transfer responsibility away from the integrating organization, which remains accountable for the security of the final product and its overall software supply chain. However, it may introduce additional obligations or expectations on the software provider regarding vulnerability handling, update mechanisms, and lifecycle management of the distributed binaries, depending on the distribution model. In practice, the presence of a binary EULA can change the governance model from a purely source-driven dependency to a more vendor-mediated supply chain component, which may need to be considered explicitly in SBOM generation, dependency tracking, and compliance processes.