how to guide

Using xs:code for offering a license (Dual licensing)

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.

The dual licensing model

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.

licensing explained

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:

  1. 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.

  2. 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 result, for companies developing proprietary software, can be a non-starter
    Learn more here.

how it works

To use the dual licensing model, You keep two repositories on your Github account:

A public repository (the one you have today) – where you will keep the free version of your code with a copyleft license, such as the GPLv3 license. Visit our licensing guide for more information before deciding which license to use.

A private repository – where you will keep a duplicate of your code, but under a more permissive license, such as MIT. Visit our licensing guide for more information before deciding which license to use.

Check before proceeding

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.

1. Create a private repository

Use Github’s built-in tools to create a private repository, and clone the code from your public repository there. Also, edit the repository’s readme file to make sure users know this is the paid repository, which includes the license you are offering (for example, an MIT license).

2. Modify your public repository

Now, assuming you have the legal right to do so (see above for general explanation which is not a legal advice), 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.

3. Create your project on xs:code

When your private repository is ready, import it to xs:code using our Github app. Just click on “Import repository” on xs:code, follow the instructions and set your monthly subscription price.

After import is complete, set your project to “Published”, and use your project URL to send users to your project and start their subscription.


4. Let everyone know

The best place to advertise your paid version is on your readme file on Github. Use our readme example to learn how to announce your paid version, and explain exactly what you are offering, along with a link to your xs:code project.

You can also use social media, blogs and developer community websites to let everyone know your project has another, paid version available.

Need help with marketing your project?

Check our promotion guide, or contact our community team at [email protected].
They can help with setting up your project and help make sure you get as many subscribers as possible.