AGPL, BUSL and SSPL in a software acquisition
Most licences ask for attribution and little else. Three ask for more, and what they ask depends on how the product reaches its customers: the GNU Affero General Public License (AGPL), the Business Source License (BUSL, often written BSL) and the Server Side Public License (SSPL). This guide is for a buyer reading a software company's code, and for the company being read. It says what triggers each licence, what a buyer asks, and how to find all three in a repository. It is not legal advice: the questions it raises are for counsel, and they are cheaper to answer before a term sheet than after one.
The three at a glance
| Licence | Open source? | What triggers it | What a buyer asks |
|---|---|---|---|
| AGPL-3.0 | Yes | Users reach a modified version over a network | Is it modified, and how is it combined with the product's own code? |
| BUSL-1.1 | No, until each version's change date | Production use the licensor's grant does not allow | What does the grant allow, and when does each version change licence? |
| SSPL-1.0 | No | Offering the program to others as a service, modified or not | Does the product offer it as a service? |
Two ways a deal meets them
- The product uses them. A component under one of these licences sits inside the product, or runs beside it. The licence binds the company as a user, and the buyer inherits that.
- The product is licensed under them. The company publishes its own code under one of these licences, usually beside a paid edition. After the deal the buyer owns the copyright, so the licence binds everyone else, not the buyer. What the buyer cannot relicense is code the company never owned: outside contributions taken without an assignment.
AGPL-3.0
The AGPL is the GPL with one more clause. Section 13 says that if you modify the program and users interact with it over a network, you must offer those users its source. For a hosted product, serving users counts the way shipping a binary counts under the GPL.
A Borehole report states it as: open source; offering it over a network counts as distributing it, so a hosted product's changes must be published.
- Unmodified and separate. An AGPL database or service run as is, beside the product, usually obliges nothing for the product's own code. Many companies still keep a policy against AGPL, and the buyer may have one.
- Modified, or combined. An AGPL library linked into the product's server code makes the combination a work based on it. Section 13 then reaches the whole combination, and the company's own code with it. How the parts are combined decides it, which is why counsel reads the architecture as well as the licence.
- The product itself is AGPL. A competitor may host it, as long as it publishes its changes. A buyer who wants to close the code later needs every contributor's copyright, or their permission.
For example, Grafana moved from Apache-2.0 to AGPL-3.0 on 2021-04-20. Its public reading shows the change with the licence file behind each side.
BUSL-1.1
The Business Source License publishes the source but restricts its use. Anyone may copy, change and run it outside production. Production use is allowed only as far as the licensor's Additional Use Grant says. Each version converts to an open licence, the Change License, on its Change Date: the date the licensor names, and at most four years after that version was first published.
A Borehole report states it as: source available, not open source; production use restricted until the change date.
- Read the Additional Use Grant. It is the part that varies. Many grants allow any production use except a product that competes with the licensor. Whether the buyer's plans compete is a question of fact, and the licensor's reading of "compete" may differ from the buyer's.
- Date each version. Each version has its own Change Date. A version old enough is already under its Change License; the newest is not.
- The product itself is BUSL. The licence protects the hosted business, and the buyer inherits that protection. The old open versions stay open, and a fork of them can compete.
For example, HashiCorp moved Terraform from MPL-2.0 to BUSL-1.1 on 2023-08-10 (its public reading). The last open version became OpenTofu, a fork that competes with it.
SSPL-1.0
MongoDB wrote the Server Side Public License from the AGPL's text, and rewrote section 13. If you offer the program's functionality to others as a service, modified or not, you must publish the source of everything used to run that service: management software, user interfaces, APIs, automation, monitoring, backup, storage and hosting. The Open Source Initiative did not approve it, and it is not open source.
A Borehole report states it as: source available, not open source; offering it as a service obliges publishing the whole service stack.
- Used internally. Running an SSPL database behind the product, where customers never reach the database's own functionality, is the use the licence leaves alone.
- Offered as a service. A product whose value is the SSPL program, hosted for customers, would have to publish its whole service stack. In practice that use needs a commercial licence from the licensor.
- The product itself is SSPL. As with BUSL, the licence protects the hosted business, and the open versions before the change can be forked.
For example, Redis moved from BSD-3-Clause to a choice of RSALv2 or SSPL-1.0 on 2024-03-20, and added AGPL-3.0 as a third choice on 2025-05-01 (its public reading). Valkey, a fork of the last BSD version, competes with it.
Their relatives
Other source-available licences restrict the same uses in different words. A Borehole report states each one from its own terms:
- Elastic License 2.0: source available, not open source; offering it as a managed service is not allowed.
- Redis Source Available License 2.0 (RSALv2): source available, not open source; offering it as a managed service or in a competing product is restricted.
- Functional Source License (FSL-1.1-ALv2): source available, not open source; a competing commercial product or service is not allowed; each version becomes Apache-2.0 two years after its release.
How to find them in a repository
- The project's own licence. Read the root licence
file and every SPDX header.
ls LICEN[CS]E* COPYING* 2>/dev/null git grep -h 'SPDX-License-Identifier' | sort | uniq -c | sort -rn
- Its history. Code taken under an earlier licence
stays under it. Date every change to the licence file.
git log --diff-filter=ADMR --date=short --format='%h %ad %s' -- 'LICEN[CS]E*' 'COPYING*'
- Committed third-party code. Vendored libraries
bring their licence files with them. Search for the three by name.
git grep -l -i -e 'GNU AFFERO GENERAL PUBLIC' -e 'Business Source License' -e 'Server Side Public License'
- Dependencies fetched at build time. They are not
in the repository, so build a licence inventory and read every AGPL,
BUSL and SSPL entry.
npx license-checker --production --summary pip-licenses --order=license go-licenses report ./... cargo deny check licenses
- Who owns the contributions. Look for a
contributor licence agreement or an assignment. Without one, outside
contributors keep their copyright, and the code cannot be relicensed
without them.
ls CLA* .github/CLA* 2>/dev/null; git grep -il 'contributor license agreement' git log --format=%b | grep -c 'Signed-off-by' # a sign-off certifies origin; it is not an assignment
How often projects move to them
Borehole reads each public project's root licence file commit by commit. Of the 1,084 projects in its library, 272 changed their licence in a way that changes what users may do, and 140 of those narrowed it. Today 86 of them grant AGPL-3.0, 17 BUSL-1.1 and 3 SSPL-1.0, alone or as one choice among several. Every licence change in the library is listed on one page, newest first.
What Borehole reads
Borehole reads a repository the way a buyer's engineer does. It reads the git history and working tree, runs 106 diligence checks, and rates it on 7 dimensions, licences among them. On licences it reads:
- the root licence file, commit by commit: every change, when it narrowed rights, and whether the terms now are open source
- the licence files of third-party code committed to the repository, against the project's own licence
- whether the package manifest and the licence file agree
- vendored code that arrived with no licence at all
It reads the licences in the repository. Dependencies fetched at build time are not there, so run the inventory above for those. Every finding cites its evidence, and what the code cannot answer becomes a question for the room.
- A public repository. Paste its address. The survey is free.
- A private repository. The collector reads it on
your machine, and your repository stays there. What it sends:
never whole files; facts and short excerpts of up to 120 characters where a check matched. The dry run prints everything a survey would send, and
sends nothing.
pip install borehole borehole collect . --dry-run # prints everything that would be sent, sends nothing borehole collect . # sends it, returns a report
A survey of a private repository spends a Report key. A Borehole Report costs €249 launch price · €499 after launch. What happens to your code lists everything the collector sends.
The check on one page
- Read the root licence, every SPDX header and the licence history
- Search committed code for AGPL, BUSL and SSPL licence files
- Build a licence inventory of build-time dependencies
- AGPL: is it modified, and how is it combined with the product?
- BUSL: what does the Additional Use Grant allow, and when does each version change licence?
- SSPL: does the product offer it as a service?
- The product's own licence: who owns the outside contributions?
- A relicence: the old versions stay open, and forks of them compete
The technical due diligence checklist covers everything else a buyer checks, and preparing for due diligence is the seller's side.