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 and shouldn’t be treated or relied upon as such. Code licenses are binding legal documents that should be treated seriously. You are exclusively responsible for compliance with the terms of the license under which you use code, and it is always best and advisable to consult a lawyer before making licensing related decisions or use.
- You must own the copyright for the entire code you will be offering, including any code contributions embedded in the code.
- Your code must originally be MIT licensed. To be able to easily use dual licensing, your code must be licensed under the MIT license. If you code is licensed otherwise, please contact firstname.lastname@example.org for assistance.
Dual licensing means you keep the same code, under two different licenses. While dual licensing is a broad subject, which can be applied in various ways, this guide will focus on a permissive-copyleft dual licensing scheme, which is what we recommend for most users on xs:code.
Before applying a license to your code, we recommend you read and understand the license and its terms.
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:
Permissive licenses are open source licenses which suit their name… They stipulate very few limitations, and most importantly - these limitations are easy to accommodate even by commercial companies.
These licenses do not involve the "viral effect" risk (that arises under copyleft licenses, as explained below), but rather are characterized by a freedom to use with almost no "strings" attached.
Though the permissive licenses differ from one another, their common main requirements can generally (common denominator) be summarized as follows:
- Attribution and retaining of copyright notices – meaning that the user needs to provide a clear attribution (give proper credit in a prominent and well-displayed location) and retain (not remove or modify) the copyright notices which accompanied the open source software.
- Inclusion of a copy of the license and of the "as-is" disclaimer – meaning that a user that redistributes the software needs to include a copy of the license under which the open source software is provided, and - if provided separately - such a disclaimer (which states that the software is provided as-is, without any warranties).
- Some of the permissive licenses (Apache for example) require the user to state if they changed the open source software/component/file.
- Some permissive licenses explicitly prohibit the use of the open source's names and trademarks to endorse and promote the user's products (but this goes without saying, even if it is not written).
Examples for permissive licenses are
“Strong” "Copyleft" licenses
Strong copyleft licenses include the requirements of permissive licenses, as described above, but additionally they may result, under certain circumstances of use, in being subjected to the "viral effect" – meaning that the "virus" will contaminate your proprietary software - if your proprietary software is a work "based" on the strong copyleft licensed software that is being distributed - and will require your software to also be distributed under the terms of the same strong copyleft license.
Such result, which in practice means that the software intended to be proprietary cannot be "closed" and distributed only in object code form, but rather needs to be "opened" and revealed in source code form, is what is called the "copyleft" requirement.
Naturally, many companies creating their own software can't release their trade secrets, making GPL a non-viable license for them to use.
Weak Copyleft Licenses
Similar to strong copyleft licenses, weak copyleft licenses include the requirements of permissive licenses, as described above, but also include certain copyleft requirements. However, their copyleft requirements are either not triggered as fast as those of the strong copyleft licenses or are of a less aggressive nature than those of the strong copyleft licenses.
Examples for weak copyleft licenses are GNU Lesser General Public License (also known as LGPL), CDDL, Eclipse, and Mozilla.
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 a permissive license (such as MIT) 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 permissive licensed code on xs:code. We recommend using the GPLv3 license for front-end code, or for code running in a mobile application, and using the AGPL license for back-end code.
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 copyleft (like GPL) licensed code are also copyleft 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 (for example) licensed code, that's usually not a problem. However, since you will want to apply those contributions to your permissive (MIT for example) licensed code, it means you will need to change their license from GPL to MIT.
Copyright holder can choose to relicense his code. Therefore, if you are the sole author and copyright holder of the code you’d like to donate, it’s doable. But, if you’re not the sole author and others have contributed to the code, you’ll need to obtain the consent of those contributors before you change the license which applies to the code they have donated. We highly recommend you to use a contributor license agreement to receive contributions, which will, in advance, anchor your right to change the license applying to the contribution. Otherwise, you can reach the contributors and obtain their consent (or remove contributions that consents were not obtained in their regard).
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. It is clarified that this sample CLA is only an example and that the above Disclaimer applies in its respect as well.
You can download the contributor license agreement here.
Using the CONTRIBUTING 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 as well, 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.