Dual-Licensing Open Source Projects: A Practical Guide for Developers

You published your library under a copyleft license and the bug reports are rolling in — but so are emails from companies asking if they can use it in their closed-source product without triggering the share-alike requirement. You want to say yes, but not for free. That's exactly the problem dual-licensing solves.

Dual-licensing lets you offer the same codebase under two different licenses simultaneously: one for the open source community, one for commercial users who need different terms. Done right, it funds your project without alienating contributors.

What you'll learn

• How dual-licensing works and why companies are willing to pay for it
• Which open source license to use as the public-facing tier
• How to structure the commercial license and pricing approach
• What contributor license agreements (CLAs) are and why they're non-negotiable here
• Common mistakes that break dual-licensing models before they start

Prerequisites

This article assumes you own or control an open source project (a library, framework, or tool) and have at least a passing familiarity with software licensing concepts. You don't need a law degree, but you should be prepared to consult a lawyer before publishing a commercial license agreement.

How Dual-Licensing Actually Works

The core idea is straightforward: your project has one codebase and two license tracks. Any user can take the code under the open source license — usually a strong copyleft license like the GNU GPL — with all the freedoms and obligations that entails. A commercial user who can't accept those obligations (typically because they can't open-source their own product) can instead buy a commercial license that removes those restrictions.

This model is sometimes called open core when the two tiers differ in features, but dual-licensing keeps the codebase identical. The only thing that changes is what the licensee is allowed to do with it. MySQL (now owned by Oracle), Qt, and MongoDB's older versions all used variations of this approach.

The reason it works commercially is that copyleft is a genuine business constraint. A company shipping a SaaS product or a proprietary device doesn't want its entire codebase subject to GPL disclosure requirements. Paying for a commercial exception is far cheaper than rewriting your library from scratch.

Choosing the Right Open Source License for the Public Tier

The copyleft strength of your public license is what creates the commercial incentive. If you pick a permissive license like MIT or Apache 2.0, there's no reason for anyone to pay you — they can already use the code in proprietary software for free.

Your main options in the copyleft family are:

• GNU GPL v2 / v3 — The classic choice. Any software that links against your library and is distributed must also be GPL. This is what MySQL used and it's well-understood by corporate legal teams.
• GNU AGPL v3 — Extends GPL to cover network use. If a company runs your library as part of a SaaS backend, AGPL requires them to release their source even if they never distribute a binary. This is a much stronger trigger and works well for server-side tools.
• LGPL — A weaker copyleft that only requires derivative works of the library itself to stay open. This is usually too permissive for a dual-licensing strategy — it gives most commercial users a free pass already.

For most server-side libraries and developer tools, AGPL v3 is the better public tier today. The SaaS loophole in GPL means companies can run your software commercially without triggering GPL at all, which undercuts the whole model.

Structuring the Commercial License

The commercial license is a private contract between you (or your company) and the customer. At minimum it needs to cover:

• Scope — What the licensee is permitted to do that the open source license prohibits. Usually: incorporate the library into proprietary software, distribute it without source, and use it in a hosted SaaS product without triggering AGPL.
• Grant of rights — Whether the license is per-developer, per-product, per-company, or per-deployment. Per-developer seats are the easiest to sell to small teams; enterprise deals are usually per-company.
• Term and renewal — A perpetual license for a one-time fee is simpler to sell but produces lumpy revenue. Annual subscriptions are harder to close but more predictable.
• Warranty disclaimer and liability cap — You almost certainly want to disclaim warranties and cap liability at the amount paid. This is standard; any lawyer will insist on it.
• Support terms — What, if anything, you're obligated to provide. Many small maintainers separate support into a separate paid tier rather than bundling it.

Don't write this yourself from scratch. Find a template from a recognized open source business (several maintainers publish their commercial license templates publicly) and have a lawyer review it before you start selling. The cost of one hour of legal review is trivial compared to a dispute over ambiguous language.

Contributor License Agreements: The Non-Negotiable Part

Here is where many dual-licensing projects fail quietly: if you accept contributions from the community, those contributors hold copyright in their contributions. You cannot relicense their code under your commercial license without their permission.

A Contributor License Agreement (CLA) is a legal document that each contributor signs before their code is merged. It grants you (the project owner) the right to relicense their contribution, including under proprietary terms. Without it, your commercial license is legally broken the moment a third-party contribution lands in the repo.

There are two common CLA shapes:

• Copyright assignment — The contributor transfers copyright entirely to you. Gives you maximum flexibility. Contributors sometimes resist this because it feels like giving away their work permanently.
• Broad license grant — The contributor keeps their copyright but grants you a broad license to sublicense the code however you see fit. This is the more contributor-friendly option and is used by projects like the Apache Software Foundation.

Automate CLA signing. Tools like CLA Assistant integrate with GitHub pull requests and block merges until the contributor has signed. This removes the manual overhead and creates a clear audit trail.

If you already have contributions in the repo without a CLA, you have a few options: contact existing contributors to retroactively sign a CLA, rewrite the affected code yourself, or accept that those contributions must stay under the open source license only. Many maintainers do a gap audit before launching commercial licensing and are surprised how much of the code is still solely theirs.

Pricing and Selling the Commercial License

Pricing open source commercial licenses is more art than science, but a few principles hold:

Anchor off the value your library provides, not the cost of building it. If your library saves a company's engineering team two weeks of work, a license priced at a fraction of that labor cost is easy to justify internally. Per-developer-seat pricing between a few hundred and a few thousand dollars annually is common for developer tools.

Publish your pricing publicly if you can. Hidden pricing creates friction and signals that you negotiate on every deal, which discourages smaller companies from self-serving. A public pricing page with tiers lets the buyer qualify themselves.

Offer a clear upgrade path from the open source tier. Many commercial conversions start because someone at a company is already using the library under AGPL and their legal team flags it during a compliance review. Make it easy for that person to find your commercial license page and buy without involving sales.

Setting Up Your Repository for Dual-Licensing

The repository itself needs to make the licensing situation unambiguous. Ambiguity leads to people accidentally using the code under terms they didn't intend — or you losing a potential sale because a buyer couldn't find the commercial option.

Practical steps:

• Place the open source license in a LICENSE file at the root, as usual.
• Add a COMMERCIAL_LICENSE file or a LICENSES/ directory if you want both texts present.
• Update the README with a clear section explaining the dual-licensing model, who needs a commercial license, and a link to purchase or contact you.
• Add an SPDX-License-Identifier header to each source file. For dual-licensed code this is typically just the open source identifier (e.g., AGPL-3.0-only) since the commercial license is a separate agreement, not embedded in the file.
• Create a dedicated page on your project website or documentation that explains the two tiers, answers common questions, and links to the commercial license purchase flow.

# Licensing

This project is available under two licenses:

**Open Source (AGPL v3):** Free for open source projects and personal use.
See [LICENSE](./LICENSE) for the full text.

**Commercial License:** Required if you use this library in proprietary
software or a hosted SaaS product. See [COMMERCIAL_LICENSE](./COMMERCIAL_LICENSE)
or visit https://example.com/commercial for pricing and purchase.

Common Pitfalls

Accepting contributions without a CLA. Already covered above, but it's worth repeating because it's the most common failure mode. Set up CLA enforcement on day one, not after you've already merged 50 pull requests.

Choosing a copyleft license that's too weak. If LGPL is sufficient to let most of your target customers use the library without buying a commercial license, you've removed your own leverage. Review the exact obligations of the license you pick against your users' actual deployment patterns.

Making the commercial terms hard to find. If a company's legal team goes looking for your license terms and can't find a clear commercial option, they'll often tell the engineering team to stop using the library rather than chase down a maintainer over email. Visibility converts customers.

Neglecting the open source community. Dual-licensing works long-term only if the open source version remains genuinely useful and actively maintained. If it feels like the community is being milked for free marketing while all the real value ships in a paid tier, contributors leave and the ecosystem shrinks.

Not separating legal entities properly. If you're operating commercially at any real scale, consider creating a company to hold the IP and sign commercial agreements. Doing this as an individual creates personal liability exposure and complicates taxes.

Wrapping Up

Dual-licensing is one of the few business models that lets you keep a project genuinely open while still getting paid for the value it creates. It's not a magic solution — it requires real legal groundwork and ongoing discipline around contributions — but it's a proven path that many successful projects have walked before you.

Concrete next steps:

1. Audit your existing repository to determine what percentage of the codebase you solely authored. Identify any contributions that would need CLA coverage.
2. Evaluate whether AGPL v3 or GPL v3 is the right public license for your project's typical deployment scenario.
3. Set up CLA Assistant (or an equivalent tool) on your GitHub repository before you merge any new external contributions.
4. Draft a commercial license based on an existing open template and budget for a one-hour legal review before you start selling.
5. Write a clear licensing section in your README and project website that explains both tiers and makes it easy for commercial users to find the purchase path.