In the last three years, I made over $300K from a simple JavaScript library called lightGallery using dual licensing. Here is everything you need to know about monetizing your open-source project using dual licensing.
What is dual-licensing?
It is a business model where you offer your software under two different licenses
- A free, open-source license (GPL or AGPL)
- A paid, commercial license
When software is dual-licensed, users can choose the terms under which they want to use the software
How does this work?
If you choose the free GPL license and use the GPL-licensed code in your project, as per GPL terms, you’ll have to open-source your entire project.
For instance, if a company uses your GPL-licensed JavaScript on their website, they must release their entir website’s source code.
Most companies cannot do this. So, they purchase a commercial license from you, which gives them the right to use the code in closed-source projects.
That is the core of the business model.
Choosing the Right License: GPL vs. AGPL
The key is understanding what triggers the open-source rules.
GPLv3: Best for libraries and frameworks. It is triggered by distribution. If someone includes your GPL’d JavaScript on their public website, they must open-source their entire site.
AGPLv3: Best for SaaS products. It closes the “SaaS loophole” where code is used on a server but never distributed. AGPL is triggered when a user interacts with the software over a network
Handling Contributions: This is CRITICAL
You cannot sell or relicense code you don’t own. When others contribute, you need the legal rights to their code.
You have two main options:
- CLA (Contributor License Agreement): Contributors let you use their code. They still own it.
- CAA (Copyright Assignment Agreement): Contributors transfer ownership of the code to you.
For a dual-licensing 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 have other contributors, you must get their permission to re-license their code. If they refuse or do not reply, you have to 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 old license. Give people a strong reason to upgrade by shipping the new version with an exclusive set of new features.
Final thoughts
Dual licensing is a proven strategy, used for decades by major players like Oracle. It is a reliable business model you can confidently apply to your own projects.
A quick note: I’ve simplified many concepts for clarity, and this article does not constitute legal advice. Always consult with a lawyer when setting up your licensing
If you need any help monetizing your open-source project, feel free to DM me on X. I’ll try to help as much as I can.