open source business model: why AGPL works for SaaS

You maintain a useful open-source remote-access project and worry about cloud vendors copying it, offering it as a hosted service, and not contributing back. That scenario — the so‑called SaaS loophole — is why some teams choose the AGPL. This article explains what the AGPL actually does for a SaaS operator, how it shapes monetization choices, and the real operational tradeoffs, including relay hosting and managed vs self‑hosted deployments.

What the AGPL (Affero GPL v3) changes, in plain terms

AGPLv3 is GPLv3 plus a network‑use clause (often called Section 13) that requires you to offer source to anyone who interacts with the program over a network. In practice that means: if you run the server-side of an AGPL app and users interact with it via web or API, you must make your modified source available to those users. It closes the classic GPL 'SaaS loophole' where a company can modify code, run it as a hosted service, and never publish the changes.

That legal effect is narrow and concrete. It doesn't magically stop people from hosting your software, but it creates a legal obligation to share changes and gives licensors leverage when a third party repackages your code as a proprietary hosted product.

How AGPL supports SaaS business models

There are three practical business patterns where AGPL makes sense for a SaaS‑backed product:

• Dual licensing: Offer the code under AGPL for the community and sell commercial (proprietary) licenses to customers who need to embed or extend the code without AGPL obligations. This is the classic open-source business model for database and middleware vendors.
• Hosted add‑ons and managed infra: Keep the core protocol/code open under AGPL, then sell hosted services that are operationally hard to replicate cheaply — multi‑region relays, analytics, backups, or orchestration. Customers pay for the convenience, SLAs, and reduced ops burden.
• Support, SLAs, and enterprise features: The AGPL code stays open, but you monetize through paid support, training, custom integrations, or proprietary enterprise plugins served from a separate service boundary.

For remote‑desktop software specifically, the hosted relay is a natural product: relays carry bandwidth and require global presence for low latency. Selling a managed relay makes commercial sense while the client and server code remain AGPL.

Dual licensing: mechanics and realities

Dual licensing is straightforward in concept: you publish the project under AGPL, and you also offer a commercial license to customers who don’t want the AGPL obligations. The two key implementation points are contributor control and legal clarity.

Contributor control: to sell commercial licenses, you need a clean assignment or a Contributor License Agreement (CLA) that allows you to relicense contributor code. Without that, you can't lawfully sell a proprietary license that includes third‑party contributions.

Commercial pricing: expect early commercial licenses to be negotiated rather than listed. Many projects start with a modest hosted product (for example, a relay service) priced transparently — Tenvo's managed relay offering is an example of packaging the operational piece while keeping protocol code open — and reserve negotiated pricing for deeper integrations or on-prem installs.

Why a managed relay is often the default recommendation

Operational complexity is the silent cost of self‑hosting. A relay cluster needs TLS certificate management, monitoring, DDoS protection, multi‑region failover, bandwidth billing and on‑call engineers. For most commercial customers, buying a managed relay reduces time to value and predictable cost.

Tenvo's managed relay is offered multi‑region by default and bundled into our commercial plans: Free $0, Lite $2.99/mo and Pro $7.99/mo. For teams that want the simplicity and SLA, a managed relay usually costs less than hiring a full operations person once you account for patching, incident response, and certificate lifecycle.

Self‑hosting: when it’s the right call

Self‑hosting is absolutely the right choice when a written requirement forces it: regulations forbidding third‑party infrastructure, an isolated network with no internet egress, or strict data‑residency constraints that your managed relay cannot meet. In those cases the AGPL still works — and may even be preferable — but you must accept the ops costs: provisioning, HA, incident response, key custody and TLS certificate renewal.

If you're weighing self‑hosting, read the practical tradeoffs in our Self-hosted remote desktop: the honest 2026 guide — it walks through DNS, certificate automation, and baseline monitoring you can't skip.

Security and encryption: what the license doesn't change

Licensing doesn't change transport security. Architecturally, a direct peer‑to‑peer connection is end‑to‑end between the two devices. If a session falls back to a relay, TLS must terminate at that relay, so the relay operator is in a position to observe session traffic. That's an operational fact you must account for when selling hosted infrastructure or when customers ask about data exposure.

Be explicit about this in your product literature: describe when direct connections are possible, what fallback to relay implies, and what the relay operator can and cannot access. For a deeper treatment of remote desktop threats, see Remote Desktop Security: What You Need to Know.

Practical architecture: keep the monetizable parts distinct

When you choose AGPL, structure the project to separate the components you intend to monetize from the AGPL‑licensed core. Typical split patterns:

• Open core: Core client and protocol under AGPL; optional proprietary server components (for example, an advanced orchestration API) delivered under commercial license or SaaS.
• Service boundary: Put the hosted relay and operational services in a separate service that interacts with the open core over documented APIs. The relay can be proprietary or charged as a service while the core remains AGPL.
• Plugins vs core: Keep runtime, protocol and low‑level transport in AGPL; expose extension points where enterprise plugins (licensed commercially) can run in a controlled environment.

Architectural separation reduces legal ambiguity and makes it easier to explain to customers which parts are open and which are commercial services.

Developer and community tradeoffs

AGPL attracts contributors who want strong copyleft and community improvements, but it can deter corporations that refuse to accept network‑use obligations. Expect fewer inbound pull requests from companies that build proprietary SaaS — but community contributions from individual developers and institutions are often higher because they see the code will remain open.

To keep contributions healthy, have clear contribution docs, a CLA if you plan to dual license, and transparent governance. Many projects adopt a Transparent Governance policy, regular release cadence (e.g., monthly stable + nightly builds) and clear security disclosure processes to reduce friction for enterprise users.

Enforcement and reputation — the soft lever

Licenses are only as useful as you can enforce them. Enforcement can be legal, but often it's reputational: public callouts, polite outreach, and community pressure matter. High‑profile changes in the open source ecosystem (for example, the database vendors who moved to SSPL or source‑available licenses) show that license choices drive behavior — but enforcement requires resources and a willingness to litigate or litigate‑adjacent actions.

If enforcement is central to your model, be prepared: keep contribution histories, track deployers (to the extent you legally can), and budget for legal support. For many projects, the practical value of AGPL is deterrence and a clear route to negotiation rather than frequent courtroom fights.

Price and cost examples: realistic accounting

Real numbers vary, but consider these ballpark examples when choosing between managed and self‑hosted relay models:

• Small team using a single relay region with light bandwidth: managed relay at <$100/month is often cheaper than hiring ops time to run and secure it.
• Production service requiring multi‑region HA and 24/7 on‑call: replication, DDoS protection and egress bandwidth can push self‑hosting costs into the hundreds or low thousands per month. A managed relay with SLAs can be more cost‑effective once you include staffing.

These are rough ranges — capacity, egress volumes and compliance requirements change the math quickly — but the point is that the operational cost of a reliable global relay is not trivial, which is why packaging it as a paid service is economically rational.

Checklist: shipping an AGPL‑based SaaS responsibly

• Pick the license version explicitly (AGPLv3 recommended for most teams) and document what it covers.
• Use a CLA or contributor assignment if you plan to sell commercial licenses.
• Separate monetizable infrastructure (relays, orchestration, analytics) behind a clear service boundary.
• Document when sessions go through relays and the security implications (TLS termination at relay).
• Publish clear upgrade, install and hardening docs to lower friction for self‑hosters.
• Decide enforcement posture and budget legal resources or a mediation policy.
• Price hosted services with transparent tiers; Tenvo’s Free $0 / Lite $2.99/mo / Pro $7.99/mo model is an example of a simple entry funnel that scales into SLAed enterprise plans.

When to pick something else

AGPL isn't the right choice if your goal is maximum adoption by third‑party SaaS vendors or if you want permissive re‑use in closed systems without negotiation. For libraries intended to be embedded in proprietary products, permissive licenses (MIT/BSD/Apache 2.0) are usually better.

Also consider hybrid approaches: a permissive client library with an AGPL server, or permissive core with an AGPL reference server. Each choice sends a clear signal about the kinds of reuse you want to encourage or prevent.

Further reading and comparisons

If you want to compare the tradeoffs for remote‑desktop projects specifically, our fork‑and‑host comparison is a useful read: RustDesk vs Tenvo: fork comparison for self-hosters. And if you're making the self‑hosting cost/benefit call, recheck the operational steps in Self-hosted remote desktop: the honest 2026 guide.

Licensing is one lever among many. Choose AGPL when you need legal assurance that network users can access source and when you intend to monetize operational services, but be explicit with customers about what AGPL does and doesn't solve: it addresses code contributions and disclosure, not transport security or configuration mistakes.

Ready to try an AGPL‑backed remote access stack with a managed relay option? Download the client and experiment, or see pricing details and managed plans at our pricing page. When you want to get hands‑on, download and test a relay‑backed setup in minutes.