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.
Offering another license is a great way to start getting paid for your open source project. Often called “Dual licensing”, it means you offer your code in two separate repositories – both have the exact same code, but a different license. Usually, the public repository will hold a copyleft license for free use, and the private repository will hold a more permissive license for paying users.
Different open source licenses provide different limitations on how users can use your code. Those limitations can make it difficult to use your code when creating commercial software. With dual licensing, you offer a free version of your code with those limitations, and a for-fee version without them. First, let’s learn a bit about open source licenses.
Open source licenses are usually divided into two main categories:
Permissive licenses (such as MIT, BSD or Apache 2.0) – These licenses impose “soft” requirements, which are easy for commercial kind of users to adhere (almost “no strings attached”), thus making them an attractive alternative when looking for code to use in commercial applications.
Learn more here.
Restrictive (or ‘Copyleft’) licenses (Such as the GPL licenses) – These licenses may under certain scenarios result in “harsh” consequences for commercial kind of users, thus making them sometimes problematic for companies looking for code to use in commercial applications. For example, in some cases, using GPL licensed code in a project, may result in subjecting the entire project’s code (both the GPL based and the newly authored), to the GPL open source license as well, which for companies developing proprietary software, can be a non-starter.
Learn more here.
To use dual licensing, you must comply with 2 main requirements. Both requirements MUST be met before proceeding:
You must have the legal rights to re-license the entire code
You must have the right to re-license the entire code you wish to re-license, including any code contributions it may contain. If you started your code from scratch, applied the license to your own code, and did not accept any code contributions, you’re supposed to be the sole author and the copyright holder (putting aside issues like rights of your employer etc., which you should carefully check and comply with) meaning that you should have the rights to so re-license. If your code contains code contributions, you might 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 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 (and remove contributions that consents were not obtained in their regard). Please have a look at our dual licensing guide for more information.
Your original code must be licensed under a permissive license (such as MIT or BSD)
If your code is not licensed under a permissive license, please contact support before proceeding.
You will need to keep two repositories on your Github account:
A public repository – where you will keep the free version of your code with a copyleft license, such as the GPLv3 license.
A private repository – where you will keep a duplicate of your code, but under a more permissive license, such as MIT. This will become the paid item you will be selling.
Assuming you have the legal right to do so (see above for general explanation), change the public repository’s license to the copyleft license you chose (Such as GPL). Then, edit the LICENSE text file in the repository root folder to the GPL version of your choice.
First, you’ll need to add your public repository, which is the foundation on which you will create your paid items.
Click “Add repository” and follow the instructions. You’ll need to install our Read-only Github app on you repository for verification purposes.
Now, let’s create your paid item.
Under your public repository, click “Add item“, and select the “License” item type. To connect your private repository to your item, follow the instructions. You’ll need to install our app on your private repository as well – but this time, xs:code will create a copy of your repository on our git servers. Users who purchase this item, will get a unique read-only token to access your private repository.
Choose your item’s pricing and billing model.
Select from one-time payment or recurring subscription (monthly/annual). You can even set multiple prices/billing models per item.
You can create as many items as you like, each with a different price and billing model. We recommend subscription based access billing for license items.
The best place to start promoting your paid items, is on your readme file.
Use our badge to place a link to your xs:code repository page (Looks like: https://cp.xscode.com/user/repository) to notify people who use your project about the items you are offering.
You can also use social media, blogs and developer community websites to publish your paid items.