Open Source Maintenance Fee

Verify participates in the Open Source Maintenance Fee. The source code stays freely available under the terms of the license, and forks, self-compiled binaries, and contributions are unaffected. What the fee covers is use of the official binary releases, the packages published to NuGet, by organizations that generate revenue from them.

Every version released after 1 September 2026 is covered. Versions released on or before that date are not.

For the reasoning behind the model, and the discussion the terms came out of, see Open Source Maintenance Fee for Verify. For the model itself, see the OSMF FAQ for consumers.

Who pays

The fee applies to:

• Organizations using the official binary releases in revenue-generating activities, with an annual gross revenue of at least US$10,000.
• Government agencies.

Exempt from the fee:

• Individuals.
• Open source projects that do not generate revenue. Voluntary donations and sponsorships are not revenue.
• Organizations that do not generate revenue, other than government agencies.
• Organizations with an annual gross revenue under US$10,000, other than government agencies.
• Organizations that engage the core maintainers for consulting work, for six months from the final date of that engagement.

Paying

The fee is paid by sponsoring VerifyTests at the monthly tier matching the size of the organization:

Organization size	Fee (USD)
Fewer than 40 employees	$5/month
40 to 200 employees	$20/month
200 to 1000 employees	$30/month
More than 1000 employees	$100/month

GitHub Sponsors bills monthly. Organizations that prefer an invoice can use GitHub's invoiced billing for sponsorships: an invoice of at least US$5,000 is paid up front into a sponsorship balance, the monthly sponsorship is then drawn from that balance, and the balance can be spent on any sponsorship and does not expire. That is the only way to pay a year up front; a single one-time sponsorship counts as one month for the build-time check below.

Declaring fee status in the build (v33 and later)

From v33, sponsorship is verified at build time by SponsorCheck. The core Verify package bundles a hashed list of sponsors and a build-time verifier, and every package that depends on it, including the test framework adapters, carries the same check. Nothing phones home: the check runs inside the build, adds no runtime dependency to the packages, and issues no license keys. A build that references a Verify package needs exactly one of the declarations below; without one it fails with SC021, whose message contains a copy-pasteable fix.

The Verify packages use SponsorCheck's owner mode with the owner id Verify, so the declaration is a single MSBuild property rather than metadata on each PackageReference. Set it once in a Directory.Build.props at the root of the repository and it covers every project and every Verify package (Verify.Xunit, Verify.NUnit, and so on), including projects that only reference Verify transitively. Prefer answering a few questions? The SponsorCheck setup wizard for Verify reads the published package and generates the exact snippet.

Sponsoring

Declare the GitHub account the sponsorship is made from, i.e. the organization or user that sponsors VerifyTests:

<PropertyGroup>
  <Verify_GitHubSponsorAccount>your-github-account</Verify_GitHubSponsorAccount>
</PropertyGroup>

The bundled sponsor list is frozen when a version is packed, so a sponsorship that began after that date cannot be in it yet; add <Verify_SponsorshipStart>yyyy-MM-dd</Verify_SponsorshipStart> alongside the account until the next upgrade. A sponsorship that is private on GitHub is never bundled at all; declare <Verify_SponsorshipPrivateUntil>yyyy-MM</Verify_SponsorshipPrivateUntil> instead, at most 12 months out, and renew it when it lapses.

Exempt

Individuals and organizations under the revenue threshold claim SmallRevenue; open source projects that do not generate revenue claim OpenSource; organizations that engaged the core maintainers for consulting work claim MaintainerConsulting. All three exemptions are time-bounded, so an end month is required: at most 12 months ahead of the build date for SmallRevenue and OpenSource, and at most 6 months for MaintainerConsulting. The build passes and logs the exemption's criteria as a message (SC031) rather than a warning, so builds run with -warnaserror pass too. Once the month has passed, the build fails until the claim is renewed.

<PropertyGroup>
  <Verify_SponsorshipExemption>SmallRevenue</Verify_SponsorshipExemption>
  <Verify_SponsorshipExemptionUntil>yyyy-MM</Verify_SponsorshipExemptionUntil>
</PropertyGroup>

For an open source project:

<PropertyGroup>
  <Verify_SponsorshipExemption>OpenSource</Verify_SponsorshipExemption>
  <Verify_SponsorshipExemptionUntil>yyyy-MM</Verify_SponsorshipExemptionUntil>
</PropertyGroup>

For an organization that engaged the core maintainers for consulting work:

<PropertyGroup>
  <Verify_SponsorshipExemption>MaintainerConsulting</Verify_SponsorshipExemption>
  <Verify_SponsorshipExemptionUntil>yyyy-MM</Verify_SponsorshipExemptionUntil>
</PropertyGroup>

Private arrangement

An organization with its own licensing arrangement declares the last covered month, at most a year out, and renews it with a one-line edit:

<PropertyGroup>
  <Verify_SponsorshipLicensedUntil>yyyy-MM</Verify_SponsorshipLicensedUntil>
</PropertyGroup>

Opting out

The build passes but logs a breach-of-license warning (SC023) on every build, so a build run with -warnaserror fails:

<PropertyGroup>
  <Verify_SponsorshipLicenseIgnored>true</Verify_SponsorshipLicenseIgnored>
</PropertyGroup>

See the consumer guide for the full reference and the diagnostic codes for every message the verifier can emit.