This guide is aimed at helping developers set up a dual licensing monetization model for their open source projects.
Disclaimer - The following is not legal advice. Code licenses are binding legal documents that should be treated seriously. If you are not familiar with licensing concepts, it is always best to consult a lawyer before making licensing decisions.
Please note - xs:code currently supports repositories with a permissive license, prior to the license change. If you repository currently has a restrictive license (such as the GPL license), please consult with our community team at firstname.lastname@example.org before importing your repository to xs:code.
What is dual licensing
Dual licensing means you keep the same code, under two different licenses. The reason for applying a dual licensing scheme, is usually to offer a one type of license for free, and another for a price. The incentive for paying, is usually for a type of license that poses less restrictions than its free counterpart. While dual licensing is a broad subject, which can be applied in various ways, this guide will focus on a permissive-restrictive dual licensing scheme, which is what we recommend for most users on xs:code.
Types of licenses
Open source licenses come in many flavors and colors. For the sake of simplicity, we will separate them into two main groups:
TLDR - A permissive license basically allows your users to do almost anything with your code, making it the preferred choice for companies using open source in their commercial projects.
Permissive licenses allow users to freely copy, distribute, and change the original software. In simple terms, giving your code a permissive license such as the MIT license, gives your users the ability to do pretty much everything with your code, including using it in commercial software almost without restrictions. The only restriction posed by the MIT licenses is that the license itself (a simple text file) will be included with the modified code.
Most of the open source code available today is licensed with an MIT license, and it is favored by companies creating commercial software, because of its simplicity and lack of restrictions.
Restrictive "Copyleft" licenses
TLDR - Restrictive Copyleft licenses usually require that a) Any derivative work created using a copyleft license, must also have the same license, and b) The derivative code must be made publicly available. This means that companies usually refrain from using copyleft licenses in their commercial software, as they won't reveal their proprietary code to the public.
Copyleft licenses are similar to permissive licenses in that they allow people to freely copy, distribute, and change the original software that is covered under the license.
However, most copyleft licenses, such as the GPL license - require the the user modifying the code, will release the modified version as open source as well. Often called a "viral" license, if you use GPL in your project, it "infects" any derivative code created using it, requiring your to release ALL derivative work with a GPL license to the public. Naturally, many companies creating their own software can't release their trade secrets, making GPL a non viable license for them to use.
Choosing the licenses for your project
The simplest way to apply a dual licensing model with xs:code, is applying a GPL license to your public repository, and an MIT license to your private repository which is offered on xs:code.
This will like cause most companies to refrain from using your public code, and opt to purchase a subscription to your MIT licensed code on xs:code. We recommend using the GPLv3 license.
Click here for more information on how to apply a license to your Github project
Accepting code contributions with dual licensing
Contributions are a great way of creating a community around your project and getting help from others with making your code better.
However, when using a dual licensing model, there are consideration to be made before you can accept contributions. Since contributions are made to your public repository, now licensed with GPL (or other copyleft license) - that means two things:
- Contributions made using GPL licensed code are also GPL licensed.
- The copyright of the contribution itself (regardless of the license) - belongs to the contributor.
As long as the contributions you accept remain in your public, GPL licensed code, that's usually not a problem. However, since you will want to apply those contributions to your MIT licensed code, it means you will need to change their license from GPL to MIT.
In order to be able to do so, the contributor must assign their copyrights to you. Once that happens, you will become both the original licencor of the code (since you originally granted the GPL license to the code), and the owner of the contribution - these two factors allow you to change the license of the contribution as you see fit.
In order to assign the copyright of a contribution, you contributors will need to sign a document called a CLA (Contribution license agreement). Before accepting and using code contributions to your project, you must have the contributors sign this agreement. Otherwise, you might be exposed to legal issues and copyright claims.
For your convenience, we've prepared a sample CLA you can use for accepting contributions. You should edit it to include the name of your project, and store it in your repository. Be sure to save the signed CLA's somewhere safe, for future reference.
You can download the contributor license agreement here.
Using the CONTIBUTING file
To make things clear for your contributors, you should consider adding a CONTRIBUTING file to your repository. The CONTRIBUTING file, is a text file that is shown to your contributors when they open a pull request. you should add to the file an explanation, stating that contributions to your project must be accompanied with a signed CLA, to ensure that the contribution can be used on another repository with a different license. You may use the following statement:
The repository you are contributing code to is also available with a different license on xs:code.
I am using xs:code to offer paid access to a permissive licensed version of the code.
In order to accept your contribution to this GPL licensed version, and to be able to use the contribution on the MIT licensed version, I ask that you sign this CLA (Contributor license agreement) and send it to <your email address>.
Download the CLA here: <link to your CLA>
Without signing the CLA, I will not be able to accept your contribution.
Thank you for your contribution and for your cooperation.
You can learn more about the CONTRIBUTING file here.
If you need any assistance with setting up a dual licensing for your project, please contact our community team at email@example.com.