The AGPL and SSPL Conundrum: Navigating Viral Copyleft and Restrictive Licensing in Commercial SaaS

The Hidden Legal Liability in `package.json`

When developers run `npm install` or `pip install`, they often evaluate libraries exclusively on utility, documentation, and GitHub stars. Rarely does an engineer audit the license headers of deeply nested transitive dependencies.

Yet, introducing a single package licensed under **GNU Affero General Public License (AGPL-3.0)** or the **Server Side Public License (SSPL-1.0)** into a proprietary cloud platform can carry serious legal consequences: requiring your company to open-source its proprietary codebase or face copyright infringement claims.

Permissive vs. Copyleft: The Spectrum

Licenses exist across a strict gradient of software freedom and restriction:

1. **Permissive (MIT, Apache-2.0, BSD-3-Clause)**:
2. **Weak Copyleft (LGPL-2.1/3.0, MPL-2.0)**:
3. **Strong Traditional Copyleft (GPL-2.0, GPL-3.0)**:
4. **Strong Network Copyleft (AGPL-3.0)**:

The AGPL Section 13 Network Interaction Clause

Section 13 of the AGPL-3.0 states:

*"Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network... an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge."*

If your engineering team imports an AGPL-3.0 storage adapter or PDF generation utility into your Node.js backend: - Is the entire backend considered a single "combined work"? - Does serving web pages or API JSON to external clients constitute "interacting with it remotely through a computer network"?

While legal definitions of derivative works vary by jurisdiction, major enterprise legal teams (including Google, Microsoft, and Amazon) enforce strict policies: **AGPL code is barred from production microservices.**

The Rise of SSPL and Source-Available Licenses

In 2018, MongoDB introduced the **Server Side Public License (SSPL)** after major cloud hyperscalers offered managed MongoDB services without contributing back upstream. Redis followed with the Redis Source Available License (RSAL) and SSPL, and Elastic transitioned Elasticsearch to SSPL before returning to dual-licensing.

Section 13 of the SSPL is even more comprehensive than AGPL:

*"If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, including the source code for all programs that you use to run the service (including management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software)..."*

If your product exposes an API backed by an SSPL dependency, distributing your proprietary orchestration and monitoring tooling may be required.

How DevAudit Automates SPDX Classification

DevAudit scans every root and transitive dependency against the standardized SPDX License List and flags compliance liabilities in sub-seconds:

import { classifyLicense } from '../licenses/classifier.js';

const license = classifyLicense('AGPL-3.0-or-later');

if (license.riskLevel === 'STRONG_COPYLEFT' && license.networkCopyleft) {
  triggerAlert({
    level: 'HIGH',
    package: 'ghost-storage-adapter',
    message: 'AGPL network copyleft detected. SaaS usage may require source code disclosure.'
  });
}

Best Practices for Engineering Teams

1. **Automate Pre-Merge Checks**: Block PRs that add packages with AGPL, SSPL, or unknown licenses via GitHub Actions or the DevAudit PR Guard.
2. **Standardize on Permissive Licenses**: Enforce MIT, Apache-2.0, or BSD-3-Clause for all backend microservices.
3. **Isolate Copyleft Utilities**: If an AGPL tool is unavoidable (e.g., an FFmpeg utility), isolate it behind a separate, standalone HTTP microservice with a well-defined boundary to minimize combined-work legal exposure.