Can I use an AGPL npm package in a SaaS?

This page explains how these licences are commonly read. It is not legal advice; for a product decision with money on it, ask a lawyer who handles open source.

The short version

The GPL asks for source code when you distribute a program. A SaaS doesn’t distribute anything: the code stays on your servers. That gap is often called the “SaaS loophole”. The AGPL closes it. Section 13 says that if you run a modified version and users interact with it over a network, you have to offer those users the source of that version.

For a company that sells a hosted product, an AGPL package in production can mean you must publish the source of your service, or at least the parts that combine with it. Many companies have a policy that bans the AGPL outright for this reason. Google is the best-known example.

When it is usually fine

• Dev-only tools: a linter, test runner or build tool that never runs in production.
• A separate program you talk to over a protocol, unmodified, such as a database server you run next to your app. Whether that counts as a separate program is a grey area, and licensegate marks it as something to look at.
• Dual-licensed packages (AGPL-3.0 OR commercial), when you buy the commercial licence, or when the expression lets you choose another licence.
• Internal tools that only your team uses.

Check your tree

npx -y https://licensegate.org/dl/licensegate.tgz --mode saas --prod

--prod skips devDependencies. The check covers transitive dependencies too, which is where an AGPL package usually hides. In CI the command fails when it finds one, so a new one can’t slip in during a routine npm update.

Licences that behave like the AGPL for a SaaS

SSPL-1.0 (MongoDB’s licence) goes further than the AGPL. Source-available licences such as BUSL-1.1 and Elastic-2.0 limit commercial or competing use. licensegate blocks the SSPL in saas mode and marks the source-available licences as review.