By the fastCRW team · Engineering/licensing deep-dive · Last reviewed 2026-01-01
Not legal advice. This is an engineer-to-engineer explanation of how AGPL-3.0 works in practice for SaaS teams evaluating an AGPL dependency. For a binding answer about your specific situation, ask counsel. The goal here is to replace fear with an accurate mental model.
Why AGPL panics legal teams more than it should
"AGPL" triggers a reflexive "absolutely not" at many companies, usually based on a folk model: "if I touch AGPL software, I have to open-source my entire product." That folk model is wrong, and the wrongness costs teams real options — they reject genuinely free, fully-featured open-core tools in favor of metered closed-source SaaS for a reason that doesn't apply to how they'd actually use it. The accurate model is narrower and, once you hold it, AGPL stops being scary for the common cases.
The GPL family in one paragraph each
- MIT/Apache (permissive): do almost anything, just keep the notice. No obligation to share your changes.
- GPL-3.0 (copyleft on distribution): if you distribute the software (ship a binary to users), you must offer corresponding source. Crucially, running it on a server to provide a service is not distribution — this is the "ASP/SaaS loophole."
- AGPL-3.0 (copyleft on distribution and network use): identical to GPL-3.0, plus Section 13 closes the SaaS loophole: if you modify the software and let users interact with that modified version over a network, you must offer those users the modified source.
The entire AGPL fear reduces to misunderstanding Section 13. Read the next section twice.
The AGPL Section 13 trigger, precisely
The network-source obligation fires only when all of these are true at once:
- You modify the AGPL program itself (changed its source), and
- You run that modified version to provide functionality to users interacting with it over a network, and
- Those users are interacting with the AGPL program itself (not merely with your separate application that happens to call it).
If any one of these is false, the network-source obligation does not apply. That's the whole rule. Now apply it to the four ways a SaaS team actually uses an AGPL scraping engine.
The four real-world cases
Case 1 — You use the vendor's hosted API / Managed Cloud
You call api.fastcrw.com from your app. Copyleft obligation: none. You are a network client of their AGPL service. The AGPL obligation (if any) is theirs to satisfy as the operator of the modified version — it does not propagate to you, and it certainly doesn't touch your application's source. This is the single most important point: consuming an AGPL API places zero copyleft on your code.
Case 2 — You self-host the unmodified engine to power your product
You run the official AGPL binary inside your infra, your app calls it over localhost or your VPC, you ship nothing modified. Copyleft obligation: none on your application. You haven't modified the program, so Section 13's "modified version" condition is false. Your proprietary app that calls the engine is a separate work communicating at arm's length over a network/process boundary; the AGPL covers the engine, not your caller. (If you redistribute the unmodified engine binary itself, you provide the unmodified source — which is already public — and you're done.)
Case 3 — You modify the engine and use it only internally, no external network users
You patch the AGPL engine for an internal batch job; no outside user interacts with it over a network. Practically: you must be prepared to provide the modified source to anyone you convey it to, but a purely internal modified deployment with no external interacting users does not itself force publication. The obligation runs to the users who interact with the modified version over the network; if that set is "nobody outside your org," scope is limited. (Conservative teams still keep the modified source ready to provide on request — cheap insurance.)
Case 4 — You modify the engine AND expose that modified engine to external users over a network
You fork the AGPL scraper, change its behavior, and offer that as a service others hit. Now Section 13 fires: you must offer those users the corresponding modified source. This is the one case that matches the folk fear — and notice it requires you to be effectively re-distributing a competing modified engine, not building a normal product on top of an unmodified one. Most SaaS teams never do this on purpose.
The "your product" question, answered directly
"If my SaaS uses an AGPL scraping engine, do I have to open-source my SaaS?"
- Using the AGPL vendor's API → No.
- Self-hosting the unmodified engine behind your app → No (your app is a separate work calling it).
- Modifying the engine, using it only internally → No publication forced by the act itself; provide modified source to anyone you convey it to.
- Modifying the engine and offering the modified engine to your users over the network → You must offer that engine's modified source — but still not your unrelated application code.
In no case does AGPL-3.0 require open-sourcing your own application's proprietary code. The obligation, even in the strict Case 4, is scoped to the corresponding source of the AGPL program, not to everything in your repo. The "open-source your whole product" folk model never matches reality for normal SaaS usage.
Why a vendor would choose AGPL on purpose
AGPL on an open-core engine is not hostility — it's the mechanism that makes the "self-host the exact same software, free" promise legally durable. AGPL prevents a third party from taking the engine, improving it privately, and offering a closed competing hosted version without giving anything back. That protects the open core from being strip-mined, which is exactly what protects your escape hatch: the engine can't quietly become closed-source on you. Permissive licenses allow the open-core bait-and-switch; AGPL structurally forbids it. For an infra dependency you're betting on, that's a feature.
The grey areas worth flagging to counsel
Honesty about limits (this is engineering analysis, not a legal opinion):
- Linking vs. arm's-length calls. Calling an engine over HTTP/IPC is widely treated as arm's length; statically linking AGPL code into your binary is a different, stricter conversation. Architect integration as a network/process boundary if you want the cleanest story.
- "Modification" edge cases. Config and plugins via documented extension points are generally not "modification of the program"; patching its source is. If you're near the line, document it.
- Corporate policy ≠ license law. Some companies ban AGPL by blanket policy regardless of these mechanics. That's a policy negotiation, and it's exactly why mature AGPL projects offer a commercial license.
When you actually need a commercial license
Get the commercial license if: company policy forbids any AGPL in the dependency graph; you intend to ship a modified engine inside a distributed/binary product; you want to embed and statically link it; or legal simply wants the AGPL question to not exist. fastCRW offers a commercial license for these cases. For the overwhelmingly common cases — calling the API, or self-hosting the unmodified engine behind your app — you do not need one, and the AGPL fear was, mechanically, never about your situation.
Bottom line
AGPL-3.0's network clause is narrow: it fires when you modify the program and offer that modified program to network users. Consuming an AGPL API or self-hosting the unmodified engine behind your own application carries zero copyleft on your code. For an open-core scraping engine, AGPL is the thing that keeps "you can always self-host the same software for free" structurally true — which is why fastCRW chose it, and why rejecting AGPL tools on the folk model usually means paying more for less freedom.
Try it without licensing anxiety
docker compose up # unmodified engine, no copyleft on your appOr call the Cloud API (also zero copyleft on you): one-time lifetime 500 free credits. fastcrw.com · GitHub
Related: Open source web scraping · Local-first scraping & data privacy · Self-host vs managed scraping