Dual licensing means releasing your software under two (or more) different licenses. Typically, one of those is an open source license and the other is a proprietary/commercial license. This setup can sound contradictory, but it’s a common business model that allows the best of both worlds: you maintain an open source project to get community adoption and contributions, while also offering a separate proprietary license to customers who want to use your software under different terms (usually to avoid the copyleft requirements).
When might you choose dual licensing?
- You want to offer a copyleft license and allow commercial exceptions. The classic scenario is a project that’s GPL licensed to the public, but if a company wants to use it in a proprietary product without GPL obligations, they can purchase a commercial license from you. For example, MySQL for many years was dual-licensed: GPL for the community, and a paid proprietary license for those who wanted to embed MySQL in closed-source software. This way, the code stays free for open source users, but you monetize commercial use. This model only works well if you own all the code (or have contributors sign agreements) so that you have the rights to license it under different terms. It’s popular with companies that develop open source: they attract a user base via the open source GPL version, and if users can’t comply with GPL, they pay. As Heather Meeker explains, dual licensing often involves offering a choice between a copyleft open source license and a commercial license. AGPL or GPL is frequently used because its strong copyleft encourages companies to seek a commercial license instead if they don’t want to open source their own code. (If you dual-licensed under, say, MIT and proprietary, no one would buy the proprietary one because MIT already lets them do anything.)
- You want to license the same code under two open source licenses to maximize compatibility or adoption. This is less common but does happen. For example, your project could be made available under GPLv2 or Apache 2.0 and recipients can choose which license they prefer. Why do this? Perhaps to allow the code to be used in both GPL projects and Apache-licensed projects that wouldn’t mix otherwise. Another case: libraries sometimes dual license under a weak copyleft and a stronger copyleft, or a non-reciprocal and a copyleft, allowing downstream users to pick what suits them. Mozilla initially dual-licensed some of its code under MPL and GPL/LGPL to ensure it could be combined with GPL code. Using multiple open source licenses (multi-licensing) can ensure broader compatibility. But note, maintaining two licenses can be confusing; you have to clearly mark which license applies or if it’s “either/or.”
- Open core or add-on licensing models: Some companies keep a core of the software under one license and dual-license certain components or plugins. Dual licensing doesn’t strictly mean one file under two licenses (that’s multi-license); it could also mean offering a product under an open source license with an alternative proprietary version that includes extra features. That strays into the territory of the open-core model, which is a business strategy: basic version is FOSS, advanced version is proprietary.
In any dual licensing scenario, an important practical point is that you (or your organization) must have the rights to do it. This usually means you either are the sole author or you require contributors to sign a Contributor License Agreement (CLA) or give you joint copyright, so that the project maintainers can relicense contributions as needed for the proprietary offering. Without that, if many people contributed under one license, you cannot later offer their code under a different license without permission.
Pros of dual licensing:
- You can serve both the open source community and paying customers. For example, small developers use it under GPL for free, but enterprises not wanting GPL obligations pay for a commercial license.
- It can provide a revenue stream to sustain development of the open source project (common in some database companies, etc.).
- It can also be used to navigate license compatibility: e.g., to permit linking with GPLv2 code, you might allow a relicensing exception or dual license part of your code under GPLv2.
Cons of dual licensing:
- It’s more complex to manage. Users have to understand under which license they are obtaining the software.
- Some community purists might be less willing to contribute if they know their contributions might be sold under a proprietary license.
- If not done carefully, it can confuse users (e.g., “Is this library GPL or MIT? It says both…” – you have to clarify it’s either/or).
When to consider dual licensing? If you have a clear commercial exploitation plan and you’re okay with handling the legal overhead. If your project is small or purely community-driven for fun/knowledge sharing, dual licensing is usually unnecessary – a single open source license is fine. Dual licensing shines in scenarios where a company is driving development and wants to use open source as part of its business model. For individual developers, a simpler approach (like just one license) is typically easier.
Example of dual licensing: QT framework is available under GPL (and LGPL for some parts) for open source use, and under a commercial license for companies who don’t want to comply with GPL/LGPL. Another example: Oracle’s MySQL (as mentioned). These are “choice of license” models– the user picks either the open license or negotiates a commercial license. An example of multi-licensing for compatibility is Mozilla’s tri-license in early 2000s (MPL/GPL/LGPL) which they eventually simplified. Some projects might say “GPLv2 or LGPLv2.1 or MPL” to allow various uses.
