I'm about to create a new open-source project and I'm not sure about the licensing method I should choose.

Here is what I know:

  • The project will be built on the basis of an already existing open source. I will fork from the original project and will build a community around a new project that has a code base from the original project.

  • In case the new project becomes successful, I will want to, one day, fork to an extended version of it which I will earn from. I want the non-free version to be non open-source.

For now, I have 2 main projects that I can use as my base project. One has a GPL license and the second has MIT license. I'm wondering what would better suit my needs. Also I'm wondering which license should I use for my open-source in order to, maybe, someday fork for a paid version which will not be open-sourced?

  • Note, that there are quite a few projects that make money from GPL codebase. Instead of paid pro version, they live off providing paid support and implementing new features for money where the features still eventually get released under GPL, but the paying customer has them first and made exactly for their needs.
    – Jan Hudec
    Commented Sep 12, 2013 at 8:03
  • Interesting example is Qt, which used to be dual-licensed GPL and commercial (which you can only do if you are sole copyright holder), but later relicensed to pure LGPL and live off just support.
    – Jan Hudec
    Commented Sep 12, 2013 at 8:06

3 Answers 3


The GPL is incompatible with your goals because it is viral. Once the code is open sourced by the original project, any fork must also abide by the GPL. If you are the copyright owner (which you will not be) then you can dual license your code, however.

The MIT license appears to be more flexible and would better suit your goals.

Source: http://opensource.org/licenses


As long as you choose one of the major open source licenses then you should be OK. I suggest sticking with one of the OSI's "Popular Licenses" But obviously you need to respect the terms of the original open source code that you build upon.

A "bait and switch" where you build an open source community around a pretence of openness then make the product proprietary will, of course, be viewed very negatively by the open source community. You would probably lose all of your community and goodwill at this point.

A better option, if you want to be a good open source citizen while still making a profit, is to stay open source but charge for services and support for corporate users. This is the model used very successfully for Red Hat Linux, for example (which is GPL licensed).


The easiest thing to do would be to use the same license as the project you are forking from.

However if the original project is BSD licensed you need to think about another license.

I would disagree with some other posters and say that your type of project is an exact fit, you retain ownership but allow others to copy and improve. Indeed if the base project you are forking from is GPLed you must use the GPL license, at least for those pieces of your code which are based on the GPLed source.

  • 1
    There is no "at least". If there is anything under GPL, it must apply to everything, period.
    – Jan Hudec
    Commented Sep 12, 2013 at 7:59
  • @Jon Hudec -- not strictly true. You can separate your code base between the GPL derived code which must be GPLed and code which merely uses the libraries/executables of the derived code which can be licensed any way you want. Commented Sep 12, 2013 at 9:07
  • They would have to be separate executables. Separate libraries do not stop GPL propagation.
    – Jan Hudec
    Commented Sep 12, 2013 at 9:09
  • Separate dynamic libraries stop LGPL propagation. Static libraries don't stop even that.
    – Jan Hudec
    Commented Sep 12, 2013 at 9:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.