Using different licenses for different branches of the same repository

Question

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?

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.