Dual-licensing, or multi-licensing is the practice of distributing source-code for a single project under two or more licenses. The general idea is pretty simple, however I’ve seen many people misunderstanding some important aspects when it comes to it. There’s especially a lot of confusion when it comes to multi-licensing a repository with a copy-left license, so in this article, I wanted to shed some light onto this practice, to hopefully make you a bit more confident in understanding, and maybe even maintaining multi-licensed projects.
Note
This article assumes that you already know the basics of how software licensing works, and that you’re familiar with the different types of licenses (permissive, (weak and strong) copy-left, public domain). If you aren’t sure you’re familiar enough with these topics, I’d strongly advice you to learn read about these before going through this article, as you will likely not end up understanding a lot of what I’m talking about here.
But don’t worry, I actually have an article explaining these basics right here, check it out!.
# Multiple licenses for the same code
Licensing the same code under 2 different licenses at once may seem like a pretty weird thing to do, after all, those licenses can each have different requirements and grant different permissions, and there’s generally not much of a need to do this.
That said, there is one very common use-case for this, which is pretty important to know about. That is, providing a stricter (usually copy-left) license to the project for free to everyone, while also selling a less strict (usually permissive) license for a price. This then means that if companies would want to include this project in their proprietary code-bases, they’d need to pay to be given the less strict license, allowing this. In fact, this is often the main way (other than donations) for open-sourced projects to make money.
This less strict license is often one, which doesn’t allow the company it was sold to to distribute the project’s code any further, however it can allow that company to use the project and make edits to it’s source code in-house, and distributing a modified binary without disclosing any source, and with their project remaining closed-sourced, which a copy-left license would not allow.
# How does multi-licensing even work?
I’ve already touched on this in my other article. Generally, as the owner of a copyrightable work, you can do anything you want with it, however others can’t really do much of anything, unless you give them a permission to. To do that, we use a software license, which might however limit condition those extra permissions behind some clauses (that’s why you need to follow software licenses), these conditions can be things like mentioning the original source, stating changes, etc.
When you, as the copyright owner, give out 2 (or more) licenses with your project, anyone is free to pick either of those, however they do need to follow at least one, in it’s entirety, so that they get the rights granted by it. People can’t just pick some terms to follow from the first license, and other from the second license, since neither of these licenses would then be applicable, as some of the conditions weren’t met, and so no copyright permissions are given to you from either of those licenses.
# Using different licenses for different parts of the project
This is a simpler case than the above, as we don’t actually have any code licensed under multiple licenses at the same time, all we have is different chunks of the code-base being differently-licensed, and this is actually incredibly common.
You’ll likely find chunks of open-sourced code thrown around in almost every bigger code-base, because it’s simply easier to re-use the already written things, than to reinvent the wheel and make up our own versions of everything. Most commonly, this is seen through projects using software libraries. These libraries will likely be under some permissive or weak copy-left license, and they’re being used in your project along with your own code, under whatever license you chose.
A slightly less common case would be directly using differently licensed code in your own code-base. When doing this,
you often end up having files like LICENSE-THIRD-PARTY next to your LICENSE file, where you’re stating all of the
different licenses used in your project, and what parts of the project they apply to. (Note that some licenses require
more things, such as also stating changes).
Another, but much less common case is when someone contributing to the project decides to contribute their code under a
different license to the rest of the project. They can do this by mentioning their changed/added part in that
LICENSE-THIRD-PARTY file, or by including a copyright header in the contributed file, or a bunch of other ways.
(Though the maintainers might just end up refusing that pull request).
# Contributing to multi-licensed project
When you see a project that’s dual-licensed, being publicly available under some copy-left license, but offering a permissive license for profit, you might be confused about how contributions to such a project could then work. After all, if you submitted your code under a copy-left license, there’s no way the company could then sell a permissive license to that code, since well, you didn’t give them a permissive license, and they wouldn’t have the right to release your copy-left code under a permissive license.
This is ultimately gonna be up to the project’s maintainers, and you’ll often find some guide on it in the project
docs, or in a file like CONTRIBUTING.md. However to understand how something like this is generally done, here’s a
few common methods these projects use to handle external contributions:
- Making all contributors sign a CLA, which grants the company maintaining this project permissive rights, even though you submitted your code under a copy-left license, and anyone else would need to honor that license. This CLA can be pretty narrow in it’s scope, only allowing the company to distribute your code under a permissive license, but only when they sell it under certain conditions, etc. However it can also be very extensive, where you will be asked to give the company complete rights over that code.
- Making all contributors use a permissive license, with the company maintaining the project having their code licensed under a copy-left license. In many cases, the company code makes up the majority of the code-base, so you end up with a mostly copy-left licensed code, with bits of permissively licensed code utilized in it. (See section below about split licensing like this.)
- Allowing contributors to pick whether they want to publish under permissive or copy-left license, keeping the code written by contributors who picked copy-left only available in the community/free version. However the company will usually try to keep version parity between these, or perhaps even having the payed permissive version include more features, so locking themselves from being able to get this code is pretty rare.
# Conflicting licenses
It is however important to say that if you do have a strong copy-left licensed code in your codebase, it’s supposed to force you to use that same (or compatible) license everywhere in your project, right? So is it even possible to dual-license in cases like these? Yes!
Even though having copy-left code in your codebase will mean you have to distribute the rest of the project under the same license, it doesn’t actually force that license to be the only one. Aha! So we could leave the original permissive license over the code in there, and on top of it add a compatible copy-left license, allowing us to use this copy-left code.
Warning
This will however still mean that when you’ll be distributing your binary, since it will contain the chunk of copy-left code, you’ll have to follow the license yourself, as that license it the only thing giving you the right to use that code, and so you’ll have to for example always bundle the source code with that binary. So your project is pretty much copy-left anyway, but you will allow others to use the rest of your code in a permissive manner, as it’s also licensed that way, and that license is usually much more friendly to others trying to use your code.
Since this code was originally permissive, you cold also just relicense and become fully copy-left, as permissive licenses do allow that. That’s also why you could “add” a copy-left license that now also applies to all of the originally permissive code.
The reason why you might want to use this approach instead of just relicensing and going pure copy-left is that you might eventually remove the copy-left chunk of code you used, and you could then go back to purely permissive license over your project again. However if you’ve changed to copy-left without dual-licensing, going back might be harder (see this post about relicensing).
# Drawbacks
While multi-licensing can have some clear advantages to the project, as it allows it’s monetization, it has it’s disadvantages too, mainly:
- Potential confusion for users who may not fully understand the licensing options
- Some contributors might be uncomfortable with the licensing terms, and with their code potentially being sold for profit, under a permissive license, making them avoid contributing completely.
# Example projects
- MongoDB: a popular open-source database system that uses dual-licensing. Its Community Edition is released under the GNU Affero General Public License (AGPL), while its Enterprise Edition is released under a proprietary license. This allows MongoDB to offer different features and support options to its users depending on their needs.
- Qt: a cross-platform application development framework that uses dual-licensing. Its Community Edition is released under the GNU Lesser General Public License (LGPL), while its Commercial Edition is released under a proprietary license. This allows Qt to offer additional features and support to its commercial users while still maintaining an open-source version.
- MySQL: another popular open-source database system that uses dual-licensing. Its Community Edition is released under the GNU General Public License (GPL), while its Commercial Edition is released under a proprietary license. This allows MySQL to offer additional features and support to its commercial users while still maintaining an open-source version that can be freely used and modified.