# The Repository License Reference: Commercial Use and Copyleft Triggers

*You can read any LICENSE file and dependency tree and state whether you may ship it commercially, what obligation triggers, and which "open source" claims mislead.*

- Canonical URL: https://www.refolk.ai/guides/repository-license-reference
- Pillar: Engineering and open source
- Format: Reference
- Published: 2026-09-25
- Last reviewed: 2026-09-25
- Reading time: 16 min
- Keywords: can I use this license commercially, AGPL SaaS source disclosure obligation, is BSL open source, check dependency license commercial use, source available vs open source

## Key takeaways

- AGPL's Section 13 network-disclosure requirement is triggered only where the software has been modified by the entity providing the network service, not by unmodified use.
- The Business Source License is not an OSI open source license; production use is off by default unless an Additional Use Grant covers your case, until the Change Date or the fourth anniversary of a version's release.
- SSPL is a step-function harder than AGPL: it demands source for all programs and systems used to provide the service, a practically unmeetable bar that is the point.
- A relicense reaches production through the upgrade, not the decision: MongoDB back-ported the SSPL to patch fixes for prior versions after October 16, 2018.
- A lockfile-only scan produces false all-clear reports because the true license lives in unpacked source and vendored subdirectories, not the manifest.
- In Refolk's index, only 49 US profiles carry a Software Composition Analysis tag and 19 a Software Bill of Materials tag, so expect to train rather than hire the exact profile.

You are about to build a commercial or SaaS product on an open-source repository, and you need to know whether its license, and its dependencies' licenses, let you ship, and what obligations you take on. This reference is for engineering managers, technical founders, and sourcers who have to make that call from the repo itself. It maps each license to concrete commercial and SaaS rights, names the exact event that triggers copyleft, and exposes the deception patterns of the source-available wave, all read straight off the LICENSE file and the lockfile.

Jump to the row you need. Every license here gets a plain statement of what it permits, what obligation it triggers, and what it looks like when someone claims more freedom than it grants.

## Can I use this license commercially? The trigger matrix

Almost every license in wide use permits commercial and SaaS use. The question that actually matters is what obligation triggers, and on what event. Read the matrix by the last column, not the first.

| License | Commercial use | SaaS without disclosure | Copyleft trigger |
|---|---|---|---|
| MIT / BSD-3 / Apache-2.0 | Yes | Yes | None (attribution only) |
| MPL 2.0 | Yes | Yes | Modify an MPL file (file-level) |
| LGPL | Yes | Yes | Modify the library (link-level) |
| GPL 2.0/3.0 | Yes | Yes | Distribute binaries |
| AGPL 3.0 | Yes | No (if modified) | Network access to modified version |
| BSL 1.1 | Only per Additional Use Grant | No | Production restricted until Change Date |
| SSPL / ELv2 | Restricted | No | Offer as a service |

The permissive tier - MIT, BSD-3, Apache 2.0 - permits commercial and SaaS use with only attribution and notice retention. Apache 2.0 adds two things worth knowing: an express patent grant and a NOTICE-file requirement. When patents are in scope, Apache 2.0 is the safe default precisely because of that explicit grant.

The weak-copyleft tier scopes the obligation narrowly. The MPL is a file-level copyleft: it encourages contributors to share modifications to the covered files while still allowing you to combine that code with code under other licenses. It sits between Apache, which does not require modifications to be shared at all, and the GNU family, which reaches further. LGPL is scoped to linking: it lets you link the library into proprietary software, but if you modify the library itself, you must release those modifications under the LGPL.

The strong-copyleft tier is where distribution matters. GPL 2.0 and 3.0 require you to provide full corresponding source when you distribute binaries. AGPL 3.0 extends that same duty to network use. The source-available tier - BSL, SSPL, Elastic License 2.0 - is not OSI open source at all, and each restricts the commercial case you most likely care about.

> **Rule:** Read the trigger, not the name
>
> The name of a license tells you almost nothing about whether you can ship. The trigger event and the scope of the obligation are the only facts that decide it. Record both for every node.

## GPL versus AGPL: the SaaS loophole and its one condition

The difference between GPL and AGPL is one event. GPL's copyleft is triggered by conveying or distributing object code. If you never distribute a binary, GPL's source-disclosure duty never fires, which is why running GPL software behind a web service historically triggered nothing.

AGPL was written to close that gap. AGPLv3 Section 13 adds a source-disclosure requirement beyond the object-code-distribution trigger in GPLv2 Section 3 and GPLv3 and AGPLv3 Section 6. The stated objective was to close a perceived loophole where users make use of functionality as a web service but no distribution occurs. AGPL v3 was published by the Free Software Foundation on November 19, 2007.

Here is the condition most teams miss. The AGPLv3 Section 13 requirement is triggered only where the AGPLv3 software has been modified by "you" - for example, the entity providing the network service. If you run the software unmodified, or you expose only your own separate code that calls it, Section 13 does not force you to publish your product.

#### When AGPL Section 13 actually fires

1. **Adopt AGPL component** - No obligation yet
2. **Modify the component** - Still no obligation if you never expose it
3. **Expose the modified version over a network** - Section 13 fires
4. **Offer to network users the corresponding source** - Obligation satisfied

*The disclosure duty needs both a modification and a network exposure of that modified version.*

This is why AGPL fear is mostly misplaced but rationally enforced. Using unmodified AGPL code does not infect your product, yet Google's internal open source policy bans AGPL-licensed code entirely, because the modified-and-network-exposed edge case is contested and cheaper to avoid than to litigate. That is a defensible policy for a large organisation. It is a bad reason for a small team to ban a dependency it only calls unmodified.

**49 - US profiles tagged with a Software Composition Analysis skill**

In Refolk's index, against 19 tagged with Software Bill of Materials - the pool that can staff this work is small.

## Is BSL open source? The Additional Use Grant and Change Date

No. The Business Source License is source-available, not open source, and production use is off by default. What you can do commercially depends entirely on two clauses you must read in the specific repo: the Additional Use Grant and the Change Date.

The Additional Use Grant is where the vendor carves out what you may do in production. HashiCorp's grant, for instance, allows production use except in products competitive with HashiCorp. That single exception is the whole license for most readers - it means you can build on it unless you compete with the vendor, and "compete" is the vendor's word to define.

The Change Date is the escape hatch. Effective on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version, whichever comes first, the licensor grants you rights under the Change License, and the prior restrictions terminate. The Change License is mandated to be GPL Version 2.0 or later, or a compatible license. BSL 1.1 was first applied to MariaDB products in 2013 and clarified as version 1.1 in 2017, so this is a mature mechanism, not a novelty.

The critical property: the four-year clock runs per version. A version you rely on today converts on its own anniversary, but the next version you upgrade to starts a fresh clock under the current terms. That is the trap covered below.

> **Watch out:** The Additional Use Grant is per repo, not per license
>
> Two BSL projects can grant wildly different production rights. Never generalise from one vendor's grant to another. Open the actual LICENSE and read the Additional Use Grant and Change Date for the exact version you plan to ship.

## Source available versus open source: the relicense wave

Source-available is not open source. When a project relicenses to BSL, SSPL, or the Elastic License, it keeps the code visible but removes the freedoms that made it open. The OSI declared in January 2021 that SSPL does not comply with the Open Source Definition. Knowing which well-known projects moved, when, and to what, tells you which "open source" claims in the wild are stale.

| Project | From | To | Date | Fork |
|---|---|---|---|---|
| MongoDB | AGPL | SSPL | Oct 2018 | - |
| Elasticsearch | Apache-2.0 | SSPL/ELv2 | Jan 2021 | OpenSearch |
| Terraform | MPL-2.0 | BUSL-1.1 | Aug 2023 | OpenTofu |
| Redis | BSD | RSAL/SSPL | Mar 2024 | Valkey |

The detail behind the rows: SSPL was published by MongoDB on October 16, 2018, is neither OSI nor FSF approved, and is GPL-incompatible. In January 2021 Elastic re-licensed under the SSPL and the Elastic License, then in August 2024 added AGPLv3 as a third option while keeping ELv2 and SSPL available. On August 10, 2023, HashiCorp announced future Terraform releases would move from MPL 2.0 to BUSL 1.1, and Vault and Consul moved too, spawning the OpenTofu and OpenBao forks. Redis moved from BSD on March 20, 2024, driven by AWS ElastiCache and Azure Cache, and then reversed to AGPLv3 in May 2025. CockroachDB (2019, Apache-2.0 to BSL), Consul (2023, MPL-2.0 to BSL), and Couchbase Server (2021, Apache-2.0 to BSL) followed the same pattern.

Each move produced a fork you can adopt instead: OpenSearch, OpenTofu, Valkey. The relicense rarely reclaims the community it targeted. More than 90 percent of Elasticsearch contributors were Elastic employees at relicense time, so the vendor lost little internal contribution and spawned forks with more organizational diversity. IBM acquired HashiCorp for $6.4 billion in February 2025, which is the kind of outcome relicensing is meant to protect.

> The vendor traded community goodwill for control it mostly already had.

If you are trying to source people who actually navigated one of these moves - engineers who contributed to a post-fork project, or a product security architect who handled a relicense - describing that experience in plain English is faster than reconstructing it from commit history by hand. That is the shape of query [Refolk](/) is built to answer.

I ran this search: `Engineers who contributed to OpenTofu, Valkey, or OpenSearch after the 2023-2024 forks` - [see the full result list](https://www.refolk.ai/s/v85s5qp313).

*Returns profiles of people with hands-on post-relicense fork experience, ranked by contribution recency and depth.*

## How to determine the effective license, including transitive dependencies

Determining whether you can ship is a tree-first, license-second procedure. You resolve the full dependency tree, attach a license to every node, verify against source, and only then classify obligations. A license compliance scanner reads dependency manifests and lockfiles, walks the full transitive tree, and attaches a license to every package, usually combining three signals: SPDX identifier matching, full-text pattern matching against bundled LICENSE files, and package-registry metadata.

The step that CI-only pipelines skip is source verification. You cannot answer the question from a lockfile alone. To produce a report that is actually true, something has to fetch and unpack the real source of every transitive dependency, because that is where the license file, the per-file SPDX headers, and the vendored third-party code live.

#### Determine the effective license of a repo you plan to ship

1. **Read the LICENSE and declared identifier** - Open LICENSE, COPYING, NOTICE, and the manifest license field, and record the canonical SPDX identifier. Note any mismatch between the LICENSE file and package.json or README, since registries check both.
2. **Resolve the full dependency tree** - Generate a lockfile and an SBOM with an ecosystem-native tool. Done when every direct and transitive node is enumerated with a version.
3. **Attach a license to every node** - Run a license scanner over manifests and lockfiles, combining SPDX matching, full-text matching, and registry metadata. Done when no node is left as unknown.
4. **Verify against actual source** - Fetch and unpack packages so per-file SPDX headers and vendored code are inspected. This is the step lockfile-only pipelines skip and where the true license lives.
5. **Classify each license by obligation and trigger** - Bucket every node as permissive, weak copyleft by file or link, strong copyleft on distribution, network copyleft, or source-available. Done when each node has both an obligation and its trigger event.
6. **Flag source-available and network-copyleft nodes** - Send every BSL, SSPL, ELv2, and AGPL node to counsel with the Additional Use Grant and Change Date attached. Done when each has a written go or no-go.
7. **Set policy and gate CI** - Export the SBOM as SPDX or CycloneDX, encode allow, review, and deny lists, and re-scan on every dependency change. Done when the pipeline blocks a newly denied license on a version bump.

Tooling exists for every step and much of it is itself permissively licensed. ScanCode recognizes over 1,000 license variants; Syft and Trivy generate SBOMs under Apache-2.0; SPDX and CycloneDX are the interchange formats your policy engine consumes. None of these tools makes the classification call for you. They surface the facts. A human still buckets each node by obligation and decides go or no-go on the source-available and network-copyleft nodes.

## Where the analysis goes wrong: failure modes and false positives

The most expensive mistakes here are false clears, not false alarms. A ban you regret costs you a good dependency; a false clear ships a compliance liability into production. These are the patterns that bite.

- **Lockfile-only scan.** Produces an all-clear report that is not true. The real license lives in unpacked source and vendored subdirectories, not the lockfile. Fix: run the source-verification step.
- **Trusting registry metadata.** The npm or PyPI license field can contradict the actual LICENSE file. Fix: full-text match, not just the SPDX string.
- **Assuming AGPL infects your app.** Using an AGPL tool to build your software does not make your software AGPL. Fix: check whether the component was modified and network-exposed before banning it.
- **Reading "source available" as "open source."** The Business Source License is not an open source license. Fix: check OSI approval status, not the marketing page.
- **Assuming SSPL is roughly AGPL.** SSPL requires releasing the entirety of the service's source, unlike AGPL, whose copyleft applies only to the licensed work itself. Fix: read the Section 13 difference directly.
- **Missing the version boundary on BSL.** Pinning to an old MPL Terraform is fine; the next upgrade flips terms. Fix: gate on version, not project name.
- **Overlooking a transitive relicense on upgrade.** Fix: re-scan on every dependency bump, not just new adoptions.
- **ELv2 "internal use is fine" overreach.** Internal use is fine, but providing it as a service where external customers gain direct access to significant functionality is not. Fix: ask whether an external user touches the software's features.

The Elastic License 2.0 case deserves its own line because the internal-use overreach is so common. ELv2 says you may not provide the software to third parties as a hosted or managed service where the service gives users access to any substantial set of the features or functionality of the software. Running it for your own team is fine. The moment an external customer touches its features through your service, you are outside the grant.

> **Watch out:** The transitive relicense is the one that turns into a finding
>
> A relicensed component hiding in a transitive layer is the hardest to catch and the most likely to reach production silently. Your direct dependencies get attention; the packages three levels down do not, until a re-scan flags them.

## The relicense-on-upgrade trap

The relicense reaches production through the upgrade, not the decision. This is the single mechanism most teams underestimate. A license is a property of the artifact you pull, not of the date you first adopted the project. When a vendor relicenses, the new terms travel with new versions and, often, with back-ported patches.

#### Is this node safe to ship after a version bump?

Horizontal axis runs from Pinned to pre-change version to Upgraded to post-change version. Vertical axis runs from Direct dependency to Transitive dependency.

| Quadrant | What it means |
| --- | --- |
| Direct, pinned | Safe for now, but note the version boundary |
| Direct, upgraded | Re-read the license before merging the bump |
| Transitive, pinned | Safe, but track it in the SBOM |
| Transitive, upgraded | Highest risk - the silent relicense finding |

*The dangerous quadrant is a relicensed component you upgrade without re-reading its terms.*

MongoDB is explicit about the mechanism: all versions of MongoDB Community Server released after October 16, 2018, including patch fixes for prior versions, are licensed under the SSPL, while every version released before that date remains under AGPL v3.0. A team applying a routine security patch adopts the new terms without ever making a procurement decision.

BSL works differently but the danger is the same. HashiCorp's change was not retroactive, so pre-change code stayed under MPL 2.0. Terraform version 1.5.7, released September 7, 2023, remained MPL 2.0, while 1.6.0 on October 4, 2023, carried BUSL. The next version bump is the relicensing event. Pinning to 1.5.7 is fine forever; the upgrade to 1.6.0 is a license change disguised as a feature update.

This is why the CI gate in step seven is not optional hygiene. It is the only control that catches the relicense you did not decide to accept. Re-scan on every dependency change, gate on the resolved version, and require a human sign-off when a node moves from an allowed license to a review-or-deny one.

## Before you call the job done

Run this checklist against the repo and its tree before you commit to shipping. If any item is unchecked, you do not yet have an answer you can stand behind.

#### Ship-readiness for a commercial or SaaS build

- [ ] Every node in the transitive tree has a resolved SPDX identifier and no node is unknown.
- [ ] Licenses were verified against unpacked source and per-file headers, not the lockfile alone.
- [ ] Each node is bucketed as permissive, weak copyleft, strong copyleft, network copyleft, or source-available.
- [ ] Every AGPL node has been checked for modification and network exposure before any ban or clear.
- [ ] Every BSL node has its Additional Use Grant and Change Date recorded, matched to your use case.
- [ ] Every SSPL and ELv2 node has a written go or no-go from counsel.
- [ ] The SBOM is exported as SPDX or CycloneDX and the CI gate re-scans on every dependency bump.
- [ ] Version pins are noted for any dependency where a future upgrade would flip the license terms.

Keep a copy of the reference outreach below if you have to escalate a source-available node to a vendor for a written grant. It is faster to get a yes on the record than to argue about a clause after you have shipped.

**Vendor request for a written production-use grant**

```
Subject: Production-use clarification for [product] under your source-available license

I am evaluating [product] version [X.Y.Z] for use in a commercial SaaS product.
My use is: [one sentence describing exactly how the software is deployed and whether external users touch its features].

Please confirm in writing whether this use is permitted under your current
Additional Use Grant, and state the Change Date and Change License for this
specific version. I need this on the record before adoption.
```

*Adapt the bracketed product and use-case description, then send to the vendor's licensing contact before you ship.*

Finally, the honest limit: staffing this work is harder than doing any single scan. In Refolk's index, only 49 US profiles carry a Software Composition Analysis skill tag and 19 carry a Software Bill of Materials tag, and the open-source compliance skill pool is roughly 5.9x larger in the US than in Germany. The exact profile is scarce and lopsided, so plan to train an engineer into the procedure rather than expecting to hire someone who already lives in it.

| Segment | Count | Derived |
|---|---|---|
| OSS compliance/licensing, US | 722 | baseline |
| OSS compliance/licensing, Germany | 122 | 0.17x of US |
| SCA skill, US | 49 | baseline |
| SBOM skill, US | 19 | 0.39x of SCA |

To keep this reference current, re-check three things on a schedule: the OSI approval status of any source-available license in your tree, the Change Date on every BSL node as its four-year clock runs, and the license field on every dependency after each upgrade. The mechanism is stable; the specific licenses on specific versions are not.

## Frequently asked questions

### Does using an AGPL tool make my whole product AGPL?

No. Using an AGPL tool to build your own software does not make your software AGPL; the license covers the tool, not what you build with it. The AGPL Section 13 source-disclosure requirement is triggered only where you have modified the AGPL software and then expose the modified version over a network. If you run it unmodified, or expose only your own code, your product is unaffected. Banning a dependency you merely call unmodified is a false positive.

### Is BSL open source?

No. The Business Source License is source-available, not an OSI-approved open source license. Production use is off by default unless the vendor's Additional Use Grant covers your case. On the Change Date, or the fourth anniversary of a version's first public distribution, whichever comes first, that version converts to the stated Change License, which must be GPL v2.0-or-later or a compatible license. Read the OSI approval status before treating any "source available" claim as open source.

### Can I check dependency licenses for commercial use from the lockfile alone?

No, not reliably. A lockfile lists packages and versions, but the true license lives in the unpacked source, per-file SPDX headers, and vendored subdirectories. A lockfile-only scan produces false all-clear reports. To get a report that is actually true, fetch and unpack the real source of every transitive dependency. Treat the lockfile scan as a first pass and verify against source before you ship.

### What is the difference between the AGPL and the SSPL disclosure obligation?

AGPL's copyleft applies only to the licensed work itself and is triggered when you offer a modified version over a network. SSPL is a step-function harder: it requires releasing the source for all programs and systems used to provide the service, which is a practically unmeetable bar. Do not treat SSPL as roughly equivalent to AGPL. Read the Section 13 differences directly before making any go decision on an SSPL node.

### How does a relicense end up in my production build without a decision?

Through the upgrade. Relicensing is applied to new versions and often back-ported to patches, so a routine security update pulls the new terms. MongoDB licensed patch fixes for prior versions under the SSPL after October 16, 2018. For BSL the boundary is version-scoped: Terraform 1.5.7 stayed MPL 2.0 while 1.6.0 onward carried BUSL. Gate on version, not project name, and re-scan on every bump.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/repository-license-reference*