I have a Git repository with a medium-sized project on GitHub. Since there are some components depending on GPL libraries, the repository is currently also licensed under the GPL. However, the GPL-licensed library is only used by some components (which can be isolated), and the remainder of the project is perfectly usable without those components. Therefore, I want to license everything that has no dependencies on any GPL libraries under the MIT license. What are the best practices to achieve this?

My idea is to have two different branches: one branch contains the full code and is licensed under GPL. The other branch removes all functionality that depends on GPL code and is licensed under the MIT. Is it feasible and/or common to have different licenses for different branches of the same repository? If not, what would be better alternatives?

Could it be a problem that, technically, the full history of that new non-GPL-branch once included GPL-code? Or is it fine as long as all GPL-code is removed from that branch before I add the new MIT license file on the branch?

Note that this question is somewhat similar, but I have the feeling that mine is more concerned with the technical implementation. That is, can I simply put two different LICENSE files in the root directory of the repository, depending on which branch we are currently on?

1 Answer 1


Git branches don't work very well for maintaining different “editions” of the same project, because there's no good way to share changes across branches without merging them completely. So simply for technical reasons, I'd urge you not to use differently-licensed branches. Such branches are also not very discoverable to users.

Instead, keep all the code in one main branch, but keep differently licensed code in different folders and make it very clear which code is under what license.

The GPL does not require that any downstream code is under the GPL. It requires that any derivative works (as a whole) are under the same GPL license. But this can be satisfied when any components you've written yourself are under a GPL-compatible license, such as the MIT. For the avoidance of doubt you might also dual-license those components as "MIT or GPL". This would be important for licenses that aren't compatible, e.g. "Apache-2.0 or GPL-2.0-only".

So the best practice would be to separate the GPL-covered parts from the parts you've written completely by yourself, and use the top-level LICENSE to describe what parts are available under which license. If you want to do this extremely accurately, you could even adopt Debian's machine-readable copyright file format which associates glob patterns with licenses. You could store the full license text either within the same license file, or maybe as separate files like LICENSE.GPL.txt, LICENSE.MIT.txt, or in their respective directories.

Since you're currently offering the entire code under GPL, moving the MIT for some parts would require relicensing. This is trivial if you are the sole contributor, because you as the sole copyright holder can issue licenses however you please. But if there are other contributors, you will have to get their consent to the relicensing or have to remove their contributions (which can be extremely tricky because it generally requires rewriting the component starting with the last state before the GPL-covered contribution). I don't think it matters that the Git history would show those same files as GPL-covered even after the relicensing. The old license is still valid for those old versions, the new license is still valid for those new versions.

  • Doesn't this sentence "But this can be satisfied when any components you've written yourself are under a GPL-compatible license, such as the MIT." contradict gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL ? Commented Aug 20, 2020 at 10:52
  • @user1494080 It's a subtle point. Your code is not necessarily derivative of the GPL library. But when your code is linked with the GPL library the result is a program that is derivative from both your code and the GPL library. If you want to be able to distribute this program, your license has to be GPL-compatible. As that FAQ entry explains: “The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL.”
    – amon
    Commented Aug 20, 2020 at 10:56
  • Does that mean I can even license code that depends on a GPL-licensed library under MIT, as long as I don’t include the GPL library’s source code in my project, but require users to download the library code themselves? In that case, I would simply put the whole project under MIT, instead of using two licenses. Commented Aug 20, 2020 at 11:36
  • 2
    @user1494080, you don't even have to let the users jump through the hoops of downloading the libraries themselves. You can license the source code of your project under the MIT license, as long as you make it clear that the GPL applies to any build that also includes the GPL libraries. Commented Aug 20, 2020 at 14:42
  • After reading this answer and comments I am even more confused about how GPL works. Ouch... So complicated...
    – Pedro A
    Commented Aug 20, 2020 at 23:58

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.