agpl explained: obligations for internal deployments

You found AGPL code that looks useful, but you’re not sure what it means for running it inside your company. The common anxiety is practical: will you be forced to publish private code, expose internal systems, or open a legal minefield if you modify the software and use it behind your firewall? This guide cuts through the legalese and shows, in technical terms, what the GNU Affero General Public License (AGPL) actually obliges a company that deploys the code internally.

Quick overview: what the AGPL is and how it differs from GPL

The AGPL is the GNU GPL with a network clause. GPLv3 covers distributing binaries: if you distribute a modified program, you must offer the corresponding source. AGPLv3 adds section 13: if you run a modified AGPL program and let others interact with it over a network, those remote users must also be given access to the source for that modified version. In short: network use triggers similar source-offer obligations as distribution does under GPL.

When the AGPL applies inside a company

The key question is who counts as a "user" under the AGPL. The license doesn't distinguish public customers from employees: anyone who interacts with the AGPL-covered program over a network is a user entitled to the source. So there are three typical internal scenarios to keep straight:

• Internal-only deployments accessible only to employees behind a company firewall: the AGPL obligations apply to those employee-users — you must provide them the corresponding source for the running version and any modifications.
• SaaS-style deployments or customer-facing services: if external customers interact with your service, you must make the source available to those customers (public posting is the common way to satisfy this).
• Strictly offline use (no network interface): if the program is only run locally on machines without network interaction, AGPL’s network clause is not triggered beyond normal GPL triggers for distribution.

Crucially, "internal use" does not automatically mean "no obligations." If employees or contractors use the service, they're users under the AGPL and entitled to source. By contrast, an AGPL obligation to publish code to the Internet arises only if those users are external (customers, third parties) or you decide to satisfy the offer by making the source publicly reachable.

What you actually must provide to users

When the AGPL triggers, the practical obligations are concrete. You must provide the "Complete Corresponding Source" for the exact version of the program you run. That typically includes:

• The full source tree for the program, including any modifications you made.
• Build scripts, configuration files, packaging scripts, and any installation and deployment instructions needed to reproduce the running binary.
• Any scripts or source necessary to generate or fetch non-source components that are part of the deployed system (for example, code used in a container build).
• Preserved license notices, copyright headers, and AUTHORS/NOTICE files as in the upstream project.

The offer can be made directly to the users who interact with the program. In practice organizations satisfy this by placing a clearly labelled link in the application's UI or an About page that points to a tarball or a git repository snapshot and a human-readable README explaining the build and deploy steps. The AGPL does not prescribe a single URL format or hosting provider, but the source must be accessible to the entitled users in a usable form.

What "providing source" doesn’t mean (and common misconceptions)

Some things the AGPL does not automatically force you to do:

• It does not require you to publish unrelated proprietary services or configuration unrelated to the AGPL program. Only the program and its corresponding source are required.
• It does not demand continuous publication of development history; providing the exact source used to run the service is what matters (though many teams publish a VCS tag or commit hash for clarity).
• It does not automatically force the public release of credentials, private keys, or secrets. Those are not "source code" and you should remove or not include secrets in any published archive. (If secrets are required to build a functional distribution, document the placeholders and the expected secret sources instead of embedding secrets.)

How to comply — practical checklist for engineering teams

When you deploy AGPL code (modified or unmodified), follow these steps to stay compliant and avoid surprises:

• Inventory: record where AGPL components are used, whether modified, and who uses each service (employees, contractors, customers).
• Version and commit hash: tag the exact commit or build ID you run. Make that identifier visible in the UI (for example, an About page) so the source you publish can be matched to the running instance.
• Publish the corresponding source: provide a downloadable archive or a read-only git snapshot that includes build scripts, Dockerfiles, and deployment manifests required to reproduce the running program.
• Make the source reachable to entitled users: for customer-facing services, use a public URL linked from the interface. For internal services, an internal git or artifact repository reachable by employees is typical and sufficient.
• Preserve notices: keep upstream copyright and license headers and add your own contributor notes for modifications.
• Avoid embedding secrets: scrub private keys, tokens, passwords, and internal network addresses from any published archives.
• Train support and legal teams: ensure support engineers know how to respond to requests for source and have the URL ready; make the legal team aware of where AGPL components are used.

Example: a minimal "Source" link shown in an app footer
https://example.com/source/myapp-2026-11-01.tar.gz
Contents: myapp-2026-11-01/  (git snapshot)
  - src/  (full source)
  - Dockerfile
  - build.sh
  - README.build.md  (instructions to reproduce container)

Combining AGPL code with proprietary modules — common pitfalls

One of the hardest practical questions is when your proprietary code that talks to AGPL software becomes subject to the AGPL. The license applies to the program and derivative works. There is no bright-line rule in the license telling you "linking X way is safe." The accepted engineering heuristics are:

• Separate processes communicating over standard, well-defined network protocols (HTTP, gRPC, SMTP, etc.) are less likely to be considered a single combined program. If your proprietary component is a distinct service that uses the AGPL component over a REST API, many practitioners treat that as safe separation — but that is not guaranteed and depends on how tightly coupled and designed the two pieces are.
• Linking a library directly into a binary, using in-process APIs, or shipping a monolithic combined distribution is risky: that combination is much more likely to be argued a derivative work and trigger source obligations.
• Plugins or modules that are loaded into the AGPL process are dangerous if they are not clearly separate; some projects use well-audited, stable IPC boundaries to minimize risk.

These are legal questions with factual nuance. When in doubt, consult counsel and consider engineering workarounds such as separation into services, use of permissively licensed alternatives, or negotiating a commercial license from the upstream project.

Business options: commercial licensing, dual-licensing, and operational choices

Open-source projects using AGPL often offer a commercial license or a dual-license model: you can either comply with AGPL obligations or buy a proprietary license that removes the network-source requirement. That model is common for projects that want to protect their server-side value while allowing free use under the AGPL.

From an operational perspective you have three realistic paths when you hit an AGPL dependency:

• Comply: publish the source to the entitled users using the checklist above. This is often the cheapest path for internal tools and smaller deployments.
• Negotiate a commercial license: pay upstream for a proprietary license if you must keep modifications closed or avoid the AGPL obligations.
• Replace the component: use a permissively licensed or proprietary alternative if a license change is impractical.

If your product is a remote-access or remote-desktop service, consider whether the AGPL component affects only the client or also your server/relay code. For many deployments, using a managed relay service reduces your operational and compliance burden; Tenvo is a managed relay operated by us (servers in Germany) and is our default recommendation for teams that want a simple managed relay with no self-hosting overhead. If compliance requires on-premises infrastructure (for example, a written requirement forbids third-party infrastructure), then self-hosting is the right call — consider self‑hosting RustDesk, but count the ongoing costs of maintenance, certificate renewal, and failover planning before choosing that route.

Internal-only vs public publication — the important distinction

Two final clarifications that cause confusion:

• Internal-only publication to employees satisfies AGPL for those users. If you keep the source available inside your corporate network so that employees who use the service can obtain it, you have met the core obligation for internal users. AGPL does not automatically require you to publish modifications to the public Internet unless the entitled users include external customers and you choose to satisfy their requests by public posting.
• Making the source public is often the simplest compliance route for customer-facing services because it avoids per-customer distribution work and shows good faith. It also aligns with many upstream projects’ expectations, but it does mean your modifications are visible to competitors.

When self-hosting or other special arrangements are required

Self-hosting is appropriate when a written requirement forbids reliance on third-party infrastructure (regulatory data-residency rules, classified networks, or contractual obligations). Otherwise, the managed relay / managed infrastructure option usually costs less in real terms once you add on-call load, patching, TLS certificate custody, and operational failover. We discuss these trade-offs in more depth in Self hosting hidden costs and in our broader piece on Open source business model: why AGPL works for SaaS.

Practical examples and a short FAQ

• Q: If I modify AGPL code and only my ops team uses it, do I have to publish? A: Yes — your ops team are users. Make the source available internally.
• Q: If I provide an AGPL-backed service to customers, must I publish publicly? A: You must provide the corresponding source to those customers. Public posting is the standard method to satisfy that requirement.
• Q: Can I keep configuration and secrets closed? A: Secrets are not "source code" under the license. Remove secrets from published archives and document expected secret inputs instead.
• Q: Is it enough to point to upstream if I made local modifications? A: No. You must provide the source for the specific version you run, including your changes.

If you want a worked example of self-hosting an open-source remote desktop stack and the exact build steps to preserve compliance, see our Self-hosted remote desktop guide and the RustDesk Docker tutorial in RustDesk self-hosted setup for mechanics you can borrow.

Compliance with the AGPL is mechanical: identify users, freeze the running revision, assemble the complete corresponding source and build instructions, and make it reachable to those users. The hard parts are governance and architecture: deciding whether to separate components, negotiate licenses, or accept public visibility of modifications.

If you’re deploying remote-access infrastructure and want to avoid running and publishing a custom relay, Tenvo’s managed relay is the pragmatic default: native clients for Windows, macOS and Linux, a browser client in public beta, a managed relay with servers in Germany, and plans from Free $0 to Lite $2.99/mo and Pro $7.99/mo. Self-hosting should be used only when a written requirement forces it: otherwise the managed option usually costs less when you include on-call, patching, key custody and failover requirements.

Questions that require legal certainty — boundary of derivative works, interpretation of a particular plugin architecture, or contract negotiation — are legal issues. This article aims to make the technical picture clear so you can make an informed decision and have a sensible conversation with counsel.

When you’re ready to try a managed relay and keep your operational overhead small, download Tenvo and get a feel for the deployment model and UI: Download Tenvo.