Dual Licensing: AGPL and Commercial Terms

An operations product I maintain ships under exactly this model: AGPL-3.0 in the LICENSE file, a paid commercial license offered right next to it. The model is smaller and more boring than most founders expect. That's a compliment.

I've written about open-source licenses from the consumer's side: what you owe when other people's code ships inside your product. This is the other chair — you built the product, you're releasing it as open source, and you'd like the businesses profiting from it to pay.

Why AGPL is the vendor's copyleft

Release a serious product under MIT and the biggest risk isn't obscurity. It's a hosting company taking your code, running it as a closed SaaS, contributing nothing back, and outselling you on your own work.

GPL obligations are principally triggered by distribution; a server-side SaaS may not distribute the covered code, though browser code or client binaries can change that analysis.

AGPL section 13 adds a source-offer requirement when you modify the program and users interact with that version remotely over a network. Offer Corresponding Source to those users; this is not an automatic requirement to publish every independent service in your business.

A commercial license is useful where the buyer cannot meet the applicable AGPL obligations. Commercial use itself is permitted by AGPL, and a paid license does not remove obligations inherited from third-party dependencies.

The model offers two sets of terms. Commercial users may comply with AGPL without buying a separate license; buyers pay for different rights over code you are entitled to relicense.

The mechanics: two files, not a legal department

The implementation is deliberately unimpressive. The repository carries the full, unmodified AGPL-3.0 text in LICENSE. Never a home-brewed copyleft — it scares lawyers on both sides.

Next to it sits COMMERCIAL.md, a page that says three things. The product is available under AGPL. Separate commercial terms are available for buyers whose intended integration cannot comply with the applicable AGPL obligations; assess the actual use rather than assuming every SaaS requires them. Here's the contact: describe your use case and deployment.

Keeping that file short is the point. Its job is to start a conversation, not to be the contract. Scope, pricing, and terms belong in the agreement you actually sign, tailored to how the buyer deploys.

NOTICE discipline: your own dependencies

Selling licenses puts your own compliance under a microscope. A vendor who monetizes copyleft while ignoring the copyleft in their dependency tree has no standing.

The product I maintain depends on LGPL libraries — python-telegram-bot under LGPL-3.0, paramiko under LGPL-2.1 — alongside the usual permissive stack. So the repository carries a NOTICE file: every third-party component, its copyright line, its license, its URL.

That file earns its keep twice: it satisfies the attribution side of your obligations. The swappability side of LGPL is its own topic, covered in LGPL dynamic linking in vendor products. And it answers the first question every commercial buyer's legal team asks — "what exactly is in this?" — before they ask it. A due-diligence checklist that gets a maintained NOTICE file in response tends to get much shorter.

What commercial buyers actually ask

The inquiries that convert follow a pattern, and having answers ready is worth real money:

1. Scope — is the license per instance, per site, or company-wide? Pick a unit that matches how your product deploys.
2. Coverage — does the license cover their modifications? Redistribution to their clients? Say so explicitly.
3. Dependencies — the NOTICE file, plus confirmation nothing in the tree forces obligations the commercial license claims to remove.
4. Support and updates — keep the license grant and the maintenance agreement separate; they have different lifetimes.
5. Warranty and indemnity — AGPL includes warranty and liability disclaimers subject to its terms and applicable law; commercial buyers often pay specifically to have someone stand behind the code.

Contributors decide your future options

The quietest trap in dual licensing: the moment you merge an external pull request under AGPL alone, that contributor's code is AGPL. You no longer have the right to sell commercial exceptions covering it. The ability to offer different terms depends on ownership or a sufficient relicensing grant for the covered code.

The options are standard — a CLA granting you relicensing rights, or keeping external contributions out of the dual-licensed core. What matters is choosing before the first outside PR arrives. Untangling it afterwards means chasing signatures from people who may have vanished.

The takeaway

Dual licensing is a funding model for open source, not an attack on it. AGPL requires source access when its conditions apply; it does not prohibit others from profiting from compliant use. Commercial terms can fund maintenance when buyers need different rights.

The mechanics fit in three files and one policy: a clean LICENSE, a short COMMERCIAL.md, a maintained NOTICE, and a contributor decision made on day one.