Open Source License Policy Template: A Copy-Paste Allow/Caution/Deny List, Intake Form & Re-Licensing Watch Clause

Want the templates only? Jump to "A copy-paste allow/caution/deny list" and "An intake form you can paste into GitHub." Only here for re-licensing? Skip to "A re-licensing watch clause." 日本語版 (Japanese version, Japan-jurisdiction): 社内OSS/SaaS調達規程のつくり方.

Written: 2026-06-13 / Jurisdiction in focus: United States & EU (other regions referenced as background)

This article is part of a series on software rights and licensing. For how to read a license, see Reading OSS licenses; for building a bill of materials, see SBOM tools; for the SaaS◆ terms-of-service side, see Reading AI service terms.

Mini-glossary (for first-time readers):

• OSS (Open Source Software): software whose source is public and which you may use, modify, and redistribute within the terms of its license.
• SaaS (Software as a Service): cloud software you use through a browser without installing it.
• SBOM (Software Bill of Materials): an inventory of the software components in a product, with their licenses and versions — a "list of ingredients" for software.
• Copyleft: a license property that requires you to share source under the same terms. Strong copyleft (GPL) and network copyleft (AGPL, which triggers on offering the software over a network) propagate broadly; weak / file-level copyleft (LGPL, MPL) propagates only to the licensed files, not your whole codebase. The condition and its scope differ by license.
• Source-available: source you can read but that does not meet the Open Source definition (BSL / SSPL / FSL). Each works differently — BSL restricts production use beyond a vendor-defined "Additional Use Grant," SSPL requires you to open-source your entire service stack if you offer it as a service, and FSL forbids a "Competing Use" (product or service) but converts to a permissive license after two years (Apache 2.0 or MIT, depending on the variant the vendor adopted — FSL-1.1-ALv2 or FSL-1.1-MIT). The common thread is that internal use is usually fine while shipping a customer-facing product or service can trigger the restriction — always read the specific license.
• GitHub: a platform for hosting source code and collaborating on it; much OSS is published and distributed there.
• Issue: a unit on GitHub (and similar tools) for filing and tracking a task, request, or intake one at a time; here, where you paste the procurement request form.
• PoC (Proof of Concept): a small trial to confirm something is technically viable before full adoption.
• CI (Continuous Integration): automatically building and testing code on each change; here, where you wire in SBOM generation.

Adopting OSS◆ and SaaS is no longer a question of "an individual picking a library." A project you adopted under a permissive license can re-license its future releases to "conditional" or "no longer for resale" terms — so your next upgrade, not your installed version, is what changes (already-released versions keep the license they were granted). This has happened repeatedly over the past few years. But routing every decision through legal stalls development. This article builds toward a state where your team can decide most cases on its own and escalate only the riskier ones, using templates you can copy and adapt.

Why you need a procurement policy now

There are two reasons a written procurement policy pays off: licenses move, and the rules that govern software supply chains are consolidating internationally.

Licenses change without notice

Over the past few years, widely used OSS projects have re-licensed one after another. The headline cases (dates and changes follow the official sources at the end of this article; always confirm the current status):

Two clarifications. First, MinIO is not a re-license: the license text stays AGPLv3, but the project wound down development (an "end-of-development" case). It still belongs in your policy's watch scope, because running unmaintained software is its own risk. Second, none of these were "bad" software — the better a project is, the more incentive its vendor has to change the license to protect its business. The lesson: a one-time check at adoption is not enough; you have to watch for changes for as long as you keep using it.

The regulatory picture is shifting (and you should read it carefully)

The second reason is that managing your software composition — SBOM◆, vulnerability handling, license compliance — is increasingly something regulators expect. A procurement policy is where you operationalize that. Three movements to know, with their current status (this area is moving; verify before you cite it):

• United States — from mandate to risk-based. Executive Order 14028 (signed May 12, 2021) and the NTIA "Minimum Elements for an SBOM" (July 2021) pushed SBOM into federal procurement. But the binding self-attestation requirements that followed were rolled back: OMB M-26-05 (Jan 23, 2026) rescinded the earlier mandate memos (M-22-18 and M-23-16) and moved to a risk-based, agency-discretion approach — agencies "may also choose" to require an SBOM on request. So in the US, SBOM is no longer a blanket federal mandate — do not write "required by EO 14028" in your policy. Separately, CISA published a 2025 Minimum Elements for an SBOM as draft, voluntary guidance for public comment (comment period closed Oct 3, 2025; not finalized at the time of writing), expanding the recommended elements. Treat it as a direction of travel, not settled law.
• European Union — a real legal obligation. The Cyber Resilience Act (Regulation (EU) 2024/2847; in force Dec 10, 2024, with the main obligations applying from Dec 11, 2027, vulnerability-reporting duties from Sept 11, 2026, and the conformity-assessment provisions from June 11, 2026) makes SBOM production and vulnerability handling a legal duty (the duty is to produce and maintain an SBOM and provide it to market-surveillance authorities on request — not to publish it to every user). The catch is who it binds: the addressee is the manufacturer of a product with digital elements placed on the EU market, so simply using a SaaS or a model is generally not directly regulated. But if your own product ships software, or relies on remote data processing that is necessary for the product's function, you can fall in scope — confirm individually when you sell into the EU.
• International standards — the backbone. ISO/IEC 5230 (OpenChain) for OSS license-compliance management, and SPDX◆ (ISO/IEC 5962) / CycloneDX for SBOM formats, are what let you describe your internal policy as a management system rather than an ad-hoc checklist.

What these share is a direction: a mature OSS policy should contain decision criteria, an intake process, an SBOM, and ongoing monitoring. The rest of this article builds exactly those, as templates you can paste in.

A copy-paste allow / caution / deny list

The heart of the policy is a rule that sorts software, SaaS, and AI models into three tiers. With this, developers can decide most cases themselves and escalate only the ones that need it.

The "caution" tier is where the judgment lives

The tier that actually needs thought is 🟡 caution. Source-available licenses such as BSL◆, SSPL◆, and FSL are routinely misread as "the source is public, so it's free to use." In reality each restricts you in its own way — and the differences matter, so read the actual LICENSE rather than relying on the family name:

• BSL forbids production use beyond a vendor-defined Additional Use Grant, and converts to an open license on a Change Date (often four years).
• SSPL is not a simple "no competing SaaS" ban — it is a strong copyleft duty: if you offer the software as a service, you must release the entire service stack's source under the SSPL.
• FSL forbids a Competing Use (a product or service that substitutes for or competes with the vendor's), then converts to Apache 2.0 / MIT after two years.

The practical pattern is the same: internal use is usually fine, but the moment you ship it in a customer-facing product or service, you can trigger the restriction or an open-sourcing obligation. That is why these belong in "caution" (confirm the use and read the license before you ship), not in "deny."

A few worked examples:

• MIT, no scale condition → 🟢 use it as-is.
• Llama-family model (Llama 3.1 Community License §2 requires a separate Meta license above 700M monthly active users) → 🟡 (a mid-sized company won't cross that, so effectively 🟢 — but re-evaluate if you OEM it to others).
• A Non-Production-licensed AI model put into production → 🔴 likely a breach (evaluation only in most cases; even "evaluation" can carry per-license conditions, and use inside a for-profit org may need review — if you go to production, consider swapping to a clearly commercial-use license such as an Apache/MIT-class model).

Hand out the shape, fill in the contents yourself

The important move here is not to copy another company's allow list verbatim. Where you draw the allow/caution/deny lines depends on whether you "only build internal tools" or "resell a customer-facing SaaS." So this article gives you the decision criteria (the three tiers above) and a blank-filled shape, and leaves the specific software names for you to inventory and slot in. Classifying just "the 20–30 main tools you use today" into three tiers is already enough to get the policy running.

An intake form you can paste into GitHub

Decision criteria are not enough on their own: when something lands in 🟡 caution or 🔴 deny, you still need to know who confirms what, and who approves. Here is an intake form you can drop in as a GitHub Issue template — put it in .github/ISSUE_TEMPLATE/, or just paste it when someone files a request.

## What you want to procure
- Name / version:
- Official LICENSE / model-card URL:

## Intended use
- [ ] Internal tool (employees only)
- [ ] Customer-facing SaaS / distributed product
- [ ] PoC / evaluation only
- [ ] Learning / internal study only

## License tier (per the policy's allow/caution/deny list)
- [ ] 🟢 On the allow list → FYI only (no request needed)
- [ ] 🟡 Caution list → conditions that apply:
  - [ ] Scale condition (headcount / revenue / MAU)
  - [ ] Geographic restriction (e.g. EU)
  - [ ] Use restriction (no SaaS resale, etc.)
  - [ ] Copyleft (GPL / AGPL)
- [ ] 🔴 Deny list → PoC / evaluation only (no production use)

## Handling the conditions
- Paid plan / price if over the scale limit:
- Alternative if geo-restricted:
- AGPL handling:
  - Modified? :
  - Offered to users over a network (the crux of AGPL)? :
  - How source is provided (repo URL / bundled with distribution):

## SBOM
- Generator (Syft / Trivy / OSV-Scanner, etc.):
- License detection result:

## Approvals
- [ ] Dev lead
- [ ] Security
- [ ] Legal (required only for 🟡 caution / 🔴 deny)

## URLs checked (date retrieved: YYYY-MM-DD)
- Official LICENSE:
- Terms of service / use policy:
- Pricing page:

The point of this form is to force the flow with checkboxes: 🟢 allow means zero paperwork; only 🟡 caution and 🔴 deny pull in legal. "Run everything past legal" never survives contact with reality — filter with the decision criteria first, then bring in people.

It also helps to make a detection report an Issue, so the monitoring later in this article has somewhere to land.

## What changed
- Name / old license → new license / change date / official announcement URL:

## Blast radius
- Internal use: yes / no
- Customer-facing: yes / no
- Existing releases: can continue / must replace

## Response
- [ ] Pin the old version
- [ ] Migrate to a fork (OpenTofu / Valkey / OpenSearch, etc.)
- [ ] Buy a commercial license
- [ ] Swap the component out

A policy boilerplate and approval flow — no OSPO needed

Once you have decision criteria and an intake form, the last piece is when, who, and how to run them — a one-page guideline. Here is a minimal common rule that works even for a mid-sized company without an OSPO (an Open Source Program Office) or a dedicated legal team.

[Internal OSS/SaaS Usage Guideline — the minimal five]
□ 1. Before adopting, classify it on the policy's allow / caution / deny list.
□ 2. If it lands in 🟡 caution or 🔴 deny, file the Issue template to request legal review.
□ 3. Wire an SBOM tool (Syft / Trivy / OSV-Scanner) into CI and inventory everything quarterly.
□ 4. For licenses that need a NOTICE (e.g. Apache 2.0), bundle the NOTICE with what you distribute.
□ 5. An AI model's license is separate from the library that calls it. Check the model card on its own.

What changes by use case

The same software needs different checks depending on how you use it:

• Internal tool (not distributed to customers): 🟢 allow is free. 🟡 caution usually just means confirming the scale condition. 🔴 deny is evaluation only.
• Customer-facing SaaS / distributed product: for 🟡 caution, confirm every condition (geography, use, copyleft) — watch AGPL◆, "no SaaS resale" terms, and AI-model terms-of-use inheritance in particular. 🔴 deny is off-limits (switch to a commercial API or commercial license).
• Internal research / PoC only: research scope can be permissive, but if there is any chance it goes to production, record the license-swap plan in the Issue.

The flow and who owns what

Strung end to end, from "considering adoption" to "monitoring," the flow looks like this:

Considering adoption → ① on the allow list, adopt immediately → ② caution, file an Issue for legal review (adopt if conditions clear, otherwise find an alternative) → ③ deny, PoC only → after adoption, wire an SBOM into CI → inventory quarterly → on detecting a license change, issue a detection report.

Split the roles like this:

The quarterly inventory can paste in this checklist as-is:

[Quarterly inventory checklist]
□ Regenerated the full SBOM (Syft + Trivy, etc.)
□ Every newly adopted tool / model is classified as allow / caution / deny
□ Checked existing software for license changes (via the monitoring in the next section)
□ Checked whether any scale condition (headcount / MAU / revenue) has been crossed
□ Checked that legal-review deadlines for caution-list items haven't lapsed
□ Checked that no deny-list software is still sitting in production as a "PoC"

A re-licensing watch clause — catch the next HashiCorp or Redis

This is the part most articles skip. There is no shortage of write-ups explaining a re-license after the fact, but almost none say how to detect a change and what the policy makes you do when you find one. Since, as we saw at the top, re-licensing will keep happening, write the monitoring into the policy itself.

A watch list (recently changed = check quarterly)

Start by putting "projects that have already changed" on watch — a vendor that changed once is comparatively more likely to change again.

Watch channels

The principle is "get official primary sources delivered to you automatically":

• GitHub Watch: watch each repo and enable the releases category (a useful signal for a re-license, though a LICENSE change won't always appear in release notes). Note that Watch is repository-level — there is no native way to watch a single LICENSE file; track LICENSE changes themselves with the API / scheduled job below (hashing the file).
• Official RSS / blogs: subscribe to vendor blogs (Redis, Elastic, HashiCorp, Sentry…).
• OSI◆ / industry news: the opensource.org newsletter, LWN.net, the Hacker News "licensing" tag.
• deps.dev: license data for your dependencies (from Google); combined with periodic SBOM scans, it makes license shifts deep in your dependency tree easier to notice.

Automate the detection (an implementation of the clause)

Reviewing every repo by hand each quarter is not realistic. Add the minimal automation: periodically compare the hash of each LICENSE file, and open an Issue if it changed. One GitHub repository is enough to run it.

Which files go where:

• .github/workflows/license-watch.yml … the workflow below. Save it at exactly this path and name so GitHub Actions picks it up automatically.
• watched-repos.txt … the watch list, at the repo root. One owner/repo per line (e.g. redis/redis, hashicorp/terraform).

# .github/workflows/license-watch.yml
# Check the LICENSE hash of the watched repos monthly,
# and auto-create an Issue if anything changed since last time.
name: License Change Detection

on:
  schedule:
    - cron: "0 0 1 * *" # 00:00 UTC on the 1st of each month
  workflow_dispatch: # also allow manual "Run workflow"

permissions:
  contents: write # to write the comparison snapshot back to the repo
  issues: write # to open an Issue on a detected change

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - name: Compare LICENSE hashes
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} # injected automatically; no setup
        run: |
          # Collect the LICENSE SHA of each "owner/repo" in watched-repos.txt
          : > license-shas.txt
          while read -r repo; do
            [ -z "$repo" ] && continue
            sha=$(curl -s -H "Authorization: Bearer $GH_TOKEN" \
              "https://api.github.com/repos/$repo/contents/LICENSE" | jq -r '.sha')
            echo "$repo $sha" >> license-shas.txt
          done < watched-repos.txt

          # Compare with last run (license-shas.prev); open an Issue if they differ
          if [ -f license-shas.prev ] && ! diff -q license-shas.prev license-shas.txt; then
            gh issue create --title "License change detected" \
              --body "$(diff license-shas.prev license-shas.txt || true)"
          fi

          # Save this run's result for next time (commit it back to the repo)
          mv license-shas.txt license-shas.prev
          git config user.name  "license-watch-bot"
          git config user.email "[email protected]"
          git add license-shas.prev
          git commit -m "chore: update license hash snapshot" || echo "no changes"
          git push

Usage notes:

• gh (GitHub CLI) and jq are preinstalled on GitHub's ubuntu-latest runner, so no extra install is needed.
• The first run has nothing to compare against (license-shas.prev is absent), so it only saves the baseline snapshot; from the second run on, any repo whose hash changed gets an Issue.
• Repos without a file literally named LICENSE (e.g. LICENSE.md or COPYING) return 404 from the API — adjust the filename in the URL to match.

Written as a single clause for the policy, it reads:

Watch clause (example): For the OSS we use that is listed in the "watch list" schedule, we confirm the current license each quarter. On detecting a license change, we issue a detection report (Issue) and decide the blast-radius assessment and response within two weeks.

This one sentence, plus the decision criteria, intake form, and inventory from the earlier sections, turns "adopt and forget" into a policy that keeps protecting you for as long as you keep using the software.

Wrapping up

An internal OSS/SaaS procurement policy is not a grand document you write from scratch. The realistic move is to copy a minimal set of decision / intake / monitoring templates and run them while adapting to your own context. Start from this checklist:

[Procurement policy — adoption checklist]
□ Classified the 20–30 main tools you use today as allow / caution / deny
□ Set up the intake Issue template (🟢 = no paperwork, only 🟡🔴 reach legal)
□ Added the license-change watch list and watch clause to the policy
□ Wired an SBOM tool into CI and scheduled the quarterly inventory
□ Had your legal / OSS-compliance owner adapt the templates to your business

If "a formal policy is overkill" for you as an individual developer or small team, just these three points will prevent most re-licensing accidents:

[Minimal set for individuals / small teams]
□ Before adopting, check the official LICENSE and its SPDX identifier — one line.
□ Remember just this: BSL / SSPL / FSL / non-commercial = "be careful for resale and production."
□ GitHub-Watch the 5–10 OSS projects you rely on, so you notice a license change.

For how to read individual licenses, see Reading OSS licenses; for building a bill of materials, see SBOM tools; for the SaaS terms-of-service side, see Reading AI service terms.

References

• HashiCorp license change (Aug 2023, BSL 1.1): https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license
• Redis license change (Mar 2024, RSAL/SSPL): https://redis.io/blog/redis-adopts-dual-source-available-licensing/
• Redis adds AGPLv3 (May 1, 2025, from Redis 8): https://redis.io/blog/agplv3/
• Elastic license change (Jan 2021, SSPL/ELv2): https://www.elastic.co/blog/licensing-change
• Elastic adds AGPL (Aug 2024): https://www.elastic.co/blog/elasticsearch-is-open-source-again
• Sentry adopts the Functional Source License (FSL) (Nov 17, 2023): https://blog.sentry.io/introducing-the-functional-source-license-freedom-without-free-riding/
• MinIO (GitHub repo / archive notice): https://github.com/minio/minio
• MinIO maintenance-mode commit 27742d4 (Dec 3, 2025): https://github.com/minio/minio/commit/27742d4
• Executive Order 14028 (May 12, 2021): https://bidenwhitehouse.archives.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
• NTIA "The Minimum Elements for an SBOM" (July 12, 2021): https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom (PDF: https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf)
• OMB M-26-05 (Jan 2026, risk-based approach): https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf
• CISA "2025 Minimum Elements for an SBOM" (Aug 2025, draft for public comment, docket CISA-2025-0007): https://www.federalregister.gov/documents/2025/08/22/2025-16147/request-for-comment-on-2025-minimum-elements-for-a-software-bill-of-materials
• EU Cyber Resilience Act (Regulation (EU) 2024/2847): https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
• OpenChain / ISO/IEC 5230: https://openchainproject.org/license-compliance
• Server Side Public License (SSPL), §13: https://www.mongodb.com/legal/licensing/server-side-public-license
• Business Source License 1.1 (BSL): https://mariadb.com/bsl11/
• Functional Source License (FSL-1.1, SPDX text): https://spdx.github.io/license-list-data/FSL-1.1-ALv2.html
• Redis licenses page (RSALv2 / SSPLv1 / AGPLv3 tri-license, Redis 8+): https://redis.io/legal/licenses/
• Llama 3.1 Community License §2 (Additional Commercial Terms, 700M MAU): https://github.com/meta-llama/llama-models/blob/main/models/llama3_1/LICENSE
• GitHub Docs "Configuring notifications" (Watch is repository-level): https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications