# Monitor Open-Source License Changes: Get Alerted When a Project Relicenses (BSL, SSPL, AGPL)

Source: PageCrawl.io Blog
URL: https://pagecrawl.io/blog/open-source-relicensing-license-change-monitoring
Published: 20 August, 2026

---

At 4:58 PM on August 10, 2023, HashiCorp published a short blog post announcing that Terraform, Vault, Consul, Nomad, Packer, and Boundary were moving from the Mozilla Public License 2.0 to the Business Source License 1.1. A platform team three time zones away that shipped Terraform inside a commercial product did not see it. They found out nineteen days later, when a customer's procurement reviewer pasted the new license text into a security questionnaire and asked, in writing, whether the team was now "a competitive offering to HashiCorp." The answer required legal review, an OpenTofu migration spike, and an awkward call. None of it would have been a fire drill if someone had caught the LICENSE file diff the same afternoon it landed.

Relicensing is one of the highest-impact, lowest-visibility events in your software supply chain. A single text change in one file can convert a permissively licensed dependency into a source-available product with usage restrictions, redistribution limits, and a competitive-use carve-out that your legal team has to interpret line by line. The change rarely comes with a press release aimed at you, and it almost never shows up in your dependency scanner the day it happens.

This guide covers what relicensing actually changes, which projects have done it and what they switched to, what BSL, SSPL, and the Elastic License restrict, exactly which pages and files to watch, and how to set up same-day license-change alerts in PageCrawl so legal and engineering get the signal together.

<iframe src="/tools/open-source-relicensing-license-change-monitoring.html" style="width: 100%; height: 500px; border: none; border-radius: 4px;" loading="lazy"></iframe>

### What does it mean when an open-source project relicenses?

Relicensing means the project owner changes the legal terms under which the code is distributed, usually by editing one file: `LICENSE` (or `LICENSE.txt`, `LICENSE.md`, `COPYING`) at the root of the repository. The code may look identical, but your rights to use, modify, host, and redistribute it can change overnight, retroactively for new versions.

The shift almost always moves in one direction: from an OSI-approved permissive or copyleft license (Apache 2.0, MPL 2.0, BSD 3-Clause, AGPLv3) toward a "source-available" license that the Open Source Initiative does not recognize as open source. Source-available means you can read and often modify the code, but the license adds restrictions, most commonly a clause forbidding you from offering the software as a competing commercial or managed service.

Because the change lives in plain text in a public repository, it is perfectly suited to automated change detection. The hard part is not reading the new license, it is noticing that the old one was replaced. A diff on a single file is exactly the kind of event that [website and file change monitoring](/blog/how-to-monitor-website-changes-guide) was built to catch, and it is the difference between a same-day migration plan and a surprise in a customer audit.

<picture>
<source srcset="/images/blog/previews/open-source-relicensing-license-change-monitoring.webp" type="image/webp">
[Image: Screenshot of github.com in a browser window, an example of a page PageCrawl can monitor for changes]
</picture>
Point PageCrawl at github.com and get an alert the moment anything on it changes.

### Which major projects have relicensed, and what did they switch to?

The last seven years produced a wave of high-profile relicensings, each one stranding teams that depended on the old terms. The pattern is consistent: a widely adopted infrastructure project, backed by a venture-funded company, swaps a permissive license for a source-available one to block hyperscalers from reselling it, and a community fork appears within weeks.

| Project | From | To | When | Fork |
|---------|------|----|----|----|
| MongoDB | AGPLv3 | SSPL v1 | Oct 2018 | (none mainstream) |
| Elasticsearch / Kibana | Apache 2.0 | SSPL + Elastic License 2.0 | Jan 2021 | OpenSearch |
| HashiCorp (Terraform, Vault, etc.) | MPL 2.0 | BSL 1.1 | Aug 2023 | OpenTofu |
| Redis | BSD 3-Clause | SSPL + RSAL 2.0 | Mar 2024 | Valkey |

The story does not always end with a one-way move. Elastic added AGPLv3 as a third license option for Elasticsearch in 2024, partially reversing course after the OpenSearch split. Redis went further, adopting AGPLv3 for Redis 8 in 2025 and returning to OSI-approved status. If you only watched for the move toward restriction, you would miss the equally important reversion that lets you adopt the project again. This is why the right approach watches for any change to the license text, in either direction, not a one-time check.

Each of these events also rippled into [the underlying technology stacks](/blog/competitor-website-technology-stack-monitoring) of thousands of downstream products, forcing migrations to OpenTofu, Valkey, and OpenSearch that took quarters to plan and execute.

### What do BSL 1.1, SSPL, and the Elastic License actually restrict?

These three are the licenses that catch teams off guard, because each looks open at a glance but encodes a different restriction. Understanding the mechanics tells you why a same-day alert matters: the clause that bites you is often buried in a one-paragraph "Additional Use Grant" or a definition near the bottom of the file.

#### Business Source License 1.1 (BSL)

The BSL is a "delayed open source" license. The text is source-available with an Additional Use Grant that the vendor fills in (for Terraform, roughly "any use that is not a competitive offering to HashiCorp"), plus a Change Date and a Change License. After the Change Date, typically four years from each release, that specific version automatically converts to the named open-source license (MPL 2.0 for Terraform, GPLv2-or-later by default). The catch: the version you ship today is restricted today, and the Additional Use Grant wording can change release to release.

#### Server Side Public License (SSPL)

The SSPL, created by MongoDB and adopted by Redis and Elastic, is AGPLv3 with a much broader copyleft trigger. Its Section 13 says that if you offer the software "as a service," you must release the source code of essentially your entire service-management stack under the SSPL, not just your modifications. In practice this makes it commercially unusable for managed-service providers, which is the point. The OSI declined to approve it as open source.

#### Elastic License 2.0 (ELv2)

ELv2 is a short, readable source-available license with three key limits: you may not provide the software as a hosted or managed service to third parties, you may not circumvent license-key functionality, and you may not remove licensing or copyright notices. It is permissive for internal use and embedding, restrictive for resale. Because the text is short, even a small wording change is meaningful, which makes [keyword and text-threshold alerting](/blog/conditional-alerts-price-keyword-threshold-rules) on terms like "competitive," "managed service," and "Change Date" especially effective.

### Which exact pages and files should you monitor?

Watch four things per dependency: the raw LICENSE file, the GitHub license metadata, the vendor's licensing or FAQ page, and the relevant release notes. The LICENSE file is the legal source of truth, but the surrounding pages often announce intent days before the commit lands, and the metadata endpoint gives you a clean machine-readable signal.

The most reliable single target is the raw license file at its canonical URL, for example `raw.githubusercontent.com/hashicorp/terraform/main/LICENSE`. The raw view is plain text with no surrounding page chrome, so a diff is unambiguous and never trips over unrelated site redesigns. Add the human-facing blob page (`github.com/owner/repo/blob/main/LICENSE`) if you want a screenshot of how the change appears to a developer.

GitHub also exposes a structured signal. The REST endpoint `GET /repos/{owner}/{repo}/license` returns a JSON object whose `license.spdx_id` field carries the SPDX identifier (`MPL-2.0`, `Apache-2.0`, `AGPL-3.0`, or `NOASSERTION` when the license is source-available and unrecognized). Watching that one field with [JSON and API field tracking](/blog/monitor-json-api-field-jsonpath-jq-filters) gives you a precise, low-noise trigger: when `spdx_id` flips from `Apache-2.0` to `NOASSERTION`, you have your answer in one line.

Finally, monitor the vendor's own licensing page and FAQ. Companies often publish a "licensing" or "why we changed our license" page, and changes there, including [policy and terms text on the vendor's own site](/blog/monitor-terms-of-service-changes-saas-vendors), frequently precede or accompany the repository commit. If a project distributes its license or contributor agreement as a PDF, point a monitor at that document too.

### How fast do you need to know about a license change?

For most teams, same-day is the right target, and an hourly check is more than fast enough. Relicensings are deliberate, announced events, not flash sales, so you are not racing milliseconds. The cost of being late is measured in days of legal exposure and weeks of migration scramble.

The goal is to catch the diff before a customer, auditor, or journalist does. There are two windows that matter. The first is the legal-exposure window: every day you ship a build of a newly restricted dependency without knowing it, you may be operating outside the new terms, which is exactly the kind of finding that surfaces in a [continuous vendor and third-party risk review](/blog/continuous-vendor-monitoring-tprm). The second is the migration-planning window: catching the change on day one means your team evaluates OpenTofu, Valkey, or OpenSearch on its own schedule, rather than under a customer-imposed deadline.

A 15-minute or hourly cadence on the LICENSE file comfortably beats the human grapevine, which typically takes days to reach the right engineer. Reserve faster check frequencies for the handful of dependencies that sit at the core of your product and where a forced migration would be a multi-quarter project.

### Which PageCrawl tracking mode fits the LICENSE file best?

Use fullpage content tracking on the raw LICENSE file as your primary monitor, because it captures the entire legal text and flags any wording change, including subtle edits to an Additional Use Grant. Layer JSON field tracking on the GitHub license endpoint for a clean one-field signal, and add keyword tracking for the specific terms that signal restriction.

Fullpage content tracking renders the page, normalizes the text, and compares it against the previous capture. On a raw license file this is close to ideal: the content is pure text, so a diff highlights exactly which clauses, definitions, or dates changed. PageCrawl renders the page fully and reliably monitors the target even when the repository host changes its layout, so your monitor keeps working through site redesigns.

For the metadata endpoint, JSON field tracking lets you watch `license.spdx_id` directly and ignore everything else in the response, which keeps the alert noise-free. For the vendor licensing page, combine fullpage tracking with keyword/text tracking on phrases like "Business Source License," "SSPL," "Elastic License," "competitive offering," "managed service," and "Change Date," so a single appearance of any of those terms raises a flag. Keep screenshots on (new monitors enable them by default) so every alert ships with a visual record of the page at the moment it changed, which is exactly what your legal team will want to attach to a file. For dependencies in private repositories, login-gated monitoring lets PageCrawl authenticate and watch the internal LICENSE file the same way.

### How do you set up open-source license monitoring with PageCrawl?

Setting up a license monitor takes about three minutes per dependency, and you only do it once per package. The example below watches the Terraform LICENSE file, but the same six steps apply to any repository, vendor licensing page, or license metadata endpoint you want to keep an eye on.

[Image: PageCrawl change diff for HashiCorp Terraform - LICENSE file, highlighting the added and removed text]

**Step 1: Add the target URL and pick a tracking mode.** Create a new monitor pointing at the raw license file, for example `https://raw.githubusercontent.com/hashicorp/terraform/main/LICENSE`. Choose fullpage content tracking so PageCrawl captures and diffs the entire license text. For a parallel metadata monitor, add the GitHub license API URL and select JSON field tracking on `$.license.spdx_id`.

**Step 2: Add keyword and threshold rules.** Within the same monitor, add keyword/text rules for "Business Source License," "SSPL," "Elastic License," "competitive," "managed service," and "Change Date." This way you get an alert if any restrictive term appears, even before you read the full diff. Conditional rules keep routine, irrelevant edits (a typo fix, a year bump in a copyright line) from paging anyone.

**Step 3: Set the check frequency.** For most dependencies, every 15 to 60 minutes is right. Set your two or three most business-critical packages to a tighter cadence, and leave long-tail dependencies on hourly. License changes are announced events, so you are buying same-day awareness, not millisecond reaction time.

**Step 4: Choose a notification channel.** Route alerts to where the right people will see them. A shared [Slack channel for license alerts](/blog/website-change-alerts-slack) works well because it reaches legal and engineering at once. You can also send to Telegram, Discord, email, or fire a [webhook into your own automation](/blog/webhook-automation-website-changes) to open a Jira ticket, kick off a dependency audit, or post to an internal compliance log automatically.

**Step 5: Confirm screenshots are on.** New monitors capture screenshots by default, and you should keep this on for license monitoring. A timestamped image of the LICENSE page is contemporaneous evidence of what the license said and when it changed, which is exactly what legal will reference in a vendor review or a customer questionnaire.

**Step 6: Scale across your dependency list.** Export your software bill of materials, pull the repository URLs for your most depended-on packages, and add them in bulk. [Bulk URL monitoring](/blog/bulk-url-monitoring) lets you stand up dozens of LICENSE-file monitors at once, so your entire critical-dependency set is covered from day one rather than one package at a time.

### How should legal and engineering teams act on a license alert?

Treat a license alert as a joint triage event, not an engineering ticket or a legal ticket alone. The moment the diff fires, you want both functions reading the same screenshot and the same text within hours, because the right response depends on the interaction between the new clause and how your product actually uses the dependency.

Engineering's first job is scope: which versions are affected, whether the change is retroactive or applies only to future releases, and whether a maintained fork (OpenTofu, Valkey, OpenSearch) is a drop-in replacement. Legal's first job is interpretation: read the Additional Use Grant or the service clause against your deployment model, decide whether your usage is internal-only (usually fine under BSL and ELv2) or service-facing (the case that triggers SSPL and competitive-use restrictions), and note the Change Date if the license will revert to open source later.

Two outcomes are common. If the new license is compatible with your use, you document the decision, capture the screenshot as evidence, and move on. If it is not, you have a migration project with a head start, because you caught it on day one instead of in an audit. Feeding these license events into a broader vendor and supply-chain risk program turns a recurring fire drill into a routine, logged signal that your compliance and procurement teams already know how to process.

### Choosing your PageCrawl plan

PageCrawl's **Free plan** lets you monitor **6 pages** with **220 checks per month**, which is enough to validate the approach on your most critical pages. Most teams graduate to a paid plan once they see the value.

| Plan | Price | Pages | Checks / month | Frequency |
|------|-------|-------|----------------|-----------|
| Free | $0 | 6 | 220 | every 60 min |
| Standard | $8/mo or $80/yr | 100 | 15,000 | every 15 min |
| Enterprise | $30/mo or $300/yr | 500 | 100,000 | every 5 min |
| Ultimate | $99/mo or $999/yr | 1,000 | 100,000 | every 2 min |

Annual billing saves two months across every paid tier.

Enterprise and Ultimate scale up to 100x if you need thousands of pages or multi-team access.

### Where should you start with license monitoring?

Start with the single dependency whose relicensing would hurt the most, point a fullpage monitor at its raw LICENSE file, and route the alert to a channel that legal and engineering both watch. Once that one works, expand to the rest of your critical packages and let the coverage grow from there.

The next BSL, SSPL, or AGPL flip is coming, and the only question is whether you read about it the afternoon it happens or three weeks later in a customer's questionnaire. Set up your first license monitor in the next ten minutes and never be the last to know again.

---

Need more? The complete PageCrawl.io help center, with every article, is available as a single document at https://pagecrawl.io/llms-full.txt. Read it for context on anything this page does not cover.