SaaS backend
The code runs on your servers. Users receive responses, not binaries.
What actually happens
| Question | Answer |
|---|---|
| Does a third party receive the software in executable form? | No |
| Does a third party interact with it over a network? | Yes |
| Is the product a consumer good? | No |
One mechanism is active, and it is decisive: network interaction.
The verdict per family
| Family | Verdict | Reason |
|---|---|---|
| Permissive | ● | No distribution obligation; crediting remains good practice |
| Weak copyleft (MPL, EPL, LGPL) | ● | Reciprocity is conditioned on distribution |
| Strong copyleft (GPL-2.0, GPL-3.0) | ● | No effect. No distribution, no duty to publish |
| Network copyleft (AGPL-3.0, OSL) | ✕ | This is exactly the case they target |
| SSPL-1.0 | ✕ | Requires publishing the whole service stack |
| Elastic License 2.0, BSL | ○ | See below: depends on what the service is |
The two wrong intuitions
“The GPL will contaminate your SaaS”
No. The GPL triggers on distribution, and an online service distributes nothing. You can build an entire backend on GPL components with no obligation to publish a line.
It is the most counter-intuitive consequence in the field — so much so that many corporate policies ban the GPL in SaaS for no legal reason, denying themselves major components.
“The AGPL is just a slightly stricter GPL”
No. It is a change of nature. In this specific scenario the AGPL is the only family that can force you to publish your code — and the obligation covers the combined work, potentially your entire service.
How the AGPL bites, concretely
Three situations, in order of severity:
| Situation | Analysis |
|---|---|
| Strictly unmodified AGPL component, in its own process, called over a network interface | Section 13 targets the modified version. A defensible position, to be documented |
| Modified AGPL component, however slightly | Section 13 triggered on your version |
| AGPL library linked to your service code | The combined work becomes “your version”: the source of the whole is owed to users |
The third case is the most common and the most expensive. One import is enough.
The recommended internal rule. The AGPL is on the deny list for any component to be linked to service code. It moves to the review list — case-by-case, decision documented — for a component deployed unmodified in an isolated process, such as a database or a standalone infrastructure service.
Source-available licences in this scenario
They target managed service providers precisely. The question is not where the software runs but what you sell:
| Case | Elastic License 2.0 / BSL |
|---|---|
| The product is your offering, resold as a managed service | Prohibited — this is the targeted case |
| The product is an internal component of your platform, invisible to the customer | Generally allowed, verify against the exact text |
| The product is used to operate your infrastructure | Generally allowed |
Each licence in this family is drafted differently. There is no generic answer: read it, and have Legal decide.
Pitfalls specific to SaaS
The published container image. Pushing an image to a public registry — or to a private one a customer can reach — is distribution. Every dormant obligation wakes up over the image’s contents.
The agent, the connector, the client SDK. The day you ship any installable component, that component falls into another scenario. GPL in the backend has no effect; the same GPL in the agent is a publication obligation.
The on-premises edition. The most brutal mutation: the product moves from the most permissive scenario to the most constrained, carrying code built for years on the opposite assumption.
The frontend. The JavaScript served to the browser is distributed, whatever the backend does. See Web frontend — same product, different regime.
Exported code. A feature that generates and delivers code, a model or a configuration to the customer can carry licensed components with it.
What the CRA adds
Standalone SaaS falls under NIS 2, not the CRA. But a backend inseparable from a connected product is a remote data processing solution within the meaning of Article 3, and therefore sits inside the product’s scope — see Scope.
Consequence: its components belong in the SBOM and in the technical documentation, even where no licence obligation triggers. The inventory is owed for security reasons, not copyright ones.