The Open Source Initiative Explained: OSD, Licence Approval and OSAID

The Open Source Initiative (OSI) is a California public benefit corporation with 501(c)(3) status, founded in February 1998, that maintains the Open Source Definition (OSD): ten criteria a software licence must meet before it can be called open source. It runs a public, consensus based review that decides which licences are "OSI Approved", and on 28 October 2024 it published the Open Source AI Definition (OSAID) 1.0, which extends the same idea to machine learning systems.

The OSI list is the reference legal teams, procurement policies and SBOM tools use when they call a dependency "open source", and the gap between "the source is public" and "the licence meets the OSD" is where licence surprises come from. This guide sits next to our posts on open source foundation governance models, the Apache Software Foundation's licence categories and whether a fine-tuned model inherits its base model's licence, and goes one level deeper on the OSI itself. Every rule, number and date below comes from the primary sources linked at the end, read on 24 October 2026.

Key takeaways

• The OSI was founded in late February 1998 by Eric Raymond and Bruce Perens, weeks after the term "open source" was coined in Palo Alto on 3 February 1998. It gained 501(c)(3) recognition in 2003.
• A twelve seat board is the ultimate authority: four seats elected by individual members, four by affiliate organisations and four appointed by the board. Election results are advisory, and the bylaws say the corporation has no statutory members.
• The Open Source Definition has ten clauses, from free redistribution to technology neutrality. It is version 1.9, last modified on 22 March 2007, and was derived from the Debian Free Software Guidelines, which Debian ratified on 5 July 1997.
• Licence approval is a public, consensus process on the license-review mailing list, normally decided about 60 days after submission by a board vote on the License Committee's recommendation.
• The OSI's licence API returned 126 entries on 24 October 2026, including 5 voluntarily retired licences. The most recent approvals were the NIST Software License (20 February 2026), the curl licence (17 April 2026) and two Python licences (29 June 2026).
• OSAID 1.0 requires detailed Data Information, the complete training and inference Code under OSI approved licences, and the Parameters under OSI approved terms. It does not require release of all training data, which is the main point of dispute.
• Source available licences such as the Business Source License and the Server Side Public License are not OSI approved. A relicense applies from a specific version onward, which is exactly what an SBOM needs to capture.
• The SPDX License List 3.29.0 (16 September 2026) holds 740 licences and flags 154 identifiers as OSI approved, more than the OSI count because SPDX splits the GPL family into "only" and "or later" forms and keeps deprecated ones.

What is the Open Source Initiative?

The OSI describes itself on its about page as the "steward of the Open Source Definition" and as a non-profit "with global scope formed to educate about and advocate for" open source. In practice it does three jobs that touch every software team, whether or not they notice:

1. It maintains the Open Source Definition, acting, in the about page's words, "as a standards body".
2. It approves licences. The "OSI Approved License" mark is a registered trademark and the label legal reviews and procurement rules rely on.
3. It advocates and educates, including policy work; its about page lists an EU Transparency Register number.

Where did the term "open source" come from?

The OSI history page gives a precise origin. The label was created at a strategy session on 3 February 1998 in Palo Alto, shortly after Netscape announced it would release its browser source code. The people in the room wanted a single, business friendly label that was distinct from the "philosophically and politically focused" term free software. The term itself was suggested by Christine Peterson. Two attendees, Eric Raymond and Michael Tiemann, later served as OSI presidents.

The organisation followed within weeks. The history page says Raymond and Bruce Perens jointly founded the OSI in late February 1998, with Raymond as first president and Perens as vice president, and that the first board accepted a mission focused on "explaining and protecting" the open source label. One of its first tasks was to draft the OSD and start a list of approved licences.

Timeline

How is the OSI governed?

The board of directors is "the ultimate authority responsible for the organization". It oversees the organisation, supports the executive director and staff, approves the budget and sets strategic direction. Directors are volunteers.

Board seats

That gives twelve seats. The board page we read listed ten sitting directors, with officer roles including chair, vice chair, secretary, treasurer and a Chair of the License Committee. The bylaws allow between 5 and 21 directors, with the exact number fixed by board resolution, and set a quorum of four directors for most business.

How elections work

The elections page says elections run online by secret ballot using the Scottish Single Transferable Vote method, and "generally begin in March". Vacancies are filled at the next regular election for a full new term, so a seat can stay empty for up to a year.

The most important detail is that elections are advisory. The board page and the elections page both say the board makes the formal appointments "based on the community's votes", and the elections page adds that community polls "have always been advisory in nature". This lines up with the bylaws, whose Article IV reads: "This corporation shall have no members." In California nonprofit law, statutory members hold legal voting rights; the OSI's individual and affiliate members are members of a programme, not members of the corporation, so the board keeps the final legal decision.

A term limit discrepancy worth knowing about

The OSI's own pages do not agree on the term limit. The board page says directors who have served "five or more years" may not run until they have been off the board for a year. The elections page says no director who has served "six consecutive years" is eligible for re-election until a year has passed, and the bylaws say the same six year rule, with an exception for an employee serving on the board. The elections page also states that the bylaws take precedence over any conflicting election document, so the six year rule in the bylaws is the binding one.

The License Committee

Licence decisions run through a License Committee, whose chair sits on the board. It judges whether the public review has reached consensus and recommends approval or rejection; the board votes. Board members and staff may join reviews in a personal capacity, using a non OSI email address.

What does the Open Source Definition say, clause by clause?

The OSD opens with a line that sets the tone: open source "doesn't just mean access to the source code". The distribution terms must meet ten criteria. The table below summarises each clause in plain words and shows the kind of licence term it rules out.

Clauses that cause the most arguments

Clause 2 and the "preferred form". The OSD says the source code "must be the preferred form in which a programmer would modify the program". That phrase matters far beyond software: the OSAID borrows it directly, and asks what the preferred form for modifying a trained model is. For software, the clause excludes deliberately obfuscated code and intermediate forms such as preprocessor or translator output.

Clause 4 and patch files. A compromise inherited from the DFSG: an author may insist modified versions ship as original source plus patches, or under a different name or version, as long as software built from modified source can still be distributed.

Clauses 5 and 6 and restrictions on users. These two clauses are why licences that ban commercial use, restrict particular industries or add ethical use conditions are not open source under the OSD, however well intentioned. The example in the text is pointed: a licence may not stop the software being used "in a business, or from being used for genetic research".

Clause 9 and aggregation. A licence can be strongly copyleft about the program and its derivatives, which is how the GPL family passes, but cannot reach independent programs that merely ship on the same medium.

Clause 10 and click-wrap. The OSI history page says clause 10 was added in 2004 to deal with click-wrap licensing, where acceptance depends on a specific interface. It is the only clause added since 1998; the history page says the OSD has otherwise had "only minor wording clarifications".

Where the OSD came from: the Debian Free Software Guidelines

The OSD page states that it "was originally derived from the Debian Free Software Guidelines". The Debian Social Contract page fills in the detail: Bruce Perens drafted the document, Debian developers refined it "during a month-long e-mail conference in June 1997", and it was accepted as Debian policy. Version 1.0 was ratified on 5 July 1997, version 1.1 on 26 April 2004 and version 1.2 on 1 October 2022. The same page notes that Perens "later removed the Debian-specific references" from the DFSG to create the OSD.

The two documents still line up clause for clause. The DFSG speaks of "free software" and ends with an "Example Licenses" section naming the GPL, BSD and Artistic licences; the OSD drops the Debian references and adds clause 10. Debian still applies the DFSG, not the OSD, to its own archive.

How does licence approval work?

The License Review Process page, last modified on 13 March 2024, sets out the stated purpose: make sure approved licences meet the OSD and "provide software freedom", discourage duplicate and poorly written licences, and give a thorough, transparent and timely review, "e.g. within 60 days".

The steps

The page is explicit that this is "a consensus process" in which no single person, a board member included, can approve, reject or require a change.

Legacy licences and new licences

The process treats two kinds of submission differently.

A legacy licence has been used for at least five years by more than twenty projects maintained by unrelated entities. Anyone may submit one, affirming that it meets the OSD, "including specifically affirming it meets OSD 3, 5, 6 and 9", naming projects that use it, the steward if known and any SPDX identifier. It is approved or not as written.

A new licence is anything else. The submitter, ideally the steward and always a natural person, must also describe the gap it fills, compare it with the most similar approved licences and describe any legal review. Non-English licences need a certified English translation.

The 2026 approvals of the NIST Software License, the curl licence and Python License 2.0.1 are all tagged "legacy" in the API: long used, formally reviewed only recently.

The standards a new licence must meet

Beyond the OSD itself, the review page lists standards for new licences:

• It must be reusable: any licensor can use it without changing terms or getting a different result.
• It must not structurally put the licensor in a better position than any licensee.
• Any ambiguity must not materially affect how the licence applies, and the text must be grammatically clear.
• Every possible application of the licence must meet the OSD, not just the common case.
• It must be possible to comply with on submission. The page names the Server Side Public License (SSPL) as an example, saying that given the scope of its copyleft, it is not a licence "anyone currently would be able to comply with".
• It must fill a gap that existing licences do not.
• It must be a complete licence. The page says overlays "like Commons Clause" and exceptions "like ClassPath" will not be approved in isolation from the licence they modify.

Reviewers may also reject a licence that fails no specific clause if they agree it "does not ensure software freedom".

How many licences are OSI approved?

The OSI launched a public licence API on 19 June 2025, describing it as "the official source of truth for OSI license data". Each record carries the name, SPDX identifier, submission and approval dates, steward and a link to the board minutes.

When we queried it on 24 October 2026, the API returned 126 licence entries. The API tags each licence with a category (one entry carried no tag, so the counts below add up to 125):

The twelve "Popular / strong community" licences are Apache-2.0, BSD-2-Clause, BSD-3-Clause, CDDL-1.0, EPL-2.0, GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0, MIT and MPL-2.0. Four details matter if you build a check on this data:

1. Retired licences are still listed. The five entries tagged "voluntarily retired" remain in the API response, so software released under them still carries an approved licence.
2. Some older entries have no approval date, including MIT, Apache-2.0 and GPL-2.0.
3. The OSI uses some older SPDX identifiers. The API lists "GPL-2.0", "GPL-3.0" and "LGPL-2.1", which SPDX has deprecated in favour of "-only" and "-or-later" forms. One entry uses "NOKIA" where SPDX uses "Nokia". The SPDX specification says identifiers should be matched case insensitively, so a check must normalise both.
4. Three entries have no SPDX identifier at all: the Los Alamos National Labs BSD-3 variant, the MITRE Collaborative Virtual Workspace License and the Jabber Open Source License.

Who may say "OSI Approved"?

The OSI brand and trademark guidelines say "OSI Approved Open Source License" is a registered trademark, and the keyhole logo is registered in the US and several other countries. Uses of the approved licence mark must promote approved licences, which is why calling an unreviewed licence "OSI approved" is a trademark problem as well as a definitional one.

What is the Open Source AI Definition 1.0?

The OSAID is the OSI's answer to a question the OSD never had to face: what is the "preferred form" for modifying a system whose behaviour comes from training data as much as from code? The OSI press release dated 28 October 2024 says version 1.0 was announced that day at All Things Open 2024 in Raleigh, after "a year-long, global, community design process". The OSAID page still showed version 1.0 as the current stable version when we read it.

The four freedoms, applied to AI

The definition says an Open Source AI is a system made available under terms that grant the freedom to:

• Use the system for any purpose without asking permission.
• Study how it works and inspect its components.
• Modify it for any purpose, including to change its output.
• Share it, with or without modifications, for any purpose.

A footnote says these freedoms are derived from the Free Software Definition. They apply to a whole system and to its parts, such as a model or its weights.

What the "preferred form to make modifications" must include

The definition allows copyleft style conditions: the terms "may contain conditions that require any modified version to be released under the same terms". It also says that "Open Source models" and "Open Source weights" must include the data information and code used to produce them, so weights alone cannot be open source under the OSAID.

Why "terms" for weights but "licences" for code?

The FAQ explains that the OSI takes no position on whether parameters can be copyrighted, so "terms" avoids implying a copyright licence is the only legal tool. It still requires "an explicit assertion" that the parameters are freely available to all.

The four kinds of training data

The FAQ sorts training data into four classes, and that is where most of the practical argument sits:

The FAQ argues that requiring all data would confine Open Source AI to "a niche of AI trainable only on open data" and shut it out of fields such as medicine.

Open weights are not Open Source AI

The OSI's open weights page draws the line: open weights share the final parameters, sometimes under an OSI approved licence, but not the training code or full data details. Its table marks training code "Not Shared" for open weights and "Fully Shared" for Open Source AI. Our post on open weight model families walks through what that means for the formats and licences you will actually meet.

The checklist, and its stated limits

The OSI's checklist, built on the Model Openness Framework paper of 21 March 2024, lists required components: data descriptions, code for preprocessing, training, validation, inference and supporting libraries, and the model architecture and parameters. Model cards and evaluation data are optional. It says it "is not an operating manual" and appears "tightly coupled to generative AI".

Why is the OSAID disputed?

Three disagreements run through the debate, and the OSI's own documents acknowledge each of them.

Training data. This is the main one. The OSAID FAQ says some people believe "full, unfettered access to all training data" is essential for reproducibility, transparency and security. The OSI chose Data Information instead, comparing it to the way the OSD enables reproducible builds without mandating them. The Free Software Foundation took a different line. Its announcement of 22 October 2024, six days before OSAID 1.0, said it was drafting criteria for free machine learning applications that would require "the raw training data and associated scripts" to grant users the four freedoms.

The legal status of weights. Whether weights are copyrightable at all is unsettled; the definition says this "will become clearer over time".

Practical evaluation. With the checklist describing itself as a learning tool, judging whether a given model meets the OSAID still involves judgement.

For a team choosing models, the practical takeaway is narrower than the debate. A model card that says "open source" may mean OSAID compliant, open weights under an OSI approved licence, or open weights under a custom licence with use restrictions. Only the last one carries terms that clauses 5 and 6 of the OSD would reject. Read the licence file, not the marketing.

What are source available licences, and why do licence changes matter for dependency risk?

"Source available" describes software whose source you can read, and often build, under a licence that fails one or more OSD clauses. The usual failures are clause 6 (restrictions on a field of use, such as offering the software as a hosted service), clause 1 (limits on redistribution or sale) and clause 3 (limits on derived works).

The main patterns

Delayed open source. The Business Source License 1.1 text, published by its author, grants the right to copy, modify, create derivative works, redistribute "and make non-production use" of the work, with an optional Additional Use Grant that can allow limited production use. On the Change Date, or the fourth anniversary of the first public release of that version, whichever is first, the work converts to a Change License that must be the GPL 2.0 or later or a GPL compatible licence. The text says outright that it "is not an Open Source license". Because the clock runs per version, each release of a BSL project has its own conversion date.

Service restrictions. The SSPL extends copyleft to the software used to offer a program as a service. The OSI review page cites it as an example of a licence nobody could currently comply with. Other vendor written licences forbid offering the software as a managed service outright.

Overlays. The Commons Clause is added on top of a permissive licence to forbid selling the software. The OSI review page says overlays like it will not be approved, and the FSF licence list calls it "a nonfree license" because it forbids selling copies and running the program as part of a commercial service.

SPDX marks BUSL-1.1 and SSPL-1.0 as not OSI approved, but does give them identifiers, so an SBOM can record them precisely.

A dated example: Redis

Redis's own announcements give a clean example of a licence change and a partial reversal.

• On 20 March 2024, Redis announced that from Redis 7.4 the core would be dual licensed under the Redis Source Available License v2 and SSPLv1 instead of the three clause BSD licence, stating that "neither RSALv2 nor SSPL is an OSI-approved license". Its modules had moved to the same dual licence on 15 November 2022.
• On 1 May 2025, Redis added the OSI approved AGPLv3 as an option starting with Redis 8, saying the 2024 change had hurt its community relationship and noting that large cloud providers now maintain their own fork.

The lesson is not about any one company. The licence attached to a project name changes over time, the change is tied to specific versions, and the response (a fork, a new foundation, a new licence option) can split one dependency into several with different terms and maintainers.

Why this is a supply chain risk, not just a legal one

That final row links back to the OSAID debate. Our post on whether a fine-tuned model inherits its base model's licence covers the chain of terms through adapters, merges and quantised copies.

How does the OSI relate to SPDX and the Free Software Foundation?

SPDX: identifiers, not judgements

The SPDX License List is part of the SPDX specification, a Linux Foundation project. It gives "commonly found licenses and exceptions" a short identifier, full name, text and permanent URL. SPDX does not decide what is open source; it records two outside judgements as flags, "OSI Approved?" and "FSF Free/Libre?".

Release 3.29.0, dated 16 September 2026, held 740 licences in its machine readable data. Of those, 154 carried the OSI approved flag, 13 of them deprecated identifiers, leaving 141 current ones; 127 carried the FSF free flag; and 72 carried both. SPDX's count of OSI approved identifiers is higher than the OSI's 126 entries mainly because SPDX gives the GPL family separate "-only" and "-or-later" identifiers and keeps the older ones as deprecated aliases.

The SPDX license expression syntax, in Annex D of the specification, is how an SBOM states licensing that one identifier cannot:

The specification says operators are case sensitive while identifiers should be matched case insensitively, so "MIT", "Mit" and "mIt" are the same licence. SBOMs also use NOASSERTION when no determination was made and NONE when there is no licence, and those two values deserve as much attention as any copyleft licence.

The Free Software Foundation: same freedoms, different emphasis

The FSF's Free Software Definition lists four essential freedoms, numbered from zero: to run the program as you wish for any purpose (freedom 0), to study and change it (freedom 1), to redistribute copies (freedom 2) and to distribute modified versions (freedom 3). The definition says access to the source code is a precondition for freedom 1.

The FSF essay "Open Source Misses the Point" explains how the two movements see each other. It says the terms describe "almost the same category of software" but rest on different values: free software is an ethical position about users' freedom, while open source, in the essay's words, "values mainly practical advantage". The essay also says that nearly all open source software is free software.

In licence terms the overlap is large but not complete, and the SPDX flags show where they part:

• FSF free but not OSI approved: CC0-1.0, CC-BY-4.0 and WTFPL carry the FSF flag and not the OSI flag. In most cases this is because nobody submitted them for OSI review or the OSI review did not conclude, not because the OSI judged them unfree.
• OSI approved but considered nonfree by the FSF: the FSF licence list says the NASA Open Source Agreement 1.3 "is not a free software license" because it requires changes to be the contributor's original creation. NASA-1.3 is on the OSI list.
• Missing flags are not verdicts. Dozens of OSI approved identifiers, such as MIT-0 and BlueOak-1.0.0, have no FSF flag, usually because the FSF list does not cover them.

How do OSI approved, FSF free, source available and open weight licences compare?

Step by step: check every dependency's licence against the OSI list

This walkthrough uses a Node.js project because npm can produce an SBOM with no extra tools, but steps 2 to 6 work on any SPDX 2.3 or CycloneDX JSON SBOM, whatever generated it.

Step 1. Generate an SBOM

The npm documentation says npm sbom writes an SBOM for the current project in SPDX or CycloneDX format, with --sbom-format choosing which. Omit development dependencies if you only care about what ships.

# From the project root, after npm ci
npm sbom --sbom-format spdx --omit dev > sbom.spdx.json

# Or CycloneDX, if that is what the rest of your tooling reads
npm sbom --sbom-format cyclonedx --omit dev > sbom.cdx.json

# Quick look at what licences were declared
jq -r '.packages[] | [.name, .versionInfo, (.licenseDeclared // "NOASSERTION")] | @tsv' sbom.spdx.json | head

In the SPDX output, each package carries a licenseDeclared field, as in the npm documentation's example where lodash 4.17.21 declares MIT.

Step 2. Download the OSI list and the SPDX list

# The OSI's own list, from its public API (one JSON array)
curl -fsSL https://opensource.org/api/license -o osi-licenses.json
jq length osi-licenses.json          # 126 on 24 October 2026

# The SPDX list, with its OSI and FSF flags and deprecation markers
curl -fsSL https://spdx.org/licenses/licenses.json -o spdx-licenses.json
jq -r '.licenseListVersion' spdx-licenses.json   # 3.29.0 on 24 October 2026

Commit both files to the repository, or to a shared policy repository, and refresh them on a schedule. A licence gate that downloads its reference list on every build fails when the site is slow, and gives different answers on different days without a reviewable change.

Step 3. Normalise identifiers

The OSI list uses "GPL-2.0" where current SPDX uses "GPL-2.0-only" and "GPL-2.0-or-later", and it uses "NOKIA" where SPDX uses "Nokia". Matching case insensitively and stripping the "-only", "-or-later" and "+" suffixes handles both. Note what you lose: the normalisation treats "GPL-2.0-only" and "GPL-2.0-or-later" as the same family for the purpose of the OSI check, which is right for approval status but not for compatibility analysis.

Step 4. Evaluate each licence expression

A single identifier is easy. Expressions need rules: an OR passes if any branch is approved, because you can choose that branch; an AND passes only if every part is approved; a WITH exception follows its base licence; LicenseRef-, NOASSERTION and NONE need a human. The script below implements exactly that. Save it as tools/osi-check.py.

#!/usr/bin/env python3
"""Flag SBOM components whose licence is not OSI approved.

Usage: python3 osi-check.py SBOM.json osi-licenses.json
Reads SPDX 2.3 JSON or CycloneDX JSON. Exits 1 if any component is 'no'.
"""
import json
import re
import sys

sbom = json.load(open(sys.argv[1]))
osi_raw = json.load(open(sys.argv[2]))

def norm(license_id):
    license_id = license_id.strip().rstrip("+")
    license_id = re.sub(r"-(only|or-later)$", "", license_id)
    return license_id.lower()

OSI = {norm(x["spdx_id"]) for x in osi_raw if x.get("spdx_id")}
TOKEN = re.compile(r"\(|\)|[A-Za-z0-9.+:-]+")

def components(doc):
    if doc.get("spdxVersion"):
        for p in doc.get("packages", []):
            yield p.get("name"), p.get("versionInfo"), p.get("licenseDeclared") or "NOASSERTION"
    else:
        for c in doc.get("components", []):
            parts = []
            for entry in c.get("licenses", []):
                if "expression" in entry:
                    parts.append("(" + entry["expression"] + ")")
                elif "license" in entry:
                    lic = entry["license"]
                    parts.append(lic.get("id") or "LicenseRef-" + re.sub(r"\W+", "-", lic.get("name", "unknown")))
            yield c.get("name"), c.get("version"), " AND ".join(parts) or "NOASSERTION"

def evaluate(expr):
    toks = TOKEN.findall(expr)
    pos = 0

    def peek():
        return toks[pos] if pos < len(toks) else None

    def take():
        nonlocal pos
        pos += 1
        return toks[pos - 1]

    def atom():
        t = take()
        if t == "(":
            value = disjunction()
            take()  # the closing parenthesis
            return value
        if t in ("NOASSERTION", "NONE") or "LicenseRef-" in t:
            value = "review"
        else:
            value = "yes" if norm(t) in OSI else "no"
        if peek() == "WITH":
            take()
            take()  # the exception identifier; the base licence decides
        return value

    def conjunction():
        values = [atom()]
        while peek() == "AND":
            take()
            values.append(atom())
        if "no" in values:
            return "no"
        return "review" if "review" in values else "yes"

    def disjunction():
        values = [conjunction()]
        while peek() == "OR":
            take()
            values.append(conjunction())
        if "yes" in values:
            return "yes"
        return "review" if "review" in values else "no"

    try:
        return disjunction() if toks else "review"
    except IndexError:
        return "review"  # malformed expression

failures = 0
for name, version, expr in components(sbom):
    verdict = evaluate(expr)
    if verdict != "yes":
        print(f"{verdict.upper():7} {name}@{version}  {expr}")
        failures += verdict == "no"

sys.exit(1 if failures else 0)

Run it against either SBOM:

python3 tools/osi-check.py sbom.spdx.json osi-licenses.json
# Example output shape:
# REVIEW  some-internal-lib@1.2.0  NOASSERTION
# NO      some-package@3.0.0  BUSL-1.1

Step 5. Cross-check with the SPDX flags

The OSI list is the authority on approval, but the SPDX data is a useful second opinion and catches identifiers the OSI list spells differently, such as MPL-2.0-no-copyleft-exception, which SPDX flags as OSI approved and the script above reports as "no".

# Which declared licences does SPDX flag as OSI approved, FSF free or neither?
jq -r '.packages[].licenseDeclared // "NOASSERTION"' sbom.spdx.json | sort -u > declared.txt

jq -r '.licenses[] | [.licenseId, (.isOsiApproved|tostring), (.isFsfLibre // false|tostring), (.isDeprecatedLicenseId|tostring)] | @tsv' \
  spdx-licenses.json > spdx-flags.tsv

# Show the flags for each simple identifier you actually use (exact match on the first column)
awk -F'\t' 'NR==FNR { want[$0] = 1; next } ($1 in want)' declared.txt spdx-flags.tsv

Deprecated identifiers in your own SBOM, such as a bare GPL-2.0, are worth fixing at the source: they hide whether the author meant "only" or "or later".

Step 6. Make it a CI gate

name: licence-check
on: [pull_request]
permissions:
  contents: read
jobs:
  osi:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm sbom --sbom-format spdx --omit dev > sbom.spdx.json
      # policy/osi-licenses.json is the committed copy from Step 2
      - run: python3 tools/osi-check.py sbom.spdx.json policy/osi-licenses.json
      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.spdx.json

Pin third party actions to a full commit SHA in production workflows, keep the job's token read only as above, and store the SBOM as a build artifact so you can answer "what licence did we ship in March?" later.

Step 7. Watch for licence changes between versions

Licence changes arrive through upgrades, so diff the licences of the SBOM you are about to ship against the last release:

jq -r '.packages[] | "\(.name)\t\(.licenseDeclared // "NOASSERTION")"' previous/sbom.spdx.json | sort > before.tsv
jq -r '.packages[] | "\(.name)\t\(.licenseDeclared // "NOASSERTION")"' sbom.spdx.json | sort > after.tsv
diff before.tsv after.tsv

Any line that changes licence for the same package name is a review item, even if both licences pass the OSI check. A move from MIT to AGPL-3.0 passes the check above and still changes your obligations for a hosted product.

A decision table

Common mistakes

• Treating "source on GitHub" as open source. Public code with no licence file generally gives you no written permission to copy, modify or redistribute it. The OSD is about distribution terms, not visibility.
• Reading "OSI approved" as "safe to use". Approval says the licence meets the OSD. It says nothing about the security, maintenance or provenance of a particular package.
• Ignoring the version in a licence change. A relicense applies from a version onward. Pinning the last openly licensed version is a legitimate choice, but then you own the gap for security fixes that land only in later versions.
• Matching identifiers case sensitively or literally. The OSI list uses "GPL-2.0" and "NOKIA"; your SBOM may say "GPL-2.0-or-later" and "Nokia". A naive string match reports false failures, and people learn to ignore the gate.
• Treating NOASSERTION as permissive. Missing licence data is common in real SBOMs. It means nobody checked, not that the licence is permissive.
• Assuming FSF free and OSI approved are the same list. They overlap heavily, but NASA-1.3 is OSI approved and nonfree in the FSF's view, and CC0-1.0 is FSF free without OSI approval.
• Calling an open weight model "open source". Under OSAID 1.0, weights without training code and Data Information are not Open Source AI, and many model licences also restrict fields of use.
• Approving a dependency's licence once. Licences attach to versions; re-check on every build, not once at onboarding.

FAQ

What is the Open Source Initiative?

It is a non-profit, a California public benefit corporation with 501(c)(3) status founded in 1998, that maintains the Open Source Definition, approves licences that meet it, owns the "OSI Approved" trademark and advocates for open source. Since October 2024 it also maintains the Open Source AI Definition.

What are the 10 criteria of the Open Source Definition?

Free redistribution, source code, derived works, integrity of the author's source code, no discrimination against persons or groups, no discrimination against fields of endeavour, distribution of licence, licence not specific to a product, licence must not restrict other software, and licence must be technology neutral.

How many licences has the OSI approved?

The OSI licence API returned 126 entries on 24 October 2026, including 5 voluntarily retired licences that remain listed. The SPDX License List flags 154 identifiers as OSI approved because it splits some licences into several identifiers and keeps deprecated ones.

How do I get a licence approved by the OSI?

Join the license-review mailing list and submit the plain text with the required statements, including OSD compliance (especially clauses 3, 5, 6 and 9). New licences must also explain the gap they fill. A decision normally comes about 60 days after submission.

Is the Server Side Public License open source?

No. It is not on the OSI list, SPDX marks SSPL-1.0 as not OSI approved, and the OSI review process page uses it as an example of a licence nobody could currently comply with because of the scope of its copyleft.

What is the Open Source AI Definition?

OSAID 1.0, announced on 28 October 2024, says an AI system is open source if it grants the freedoms to use, study, modify and share it, and provides the preferred form for modification: detailed Data Information, complete training and inference code under OSI approved licences, and the model parameters under OSI approved terms.

Are open weight models open source?

Not under OSAID 1.0 if only the weights are released. The OSI's open weights page says open weights lack the training code and full data transparency that Open Source AI requires. Many open weight models also carry licences with use restrictions that the OSD would not allow.

What is the difference between open source and free software?

They cover almost the same licences. The FSF frames free software as an ethical matter defined by four freedoms; the OSI frames open source around practical benefits, defined by ten criteria. A few licences, such as NASA-1.3, are OSI approved but nonfree in the FSF's view.

Does SPDX decide which licences are open source?

No. SPDX gives licences standard identifiers and records whether the OSI has approved them and whether the FSF considers them free. The decisions belong to the OSI and the FSF.

Where Safeguard fits

The OSI decides what open source means; it cannot tell you which licences are inside your own builds. That inventory question is where Safeguard works. The Safeguard CLI scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>), and the platform shows which projects contain a given component and version. Safeguard's licence compliance capability parses SPDX expressions, classifies licences as permissive, weak copyleft, strong copyleft or network copyleft, applies licence rules written as policy, and generates NOTICE and attribution files, so the decision table above can run as a policy and a gate rather than a script you maintain yourself.

The fit is partial, and worth stating plainly. Safeguard does not take part in OSI licence review, does not decide whether a model meets the OSAID, and does not give legal advice; a licence that a policy flags for review still needs a person, and often a lawyer, to decide. Licence data is only as good as the metadata packages publish, so a NOASSERTION result is a prompt to look, not an answer. You can try the CLI from safeguard.sh/download, with setup steps in the CLI documentation.

Licence and vulnerability hygiene travel together: the upgrade that brings a security fix can bring a licence change, so the fix and the licence check belong in one process.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository; the assistant reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. Lodash 4.17.21 is also the package in the npm documentation's SBOM example, so this is the upgrade you would follow with the licence check from Step 4.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard local runner on your own machine, approves it with its device code, then runs a scan from the terminal. Teams that keep source off hosted runners can build the inventory where the code already lives.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use. If someone in legal or engineering wants to ask an assistant which projects still carry a component at a version from before a licence change, this is how the assistant gets access to your Safeguard data, with the tool list set by you.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Open Source Initiative: The Open Source Definition
• Open Source Initiative: About
• Open Source Initiative: History of the OSI
• Open Source Initiative: Board of Directors
• Open Source Initiative: Board elections
• Open Source Initiative: Bylaws
• Open Source Initiative: OSI Approved Licenses
• Open Source Initiative: License Review Process
• Open Source Initiative: Licence API
• Open Source Initiative: Introducing the new API for OSI Approved Licenses (19 June 2025)
• Open Source Initiative: Brand and trademark guidelines
• Open Source Initiative: Open Source AI Definition 1.0
• Open Source Initiative: Open Source AI
• Open Source Initiative: Open Source AI Definition FAQ
• Open Source Initiative: Open Source AI checklist
• Open Source Initiative: Open Weights
• Open Source Initiative: OSAID timeline
• Open Source Initiative: OSAID 1.0 release announcement (28 October 2024)
• Debian: Social Contract and Debian Free Software Guidelines
• SPDX License List
• SPDX License List machine readable data (licenses.json)
• SPDX Specification 2.3.1, Annex D: SPDX License Expressions
• GNU Project: What is Free Software?
• GNU Project: Open Source Misses the Point
• GNU Project: Various Licenses and Comments about Them
• Free Software Foundation: FSF is working on freedom in machine learning applications (22 October 2024)
• Business Source License 1.1 text
• Redis: Redis adopts dual source-available licensing (20 March 2024)
• Redis: Redis is now available under the AGPLv3 open source license (1 May 2025)
• npm Docs: npm sbom
• CycloneDX 1.6 JSON reference

Last reviewed: 24 October 2026. OSI board membership, the approved licence list, the SPDX License List and the Open Source AI Definition all change over time; check the date and status on each linked page before relying on a specific rule or count.