In the last four years, I made over $350K from a simple JavaScript library called lightGallery using a dual-licensing business model. Here is everything you need to know about monetizing your commercial open-source software (COSS) project using dual licensing.
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: This is CRITICAL
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.
License delivery and payments
I use kelviq to handle license file delivery, license key generation, and checkout.
As soon as a customer purchases the product through Kelviq, it generates a unique license key for that customer and sends the license agreement by email.
Kelviq charges 3.5% per transaction while handling taxes and compliance as well. It also generates a customer portal where customers can download their license agreement and invoices later.
Full disclosure: I’m a co-founder of Kelviq. We built it specifically to make it easier to sell software globally.
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.
If you need any help with open-source monetization, handling a Merchant of Record (MoR), or setting up license fulfillment, feel free to DM me on X. I’ll try to help as much as I can.
