On 1 May 2025 Redis announced that Redis 8 is available under the AGPLv3 as an additional licensing option, after moving to source available licensing in March 2024. The post was updated on 23 May 2025. For SaaS companies it was a useful reminder: whether a dependency's license creates obligations for you depends on what you do with the code, not only on which license it carries.
This is a working guide, not legal advice. Ask counsel before you rely on it for a contract.
What's affected
Three behaviors trigger different duties.
Distributing a copy. The GPL's duties attach to conveying. GPLv3 defines it: "any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying." A pure hosted service does not convey the code. An on-premises installer, a container image you hand to customers, a mobile app or an SDK does.
Letting users interact over a network with a modified version. This is what the AGPL adds. Section 13 says: "if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version." Running an unmodified AGPL component as a backend service is a different case from modifying it and exposing that version to users. Your counsel decides where your architecture falls.
Using source available code. Redis's own post notes that the SSPL "is not truly open source because the Open Source Initiative clarified it lacks the requisites to be an OSI-approved license." Source available licenses can restrict offering the software as a service. Read each one separately.
The Redis case shows why licenses change under you. A component you adopted under one license may offer a different set of choices at the next major version, so your policy has to record which license you rely on for which version.
How to check if you're exposed
Pull license data from your SBOM. This works on any CycloneDX file:
jq -r '.components[] | select(.type=="library")
| (.licenses[]? | (.license.id // .license.name // .expression))' sbom.cdx.json \
| sort | uniq -c | sort -rn
On a one dependency Node project we generated for a comparison on 18 October 2026, this printed 66 MIT, 2 ISC and 1 BSD-3-Clause across 70 libraries, so one library had no license entry at all. That unlabeled entry is what you chase first.
What to do now
- Sort licenses into three lists: allowed (for example MIT, BSD, Apache 2.0), review (weak copyleft such as LGPL and MPL), and escalate (GPL, AGPL, SSPL, anything custom or missing).
- For anything on the escalate list, write down how you use it: unmodified or modified, linked or separate process, hosted only or shipped to customers.
- Check what you ship outside the SaaS. Containers, agents, CLIs, and mobile apps distribute code, so GPL duties may apply even if your core product never leaves your servers.
- Keep the notices. Most permissive licenses require you to keep copyright and license text. Generate a notices file from the SBOM at release.
- Record the license you rely on for dual or multi licensed components, and the version.
- Treat "no license found" as a blocker, not as free to use.
An OSPO you can run part time
The TODO Group publishes guides on creating an open source program office and on using open source code. You do not need a team to borrow the shape. For a small company, a light program is:
- One named owner, who can say no.
- One page policy: the three lists above, plus how exceptions work.
- One intake path: a pull request template for new dependencies that asks for license, maintainer and purpose.
- One review a quarter: the escalate list, new license changes among your dependencies, and any upstream contributions.
- One rule for contributing back: who may send a patch to an upstream project and under what employer terms.
How to avoid this trap
- Do not assume SaaS means copyleft never applies. Distribution and modification are separate triggers.
- Do not rely on a tool's license label alone. Check the license text for anything on the escalate list.
- Do not adopt a source available component without reading its terms on offering it as a service.
Why it matters
License risk rarely announces itself. It arrives as a due diligence question during a deal, a customer audit, or a vendor changing terms. A part time program that keeps three lists and one owner turns that moment into a lookup.
Try it yourself
Run the jq command on your largest repository's SBOM, move every unlabeled and copyleft entry onto the escalate list, and write one sentence about how you use each.
Click through it at your own pace, or open it full screen.
Quick check
Does hosting an unmodified GPL component as a network service convey it under GPLv3?
No. GPLv3 says mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
What does AGPL section 13 add?
If you modify the program, you must offer remote network users the Corresponding Source of your modified version.
What should you do with a component whose license is missing from the SBOM?
Treat it as unknown and escalate it until you have confirmed the license from the source.
