What is the dual-licensing business model?
It is a proven commercial open-source strategy where you offer your software under two different licenses:
- A free, copyleft open-source license (GPL or AGPLv3)
- A paid, commercial license for proprietary use
When software is dual-licensed, users can choose the legal terms under which they want to use the software.
How does this work?
If a developer chooses the free GPL license and includes that code in their project, as per GPL terms, they are often required to open-source their entire project.
For instance, if a company uses your GPL-licensed JavaScript on their website, the viral nature of the license may require them to release their entire website’s source code.
Most enterprise companies cannot do this. To remain compliant, they purchase a commercial license from you, which gives them the right to use the code in closed-source, proprietary projects. This is the core of the business model.
GPL vs. AGPLv3: Choosing the Right License
The key is understanding what triggers the open-source requirements.
GPLv3: Best for libraries and frameworks. It is triggered by distribution. If someone includes your GPL’d JavaScript on a public website, they must remain license compliant by open-sourcing their site or buying a license.
AGPLv3: Best for SaaS products. It closes the “SaaS loophole” where code is used on a server but never distributed. AGPLv3 is triggered when a user interacts with the software over a network.
Handling Contributions
For a successful dual-licensing model, you cannot sell code you don’t own. When others contribute, you need the legal rights to re-license their work.
You have two main options:
- CLA (Contributor License Agreement): Contributors grant you permission to use their code. They still own it.
- CAA (Copyright Assignment Agreement): Contributors transfer ownership of the code to you.
For a commercial open-source (COSS) model, the CAA is the safest option. You can use bots like CLA Assistant on GitHub to automate signing before you merge any pull requests.
Switching an Existing Project to Dual License:
If you are moving from a permissive license (like MIT) and have other contributors, you must get their permission to re-license. If they refuse, you must remove their contributions.
Release the new version under a new major version (e.g., v3.x → v4.0). This prevents users from accidentally breaking license compliance when using package managers like NPM. Old versions remain free under the original license, so give users a strong reason to upgrade by shipping the new version with exclusive features.
Final thoughts
Dual licensing is a reliable business model used for decades by major players like Oracle and Qt. It is a sustainable way to fund open-source development while building a profitable side project.
A quick note: I’ve simplified these concepts for clarity, and this article does not constitute legal advice. Always consult with a lawyer regarding your specific licensing and SaaS tax compliance.
Also, if you are looking for an easier way to sell your software globally, check out Kelviq We handle license delivery, key generation, taxes, and compliance for 3.5% per transaction.