Dual Licensing From the Vendor's Chair: AGPL Plus a Commercial License

Dual Licensing From the Vendor's Chair: AGPL Plus a Commercial License

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 doesn't stop them either. GPL's obligations trigger on distribution, and a SaaS never distributes anything. The software runs on their servers; users only touch a browser.

AGPL closes that loophole. Serving the software over a network triggers the same source-sharing obligation as shipping it. For anyone willing to keep their derivative open, your product is genuinely free.

For anyone who wants to embed it in something closed — a proprietary integration, an internal fork they won't publish, a SaaS whose code stays private — the AGPL is a wall. The commercial license is the door through that wall, and the door has a price.

That's the whole business model: the license splits your users into two honest groups, and only the group extracting closed commercial value pays.

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 AGPL for open use. A commercial license without AGPL obligations is available for proprietary integrations, closed-source deployments, and SaaS products. 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 disclaims everything; 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 copyright-holder privilege that makes dual licensing work only covers code you hold the copyright to.

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 keeps the product open and un-freeridable; the commercial license converts closed-source use into revenue that pays for maintenance.

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.