Open Source License Obligations, OpenChain and Attribution With Safeguard

Safeguard handles open source license obligations by identifying the license of every component in your software, classifying what each license asks of you, enforcing your license policy at gates in CI and before release, and generating the NOTICE and attribution files a release needs. License compliance is GA in Safeguard today. It gives you the inventory and the evidence an OpenChain ISO/IEC 5230 program depends on, while the policy decisions, the program roles and the legal judgement stay with your people.

Key takeaways

• OpenChain ISO/IEC 5230 asks for a written policy, trained people, a bill of materials with identified licenses, a process for compliance artifacts, a public inquiry contact and a conformance affirmation renewed every 18 months. Tools help with the middle of that list.
• SPDX expressions decide what you owe: MIT OR Apache-2.0 is a choice, MIT AND Apache-2.0 means both apply.
• How you ship matters. GPL obligations attach to distribution; AGPL-3.0 section 13 reaches modified software users interact with over a network.
• License compliance (GA): detection from metadata, SPDX identifiers, license files, source headers and container layers, with a license-discrepancy finding when they disagree.
• Suppliers and Licenses view in ESSCM (GA): per project license summary, compliance status, obligations and attribution export.
• Policies, gates and guardrails (GA): allow, deny and review lists with Block, Warn or Notify, and a CI step that fails on a failed gate.
• SBOM generation and analysis (GA) and the Compliance and GRC suite (GA), which includes an OpenChain ISO 5230 framework.
• Autonomous remediation (GA, ships off): the License category can swap to an MIT or Apache-2.0 equivalent, drop the component, open a tracked item for legal, or choose (Smart). Every category ships set to Manual.
• Safeguard CLI (GA) writes license.json per scan; there is no CLI command yet for attribution or license policy evaluation.
• Safeguard is not a lawyer, and detection can be wrong for files without headers or with edited license text.

The problem: obligations you cannot see are obligations you cannot meet

Each open source component arrives with a license, and each license sets conditions on your right to copy, modify and distribute it. Some are small: keep the copyright notice, include the license text. Some are large: provide the corresponding source of a combined work, or offer the source of a modified server program to its users.

Without a program, three things go wrong. Nobody knows the full list: a direct dependency under MIT can pull in a transitive dependency under GPL-3.0, and a container image adds operating system packages nobody on the application team chose. The notices are missing: even the permissive Apache License 2.0 sets four conditions on redistribution in section 4, including carrying forward the contents of any NOTICE file the work includes. And the wrong license lands in the wrong product, such as a strong copyleft library inside a proprietary desktop app, which usually surfaces at a customer's procurement review or in acquisition due diligence.

The fix is not a single scan. It is a program: policy, people, inventory, review, artifacts and records. That is what the OpenChain specification describes.

What OpenChain ISO/IEC 5230 requires of a license compliance program

The OpenChain license compliance specification, version 2.1, is functionally identical to the international standard ISO/IEC 5230:2020. The OpenChain project says it was submitted to the ISO/IEC JTC 1 PAS transposition process in April 2020 and published as ISO/IEC 5230:2020 in December 2020. The specification text is free to read under CC-BY-4.0.

The specification deliberately describes the "what" and "why" of a program, not the "how". Every requirement comes with verification materials, the records you produce to show the requirement is met. Those records do not have to be public.

Two definitions shape everything else. Section 2.8 defines supplied software as software an organization distributes to third parties. Section 2.1 defines compliance artifacts as the output of the program that accompanies supplied software, and lists examples: attribution notices, source code, build and install scripts, copies of licenses, copyright notices, modification notifications, written offers, an open source bill of materials and SPDX documents.

The requirements sit in section 3:

Two details are easy to miss. Clause 3.4.1.2 asks you to archive compliance artifacts for a reasonable period after the last offer of the supplied software, or for as long as the identified licenses require, whichever is longer. And clause 3.6.1 is explicit that meeting a subset of requirements is not enough to call a program conformant.

Much of that list is people and process. A tool can produce the bill of materials in 3.3.1, the license review input for 3.1.5 and 3.3.2, and the artifacts in 3.4.1. It cannot adopt your policy, train your engineers, publish your inquiry address or sign your conformance statement.

How ISO/IEC 18974 relates

ISO/IEC 18974 is OpenChain's security assurance standard. The OpenChain project says it was built from the source material of ISO/IEC 5230, and that its governing board approved the security specification on 14 September 2022. Its introduction sets the focus: checking open source against publicly known vulnerabilities such as CVEs.

The two share a skeleton: program foundation, resourced tasks, and a bill of materials at the centre (section 3.3.1 of the security specification is titled Software Bill of Materials). Where ISO/IEC 5230 asks about license obligations, the security specification's clause 3.1.5 asks for methods to detect known vulnerabilities, follow them up, tell customers when warranted and keep checking after release.

So one SBOM per release feeds both programs. In Safeguard, the vulnerability side is vulnerability management with EPSS and KEV enrichment (GA) and reachability analysis (GA). The Safeguard framework page we read covers OpenChain ISO 5230; check the frameworks list in your workspace before planning an 18974 mapping around it.

How SPDX license identifiers and expressions work

You cannot review licenses consistently if every tool and every manifest names them differently. "Apache 2", "Apache License, Version 2.0" and "ASL 2.0" are the same license. SPDX fixes that with two things: a license list and an expression syntax.

The SPDX License List gives each license a short identifier, such as MIT, Apache-2.0, GPL-2.0-only and GPL-2.0-or-later, and records whether the FSF considers it free and whether the OSI has approved it. The list is versioned; the version we read was 3.29.0, dated 16 September 2026. The GNU family identifiers carry an explicit -only or -or-later suffix, because "GPL-2.0" alone does not tell you whether a later version may be chosen.

SPDX license expressions combine identifiers. The normative annex in SPDX 3.0.1 defines the grammar in ABNF and four operators:

• OR is a choice. LGPL-2.1-only OR MIT means you may take the software under either license. The annex says the operator is commutative.
• AND means all apply at once. LGPL-2.1-only AND MIT describes, for example, a binary built from files under different licenses, and you must comply with both.
• WITH attaches an exception or addition to a license, as in GPL-2.0-or-later WITH Bison-exception-2.2.
• + after an identifier means "this version or any later version".

Precedence matters, and it catches people. The annex sets the order as +, then WITH, then AND, then OR. So LGPL-2.1-only OR BSD-3-Clause AND MIT is a choice between LGPL-2.1-only on one side and BSD-3-Clause plus MIT on the other, because AND binds first. Parentheses change it: MIT AND (LGPL-2.1-or-later OR BSD-3-Clause) means you first choose between LGPL and BSD, then also comply with MIT.

Operators are matched case sensitively (all upper case or all lower case), while license identifiers are matched case insensitively. For licenses that are not on the list, the grammar provides user defined references of the form LicenseRef- followed by an id string, optionally prefixed with a DocumentRef- when the definition lives in another SPDX document.

Why AND and OR matter for your obligations

Read AND as "add these obligations together" and OR as "you pick, and you record what you picked". MIT OR Apache-2.0 lets you comply with MIT alone. MIT AND Apache-2.0 adds the Apache-2.0 conditions, including NOTICE handling under its section 4(d). And GPL-2.0-only WITH Classpath-exception-2.0 is not plain GPL-2.0-only, because the exception changes what the license asks of code that links to it.

Safeguard's license compliance docs say it understands the full expression syntax, including OR, AND and WITH, and that for OR it automatically picks the most permissive option that matches your policy. That is the right behaviour for a gate. It also means your records should show which option was chosen, so a reviewer later understands why a dual licensed GPL package passed a policy that denies GPL.

REUSE: put the identifier where the code is

The FSFE's REUSE specification, version 3.3 dated 14 November 2024, describes how a project should state licensing per file. It recommends comment headers, so each source file carries an SPDX-License-Identifier tag and an SPDX-FileCopyrightText line, with the full license texts stored in a LICENSES/ directory at the project root, one plain text file per license named after its SPDX identifier. For files that cannot carry comments, it offers adjacent .license files or a REUSE.toml file, and it marks the older DEP5 method as deprecated.

REUSE matters to this post for a practical reason. License scanners, Safeguard included, read source file headers as one detection signal. Code that follows REUSE is far easier to classify correctly. Code that does not, such as a vendored file with no header copied into your repository years ago, is where detection is weakest.

Permissive, weak copyleft, strong copyleft and network copyleft

Safeguard's license compliance docs classify every license into one of these obligation categories:

Two notes. SSPL-1.0 is on the SPDX License List but not on the OSI's list of approved licenses, so treat it as a source available license with heavy obligations. And Safeguard's Suppliers and Licenses page groups AGPL with strong copyleft, while the main license compliance page gives network copyleft its own row, which is the more useful view for a SaaS business.

What changes for SaaS versus distributed software

The trigger for most copyleft obligations is distribution. OpenChain's own definition of supplied software is software you distribute to third parties. If you ship a mobile app, a desktop installer, firmware, an on-premises appliance, an SDK, or a container image that customers pull and run, you distribute. Strong copyleft then asks for corresponding source of the covered work, and permissive licenses ask for notices to travel with the binary.

A hosted service is different. The GNU project explains why it wrote the Affero GPL: under the ordinary GPL, someone can modify a program and run it on a server for other users without releasing the modified source, because running it for users over a network is not distribution. AGPL-3.0 closes that gap. Its section 13 says that if you modify the program, your modified version must prominently offer everyone who interacts with it remotely over a network a chance to receive the corresponding source of that version.

That gives a rough decision grid:

This grid is a starting point for your legal team, not a ruling. Words like "usually" are doing real work in it. Safeguard's docs reflect the same idea with context overrides: their example license policy denies LGPL-3.0-or-later for assets labelled as an SDK, because LGPL is tricky in SDK distribution, and allows it for a server binary.

How Safeguard detects licenses and shows them per project

License compliance is GA. Here is what the product does, from the docs.

Detection from several signals. The license compliance docs list five sources, reconciled against each other:

1. Package metadata, such as the license field in package.json, pyproject.toml or Cargo.toml, or the licenses element in a Maven POM.
2. SPDX identifiers, recognised against the SPDX License List.
3. Full text matching of LICENSE, LICENCE, COPYING and NOTICE files against known license texts.
4. Header detection in source files.
5. Binary extraction from container layers, by parsing /usr/share/doc/*/copyright files and embedded license strings.

When those signals disagree, for example package.json says MIT while the LICENSE file is AGPL, Safeguard raises a license-discrepancy finding. The docs describe this as typically a packaging mistake or a license relabelling. It is one of the most useful findings in this area, because metadata is what most tools trust and metadata is what is most often wrong.

Classification with obligations. Each license lands in one of the categories in the table above, with linked explanations of obligations such as attribution, source disclosure and patent grants.

Per project: the Suppliers and Licenses tab. In ESSCM, open a project and go to the Suppliers and Licenses tab. The license summary shows the number of distinct licenses, the license types, the overall compliance status and the licenses that require attribution. Compliance status is one of Compliant, Review Needed, Violation or Unknown (license could not be determined). Click a component to see its SPDX identifier, the license text, its obligations, its attribution requirements and a compatibility analysis. The same tab shows supplier data per component: supplier name and URL, contact and verification status, with supplier types of open source project, commercial vendor, internal or unknown. Supplier origin matters to OpenChain too, as we will see in the mapping.

Across the fleet. The Licenses dashboard shows license distribution across your assets, new license introductions over time (new obligations adopted), policy violation counts and trends, and a per asset license manifest you can export to Excel, CSV, SPDX or CycloneDX.

From the CLI. The Safeguard CLI (GA) writes a license.json with the licenses it found alongside vuln.json, collection.json and other results, in a folder per scan under ./output by default. The CLI docs are clear that there is no CLI command yet for license listing, license reports or license policy evaluation.

For open source inventory. OSM, the Open Source Manager (GA), has its own license view with compatibility analysis and a compliance dashboard. Its docs say Gold packages carry a clear license declaration and complete attribution information.

For vendor software. TPRM (GA) runs the same classification on a vendor's SBOM: are their licenses compatible with your product, does any component hit your deny list, and has the license set changed between versions. The docs say this flows into TPRM assessments automatically. See supplier software risk with TPRM.

For which manifest, lockfile and SBOM formats feed this inventory, see the formats Safeguard reads. For the SPDX and CycloneDX side, see how Safeguard handles both SBOM formats.

Step by step: write a license policy, gate on it, and generate NOTICE files

This is the flow from inventory to a release that carries its notices. Commands and paths are as Safeguard's docs show them. Where the docs do not show a screen, we describe the outcome instead.

1. Build the inventory

Connect the repository in the platform, or start from the CLI. The CLI docs say most people begin in the interactive terminal: run safeguard, type /login, then /scan .. Scanning from the interactive terminal while signed in uploads the SBOM and findings to the platform, never your source, so the project appears next to your others.

For a local scan with results on disk only, the command takes one target: a directory, an image or an existing SBOM.

safeguard scan --dir .
safeguard scan --image nginx:latest
safeguard scan --sbom sbom.json

Results land in ./output, including license.json. Scan the image you ship, not only the repository, because its operating system packages carry their own licenses.

2. Review the Suppliers and Licenses tab

Open the project, go to Suppliers and Licenses, and read three things before writing any policy: which licenses appear, which components show Unknown, and whether any license-discrepancy findings exist. Fix discrepancies and unknowns first. A policy built on wrong data gates the wrong things.

3. Write the license policy

The docs show two ways to express it.

In the app, the ESSCM docs say: go to Settings, then License Policies, click New Policy, configure allowed and blocked licenses, set the scope (organization or project) and save. Rules come in three kinds: an allowlist (only these licenses are permitted), a blocklist (these are prohibited) and a review list (these need approval). The OSM docs describe the same screen with actions of warn or block.

As code, the license compliance docs show this format:

apiVersion: safeguard.sh/v1
kind: LicensePolicy
metadata:
  name: default
spec:
  allow:
    - MIT
    - BSD-2-Clause
    - BSD-3-Clause
    - Apache-2.0
    - ISC
    - MPL-2.0
  deny:
    - GPL-3.0-or-later
    - AGPL-3.0-or-later
    - SSPL-1.0
  require_review:
    - GPL-2.0-only
    - LGPL-3.0-or-later
    - "Custom/*"
  context_overrides:
    - apply_to: { env: sdk }
      deny:
        - LGPL-3.0-or-later   # LGPL tricky in SDK distribution
    - apply_to: { env: server }
      allow:
        - LGPL-3.0-or-later   # fine for a service binary

The docs say policies can be scoped to asset labels, so an open core distribution can carry a different policy from a SaaS backend. The docs do not show a command for applying this file, so we will not invent one; ask your Safeguard contact how it is loaded in your workspace.

Use SPDX identifiers in the policy, with explicit -only and -or-later suffixes. A policy that says "GPL" is ambiguous in exactly the place you need precision.

4. Link the policy to a gate and choose its action

Policies generate findings. Gates enforce them at checkpoints. The Policies and Gates docs list License as one of the policy conditions (their example is "No GPL licenses") and include a License Compliance template. Policy creation from plain English prompts is GA as well; see plain English policies to release gates for that flow.

Each policy has one action:

• Block: the gate fails.
• Warn: the gate passes with a warning that names the policy.
• Notify: the gate passes and Safeguard sends a notification to your configured channels.

Per the policy outcomes docs, any failed Block policy fails the gate, a failed Warn policy gives Warning, and an Error never counts as a pass.

A sensible start is Block for the deny list, Warn for the review list, and Notify for new license introductions you want to watch.

5. Fail CI when the gate fails

The GitHub Actions docs give a workflow. Create a secret key under Settings, then Developer, with the scopes scans:trigger and scans:read, store it as the repository secret SAFEGUARD_API_KEY, and save this as .github/workflows/safeguard.yml:

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

To fail on a policy gate, the docs' options table says to add --fail-on-gate all. The policy outcomes docs describe the full form:

safeguard ci scan --wait --fail-on-gate <gate name or id | all>

It waits for the scan and for the gate's policies to be evaluated on the new data, exits 0 on Passed or Warning, and exits non zero on Failed, Error or Not evaluated, printing the Block policies that failed.

Two caveats from the docs. Policy outcomes are turned on per workspace by Safeguard; if you do not see an Outcome column on the Gates and Policies tables, ask your Safeguard contact. And plain safeguard scan never fails on findings: it exits 0 when the scan ran, 1 when the command failed, and 2 when results were written but the vulnerability scan did not run. Gating is done by policy gates in the platform, not by the scan command.

The license compliance docs also describe enforcement at pull request time (a new direct dependency with a deny listed license gets a blocking check) and at admission (images with denied licenses cannot deploy to production). Findings show the transitive path, so the developer sees which direct dependency pulled the license in.

6. Handle exceptions with an expiry

Some conflicts are acceptable: a GPL tool used only at build time and never shipped, or a commercial license you bought. The docs say license exceptions follow the vulnerability exception workflow: a named approver, an expiry date, a business justification, and re-evaluation at expiry. A developer clicks Request Exception, selects the policy and finding, gives a justification and expiry, and submits; the decision lands in an audit trail, which is useful evidence for OpenChain clause 3.2.2.5 on handling non compliant cases.

7. Generate the NOTICE and attribution files

For the project, the ESSCM docs say: click Export, then Attribution Notice, select a format (TXT, HTML or Markdown), customise the template and download. The file includes component names and versions, license type, copyright notices, license text where required and supplier information. The docs also describe regenerating it with each SBOM update and including it in build artifacts. OSM offers the same job as Generate Attribution, with NOTICE, HTML, PDF or Markdown output.

The license compliance docs summarise the outputs as a NOTICE or THIRD-PARTY-NOTICES.txt file, a licenses/ directory with each required license text, and an SPDX document per release. There is no CLI command for generating these yet, so attribution comes from the app today. Put the file where your licenses require it to travel: in the installer, the about screen, the container image or the SDK.

8. Keep a record per release

OpenChain 3.4.1.2 asks you to archive compliance artifacts. Export the per asset license manifest (Excel, CSV, SPDX or CycloneDX) and keep the SPDX document for each release next to the release itself. If you publish SBOMs to customers, see the SBOM generation post in this series.

9. Track OpenChain readiness in Compliance

The Compliance and GRC suite (GA) includes an OpenChain ISO 5230 framework page. The docs say it is on in your workspace unless you switch it off in Compliance, then Manage. Each scan of a product checks six requirements, all decided by the scan:

The framework's Controls tab adds catalog controls for the people and process parts: a written open source policy, roles and responsibilities, competence, awareness, inbound and outbound processes, supplier conformance and fulfilling distribution obligations. You evidence those with uploaded documents, policies, attestations or tests you link yourself. The docs say no automated tests map to this framework directly. The framework also includes policy templates, two of them written for OpenChain: an open source license compliance policy and an open source contribution policy.

A second framework, License Obligations, adds scan checks for attribution completeness (component name and version populated), copyright holder origin, exact versions for source disclosure (no vague ranges) and a machine readable manifest that supports SPDX expressions, plus controls including Unknown and NOASSERTION license handling. For how frameworks, controls and evidence work together in general, see continuous compliance in Safeguard.

Requirement vs what Safeguard does vs what you still own

What the license remediation strategies do

Autonomous remediation (GA, ships off) covers eight categories, and License is one of them, aimed at risky or unknown licenses. Every category is independently set to Manual or Auto. It ships switched off: every category defaults to Manual and nothing is applied until the master Autonomous Remediation toggle is enabled. For the full model, see autonomous remediation in this series.

The License category offers four strategies in the offering:

• Swap to an MIT or Apache-2.0 equivalent. Replace a component whose license fails policy with a different package under a permissive license that does the same job. This is a real code change. A different package rarely has an identical API, so the change must go through review and your tests like any other pull request.
• Drop the component. Remove a dependency that is no longer needed or whose function you can live without. Safeguard's deep dependency scanning (GA) includes unused dependency detection, which is where this strategy is cheapest.
• Open a tracked item for legal. Do not change code; create a work item so a person with authority decides. For anything involving dual licensing, commercial licenses or unclear terms, this is the honest default.
• Smart. The model picks per item based on context, risk and impact.

The AI Remediate docs describe the general pull request flow: analysis, solution generation, impact assessment, pull request creation and validation, with a breaking change rating of Safe, Minor, Major or Critical and settings such as Require Approval and Test Integration. Those docs are written around vulnerabilities, so treat the license strategies as the same pattern applied to a different trigger, not as a separate engine.

Our advice is to start the License category on Manual with "open a tracked item for legal", watch what it proposes for a few weeks, and only then consider "swap" for clear cut cases such as a deny listed library with a well known permissive alternative your team already trusts.

How to handle unknown or custom licenses

Unknown is the most common license status in a real inventory, and the most dangerous one to ignore, because "unknown" often hides "all rights reserved".

Safeguard surfaces these in three places: the Unknown or unidentified category ("review required" in the docs), the Unknown compliance status on the Suppliers and Licenses tab, and the license-discrepancy finding when signals disagree. The example policy puts Custom/* on the review list, and the License Obligations framework has a control for Unknown and NOASSERTION handling.

A workable process:

1. Find the real source. Go to the upstream repository at the exact version you use. Look for a LICENSE file, file headers, and the package registry's metadata. Many unknowns are a packaging slip, not a missing license.
2. Fix it upstream when you can. Open an issue or pull request asking the maintainer to add an SPDX identifier and a LICENSE file. REUSE headers are a good thing to suggest.
3. Record custom licenses properly. If the license is genuine but not on the SPDX list, record it as a LicenseRef- identifier with the full text kept alongside, so the next scan and the next reviewer see the same thing.
4. Get a decision and time box it. Send it to legal through the review list or a tracked item, and if you accept it for now, grant an exception with an expiry so it comes back.
5. Treat no license as no permission. If you cannot find any license, the safe working assumption is that you have no right to redistribute it. Replace it or get written permission.

What still needs a lawyer

Safeguard tells you what you have and what it is labelled. A lawyer tells you what that means for your business. Bring counsel in for:

• Whether a delivery model counts as distribution: a customer hosted deployment, a trial image, a device, an SDK given to others.
• Linking and derivative work questions, especially LGPL in mobile or embedded products and GPL with exceptions.
• Whether a modified AGPL component is one users interact with remotely, and how to make the source offer.
• Dual and commercial licensing, custom licenses, and source available licenses such as SSPL.
• Compatibility when combining components into one work, for example GPL-2.0-only with Apache-2.0.
• Incoming compliance inquiries or claims, and customer contracts that ask for open source warranties.

OpenChain itself expects this: clause 3.2.2 asks that legal expertise on license compliance be accessible to those who need it.

What Safeguard does not do

• It does not give legal advice. Classifications, risk ratings and obligation summaries are inputs for your review. They do not decide whether you distribute, whether a combination is a derivative work, or whether a license is compatible with your business model.
• Detection can be wrong. It is weakest for files without headers, license texts that have been edited, code copied into your repository without its metadata, and snippets pasted from elsewhere. The discrepancy finding catches some of this, not all of it. Unknown results need a human.
• It does not build corresponding source packages or written offers. The docs describe attribution notices, license text bundles and SPDX documents. Assembling the exact source, build scripts and written offer that GPL family licenses require for a release is still your release engineering job.
• There is no CLI command for attribution, license reports or license policy evaluation yet. The CLI writes license.json; notices come from the app, and gating comes from policy gates in the platform.
• The /v1 REST endpoints on the Suppliers and Licenses page are not available. That page carries a banner that every path under the /v1 API returns 404 today and describes intended shape only. Use the app, the CLI or CI.
• Policy outcomes need to be switched on. Safeguard turns them on per workspace. Until then, --fail-on-gate cannot fail a build on a license gate.
• Remediation does not act until you let it. The License category ships on Manual, and a swap to a permissive equivalent is a code change that needs testing and review.
• It does not run your OpenChain program. Writing and communicating the policy, training, the public inquiry address, the contribution process and the conformance affirmation every 18 months stay with your organization. Safeguard supplies the inventory, the checks and the evidence.

Common mistakes

• Scanning the repository but not the shipped image. Base image packages carry GPL and LGPL licenses that never appear in your application manifest.
• Trusting package metadata alone. The license field in a manifest is self declared. Compare it with the LICENSE file, which is exactly what the discrepancy finding is for.
• Writing "GPL" in a policy. Use GPL-2.0-only, GPL-2.0-or-later and so on. The difference changes which license versions you may apply.
• Reading OR as AND, or the reverse. MIT OR GPL-3.0-only is not a GPL problem if you take MIT. MIT AND GPL-3.0-only is.
• Forgetting Apache-2.0 NOTICE files. Section 4(d) requires you to carry the attribution notices in a component's NOTICE file. Permissive does not mean nothing to do.
• Treating SaaS as exempt from everything. It is mostly exempt from distribution triggered duties, not from AGPL section 13, and not once you ship an agent, an SDK or an on-premises edition.
• Exceptions with no expiry. An exception without an end date becomes permanent policy by accident.
• Generating notices once. Dependencies change every release. Generate attribution with each SBOM update so the file matches what ships.
• Calling the program conformant because the tool is green. OpenChain 3.6.1 is explicit that meeting a subset of requirements is not enough.

FAQ

What is OpenChain ISO/IEC 5230?

It is the international standard for the key requirements of a quality open source license compliance program. OpenChain 2.1 is functionally identical to ISO/IEC 5230:2020. It covers policy, competence, awareness, scope, license review, an inquiry contact, resourcing, a bill of materials, license use cases, compliance artifacts, contributions and conformance.

What is the difference between ISO/IEC 5230 and ISO/IEC 18974?

ISO/IEC 5230 covers license compliance. ISO/IEC 18974 covers open source security assurance, focused on known vulnerabilities, and was built from 5230's structure.

Can a tool make us OpenChain conformant?

No. A tool produces the inventory, the license review input, the artifacts and the evidence. Conformance needs a written policy, trained people, a public inquiry method, staffing and a signed affirmation, renewed within 18 months.

What does "MIT OR Apache-2.0" mean in an SBOM?

It means the component is dual licensed and you may use it under either license. Record the one you chose. Safeguard's docs say that for OR expressions it picks the most permissive option that matches your policy.

Does the GPL apply to SaaS?

The GNU project explains that running a modified GPL program on a server for others does not by itself require releasing the source, which is why it wrote the AGPL, whose section 13 does. Ask counsel about your deployment.

How does Safeguard detect open source licenses?

From package metadata, SPDX identifiers, full text matching of license and notice files, source file headers and container layer copyright files, reconciled together. When signals disagree it raises a license-discrepancy finding.

How do I generate a NOTICE file with Safeguard?

In the project's Suppliers and Licenses tab, use Export, then Attribution Notice, and choose TXT, HTML or Markdown. OSM offers Generate Attribution with NOTICE, HTML, PDF or Markdown output. There is no CLI command for this yet.

Can Safeguard block a GPL dependency in a pull request?

Yes, through a license policy linked to a gate. Set the policy's action to Block, and add --fail-on-gate to the safeguard ci scan step in CI. Policy outcomes must be on for your workspace.

What should we do with a dependency that has no license?

Treat it as not licensed for redistribution until proven otherwise. Check upstream at the exact version, ask the maintainer to add a license, record custom licenses as LicenseRef- identifiers with their text, and route the decision to legal with a time boxed exception if needed.

Does Safeguard automatically replace copyleft dependencies?

Only if you allow it. The License remediation category can swap to an MIT or Apache-2.0 equivalent, drop the component, open a tracked item for legal, or let the model choose, but it ships switched off with every category set to Manual.

Putting it together

A license program that works has a short loop. Every release is scanned, including the image you ship. Unknowns and discrepancies are fixed before policy is trusted. The deny list blocks at a gate, the review list goes to a named person, and exceptions expire. Notices are regenerated with every SBOM update and archived with the release. Once a quarter, someone checks the OpenChain controls that no scan can decide: the policy is current, people are trained, the inquiry address works, and the conformance affirmation is inside its 18 months.

License work and vulnerability work run on the same inventory, and the components you swap or drop for license reasons still need to be free of known vulnerabilities in the versions you pick. The block below covers how Safeguard closes that gap, including Gold artifacts that carry a completed license check.

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 with safeguard, and asks it to fix the lodash CVE in a repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It then shows /permissions, /model and /scan .. The same /scan . is how you build the license inventory in step 1, and swapping a dependency that fails your license policy follows the same pattern of a reviewed, approved change.

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

The second demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Safeguard is listed in the Claude connector directory as a community connector. The policy outcomes docs say the MCP server has read only tools for gate outcomes, policy outcomes and evaluation history when outcomes are on and your MCP access settings allow them, which makes "why did the license gate fail on this release?" a question you can ask in plain words.

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

For a shorter take on the license checks themselves, see license compliance checks with Safeguard. If you need to find every product that ships a component after a license or vulnerability surprise, see finding affected products fast with SBOMs. To try it, download Safeguard at safeguard.sh/download and read the docs at docs.safeguard.sh/docs.

Quick check

Sources

• OpenChain Specification 2.1 (functionally identical to ISO/IEC 5230:2020)
• OpenChain Specification 2.1 on GitHub
• OpenChain ISO/IEC 5230 License Compliance
• OpenChain ISO/IEC 18974 Security Assurance
• OpenChain Security Assurance Specification 1.1
• SPDX License List
• SPDX 3.0.1 Annex B: SPDX license expressions
• Open Source Initiative: OSI Approved Licenses
• Open Source Initiative: The Open Source Definition
• FSFE REUSE Specification, version 3.3
• GNU Affero General Public License version 3
• GNU Project: Why the Affero GPL
• Apache License, Version 2.0
• Safeguard docs: License Compliance
• Safeguard docs: ESSCM Suppliers and Licenses
• Safeguard docs: OSM License Compliance
• Safeguard docs: OpenChain ISO 5230 framework
• Safeguard docs: License Obligations framework
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: GitHub Actions
• Safeguard docs: CLI Usage
• Safeguard docs: AI Remediate

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.