The .NET Foundation exists to support a healthy, commercially friendly, open-source ecosystem around the .NET platform. We believe two things can be true at the same time: maintainers need sustainable ways to support the work required to keep open-source projects healthy, and consumers need clear, predictable terms when adopting open-source software.
Some open-source projects have adopted or are considering the Open Source Maintenance Fee (OSMF) and similar funding mechanisms. These models generally distinguish between source code made available under an open-source license and maintainer-provided binary releases, package-manager artifacts, release services, support channels, project infrastructure, or other project conveniences.
The .NET Foundation does not take a position for or against the use of OSMF or similar funding models, whether by projects inside or outside the Foundation. Different projects have different sustainability needs, and organizations that consume open-source software should evaluate each project's terms in the context of their own legal, procurement, security, compliance, and supply chain requirements.
Our guidance for consumers of .NET open-source software is straightforward: do not assume that software obtained through a package manager is governed only by the source repository's license file.
Before adopting or upgrading dependencies, consumers should review the applicable source license, package metadata, package license expression, README, notices, EULAs, release terms, and any project-specific funding, access, or use requirements. Consumers should also distinguish between rights granted in source code under an open-source license and additional terms that some maintainers may apply to maintainer-provided binaries, hosted services, release channels, project infrastructure, support, or other convenience artifacts. Where those terms are unclear, consumers should consult their own counsel.
This guidance applies to all .NET open source projects, whether Foundation members or not. Foundation membership provides certain structural assurances described below, but does not eliminate the consumer's responsibility to review the specific terms applicable to the artifacts they consume.
Foundation projects remain subject to the Foundation's existing eligibility criteria, which include, among other things:
Source code is distributed to the public at no charge under a Foundation-approved permissive open source license.
Mandatory dependencies of the project are offered under a standard, permissive open source license approved by the Foundation, with limited exceptions for platform or hardware-specific libraries where no alternative is available.
A build script exists that can produce deployable artifacts functionally equivalent to the official releases, with the exception of code signing.
Committers are bound by a Contributor License Agreement, copyright ownership is clearly defined, and the project adheres to the .NET Foundation Code of Conduct.
These criteria continue to apply, and they meaningfully bound the design space available to Foundation projects considering OSMF or similar funding models.
A funding model that is incompatible with these criteria — for example, one that paywalls source code, restricts the public's ability to build equivalent artifacts from source, or introduces a mandatory dependency under non-permissive or paid terms — would put a project's eligibility in question.
A funding model that applies only to maintainer-provided binaries, hosted services, support, signed releases, official package distribution, or other convenience artifacts, while leaving the source and self-build path intact and the mandatory dependency chain permissively licensed, is generally compatible with these criteria. Adopting such a model does not, by itself, violate Foundation policies.
The Foundation's interest is not in approving or denying specific funding model decisions, but in ensuring the ecosystem has clear and consistent information about the terms under which Foundation projects are distributed. Maintainers considering material funding-model changes — including the introduction of OSMF, EULAs on official packages, payment requirements for binary distribution, or similar changes — are encouraged to notify the Foundation in advance so that consumer-facing communications and ecosystem coordination can be handled clearly.
The Foundation encourages organizations that benefit from open source software to support the maintainers and projects they rely on. Sponsorships, paid support, consulting, commercial services, dual licensing, commercial editions, maintenance fee models, and other sustainability approaches can all play valuable roles in the ecosystem when they are clear, transparent, and compatible with the applicable open-source commitments and, where relevant, the Foundation's eligibility criteria.
Our goal is not to discourage maintainer sustainability or to tell consumers which funding models to prefer. Our goal is to preserve clarity. Open source works best when contributors, maintainers, and consumers understand the terms under which software is created, distributed, and relied upon.
Review dependency terms carefully, especially when adopting or upgrading packages used in production or commercial products. Foundation membership provides structural assurances about source availability, build reproducibility, and mandatory dependency licensing — but does not relieve you of the responsibility to review the specific terms attached to the artifacts you consume.
Funding model changes, including OSMF, do not by themselves violate Foundation policies, provided the project remains compatible with the Foundation's eligibility criteria. Notify the Foundation in advance of material changes so we can support clear communication to the community.
The Foundation neither endorses nor opposes OSMF or similar models outside the Foundation, but encourages all participants in the ecosystem to be transparent about the terms that apply to their software.
Adopted by the Board of Directors of the .NET Foundation on [date].
This companion document accompanies the .NET Foundation Statement on Open Source Maintenance Fees. It addresses common questions about how OSMF and similar funding models interact with .NET open source projects and Foundation membership.
Foundation affiliation indicates that a project meets the Foundation's eligibility criteria, which include:
Source code distributed to the public at no charge under a Foundation-approved permissive open source license
Mandatory dependencies offered under similarly approved permissive licenses
A build script capable of producing deployable artifacts functionally equivalent to the official releases (with the exception of code signing)
Committers bound by a Contributor License Agreement
Clearly defined copyright ownership
Adherence to the .NET Foundation Code of Conduct
What Foundation affiliation does not guarantee: that maintainer-provided binaries, packages, or services will always be free; that no EULA or supplemental terms will ever apply to convenience artifacts; that a project funding model will never change. The Foundation badge is a signal of governance and structural openness, not a warranty against future evolution of commercial terms. The Foundation badge is a signal of governance and structural openness, not a warranty against future evolution of commercial terms.
For most .NET consumers: both.
When you run dotnet add package, you are consuming a maintainer-built binary plus its embedded license metadata. The source license on GitHub governs the source. The package may carry additional terms via its license expression, EULA, README, or other artifacts shipped alongside it. These can — and under OSMF-style models, are often designed to — differ.
No.
The <license> element in a .nupkg is one signal, but maintainers may also include EULA files, link to terms in the README, ship THIRDPARTY.txt notices, or post terms on the project website. NuGet does not enforce a single source of truth for terms.
Consumers should review everything that travels with the artifact, including any in-package files and the maintainer's published terms.
For source acquired under prior license terms, your rights to that specific source under that specific license are generally what they are; a permissively licensed release does not retroactively become non-permissive because the maintainer changes terms later.
In practice, however, "grandfathered" means "frozen": package availability is not guaranteed indefinitely; security patches typically will not be backported, and any new version you adopt is governed by whatever terms apply at the time of adoption.
For Foundation projects, mandatory dependencies are required by the eligibility criteria to be permissively licensed and Foundation-approved. This significantly reduces — but does not eliminate — exposure to the core dependency chain.
For non-Foundation projects, no such guarantee exists; consumers must audit the full graph themselves. Tools such as dotnet list package --include-transitive, SBOM generators, and license scanners can help, but none fully eliminate the need for review.
Optional or recommended dependencies, even of Foundation projects, are not subject to the mandatory-dependency criterion and require independent review.
This is project-specific. There is no industry-standard OSMF trigger.
Triggers may include commercial use above defined thresholds, use in production, use by entities above a revenue threshold, use of specific binary distributions, or use after a specified date.
Consumers cannot assume any particular trigger structure and must review the terms for each project that adopts a fee model.
Project-specific.
Typically, you pay the maintainer or their commercial entity in exchange for continued rights to use the binaries or packages, and often some level of support, security updates, or a commercial-use grant.
What a fee typically does not purchase is rights you didn't already have under the source license — those were already granted. The fee is for convenience artifacts and assurance, not for the source code itself.
Consumers should clarify: who is the legal counterparty, what is the term, what is the renewal mechanism, what happens if the maintainer stops maintaining, and whether any perpetual fallback exists.
In nearly all cases, yes.
The Foundation's eligibility criteria require that a build script exists which can produce deployable artifacts functionally equivalent to the official releases (excluding code signing). Consumers retain a working self-build path by policy.
It depends on the source license and whether a working build is actually achievable from the public source.
In either case, consumers who self-build forfeit signed releases, official package distribution, support, and the maintainer's chain-of-custody assurance.
For some organizations — particularly those in regulated industries or with strict supply-chain compliance requirements — self-built artifacts may not be operationally acceptable even when legally permitted.
Your rights to versions you have already acquired under the prior terms are unaffected.
Going forward, you will need to evaluate the new terms against your own use and decide whether to pay the fee, remain on a prior version, build from source, or migrate to an alternative.
If the new terms appear inconsistent with the Foundation's eligibility criteria — for example, if the source itself becomes paywalled or the build path is closed — you may raise the issue with the Foundation through its standard channels.
The Foundation evaluates eligibility on an ongoing basis and may revisit a project's status if its compliance with the criteria is in question.
Trust the badge for what it represents: structural openness — free permissively-licensed source, a working build path to functionally equivalent artifacts, permissively-licensed mandatory dependencies, defined copyright, a CLA, and code of conduct enforcement.
Do not treat the badge as a guarantee of stable commercial terms, free-forever maintainer-provided binaries, or no future EULAs on packages.
The Foundation does not pre-clear funding model changes, and the badge is not a consumer-protection certification in that sense.
Consumers who need such guarantees should obtain them contractually from the maintainer, fork at a known-good version, or factor in the project's funding-model trajectory into their adoption decision.
Not by itself.
An OSMF-style model that applies only to maintainer-provided convenience artifacts — binaries, packages, hosted services, support, signed releases — while leaving the source under a Foundation-approved permissive license, the build path open, and the mandatory dependency chain permissively licensed, is generally compatible with the eligibility criteria.
A model that paywalls the source itself, closes the public build path, or introduces a mandatory dependency under non-permissive or paid terms would put eligibility in question.
No. Foundation approval is not required.
Please notify the Foundation in advance of any material changes to the funding model so we can coordinate consumer-facing communications and keep the broader ecosystem informed.
There is no exhaustive definition, but reasonable examples include adopting a maintenance fee, adding an EULA to official packages or binaries, introducing payment requirements for binary distribution, changing the source license, changing how official artifacts are signed or distributed, or imposing new conditions on commercial use.
Routine engineering changes — version bumps, API deprecations, dropping support for old runtimes, ordinary semantic-versioned releases — generally do not require notification.
Email [email protected] with a brief description of the proposed change, the expected timing, and a link to any draft terms, EULA, or public communications you intend to publish. The Foundation will acknowledge receipt and follow up if coordination, clarification, or eligibility review is warranted.
Notification is most useful when it arrives before the change is publicly announced, so that consumer-facing communications across the ecosystem can be aligned.
Notification after a change has already shipped is still welcomed but provides less opportunity for coordination.
The consumer guidance applies to all .NET open source projects.
The Foundation neither endorses nor opposes OSMF or similar funding models for projects outside the Foundation, and the Foundation's eligibility criteria do not bind non-Foundation projects.
Consumers of non-Foundation projects do not have the structural assurances that Foundation membership provides — free permissively-licensed source, build reproducibility, permissively-licensed mandatory dependencies — and should apply correspondingly greater diligence when reviewing project terms.