Let's say I have three repositories on GitHub that I own. I made repository #1 open source under the MIT license. Repository #2 is mostly user graphical interface stuff, but I made it private without any license, because I want my programs to look unique.

I want repository #3 to be open source, but it uses both repository #1 and repository #2. How should I license repository #3?

  • 3
    If project #3 depends on project #2, then it doesn't matter what license you choose for project #3. Since project #2 has no license, nobody can make use of it, and since project #3 depends on project #2, that means project #3 cannot be used either. Nov 16, 2022 at 14:31
  • 8
    "I want my programs to look unique" - but you otherwise want people to be able to use the software? It sounds like you want a trademarked style which sits on top of your software. Fix up the dependencies so that the program can have its look and feel swapped out while retaining all the important functionality, then distribute a "base" style as open source and either do not distribute or otherwise protect your "branding". Nov 16, 2022 at 15:38
  • 1
    @GACy20 no need to go into hypotheticals, that's a binary blob. It's done by many Linux distributions. It has however always been controversial whether this actually complies with the GPL: if you ship a binary, then this whole program has to be GPL-licenced due to copyleft. And the GPL requires you to make all the source available. Of course, you're unlikely to be sued for violating your own license, but that doesn't mean it's legal. Only as long as you don't ship any binaries, no issues arise, Nov 17, 2022 at 0:10
  • 1
    @BladePoint You can't violate your own license because you're not bound by the license. Default state of copyright is you own everything you make, and nobody else has any rights. Licenses exist to specify exceptions to that between you and a third party. Such a contract does not exist for yourself on your own. You can license your own code however you want. It's just nobody else might be able to use it if you specify self-contradictory terms. GPL can't force itself upstream.
    – Will Chen
    Nov 17, 2022 at 7:51
  • 1
    @leftaroundabout that's not how it works, the license doesn't bind the copyright owner, who is always free to do whatever they want. The license grants the receiver permission to do things they otherwise would not (using the library, redistributing it, etc), provided they obey the conditions.
    – mbrig
    Nov 18, 2022 at 20:23

6 Answers 6


I want repo #3 to be open source, but it uses both repo #1 and repo #2. How should I license repo #3?

You can license repo #3 under a permissive open-source license, like MIT or Apache.

Permissive open-source licenses do not place a restriction on the type of license that is used by the dependencies. You might get some flack from people for the fact that repo #3 depends on closed-source code, but that is only sentiment speaking. On the legal side, you are fully in the clear.

  • 2
    This is correct, since the OP says that repo #1 is also under a permissive license (MIT). Things would get a lot more complicated if repo #1 was under a copyleft license such as GPL and, in particular, it would be easy to end up in a situation where nobody (except possibly the OP, if they were the sole copyright owner of all repos) was allowed to distribute the finished software built from repo #3, as it would include the incompatibly licensed dependencies from repos #1 and #2. Nov 16, 2022 at 21:53
  • 1
    Worth noting that GPL says you can't distribute software in which GPL code is "linked" to non-GPL code. It doesn't say you can't download a GPL component and a non-GPL component and link them yourself, following detailed instructions provided by the distributor of both components... Nov 18, 2022 at 19:36
  • Why is that difficult, please? Repository #1 is open source, or not? Repository #2 is private without any license, or not? Repository #3 uses some elements from Repository #2, or not? Why would you not license R3 according to its components? Does R3 include any component requiring any licence, or not? Nov 19, 2022 at 20:32

While you can do this (with MIT at least, potentially others, but not a large choice), you're going to run into some fairly large issues.

Firstly, there will be a lot of complaints, as in effect the final delivered product would not be open source as an offering, and there are a lot of purists out there.

Secondly, nobody could run the open source code legally, unless you attach a license for the use of repo 2 (though potentially not its sources).

Thirdly, a license permissive enough to do this is likely going to allow alteration and derivative works, which could then use repo 2 (in the same manner that repo 3 does) for something that could eventually be very different to the purpose of repo 3.

In short, if you want to do this, there are many options available with differing degrees of complexity, but all of them will involve attaching some kind of license to repo two (though not an open source license), to control how it can and cannot be used. Until you put a license on the repo, nobody can use it except you even if you are using it from MIT code.

In practice the way to do this is normally to split repo two in half, and make an open source framework, and a closed source and proprietary resource/configuration pack to ensure a unique look and feel.

  • yeah, and explain well what would be required from users to do to be able to actually use your #3 repo as part of other projects or as derivative work. Nov 17, 2022 at 18:54
  • See Firefox: if you download the source and build it comes out branded "Minefield"
    – Joshua
    Nov 17, 2022 at 20:02

Making repo #3 permissive is as easy as it would be for any other project. To make it copyleft, you need to add an exception to its license for repo #2 specifically. The FSF has a full FAQ on how to do this at https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs, but the gist of it is this:

In addition, as a special exception, the copyright holders of [name of your program] give you permission to combine [name of your program] with free software programs or libraries that are released under the GNU LGPL and with code included in the standard release of [name of library] under the [name of library's license] (or modified versions of such code, with unchanged license). You may copy and distribute such a system following the terms of the GNU GPL for [name of your program] and the licenses of the other code concerned{, provided that you include the source code of that other code when and as the GNU GPL requires distribution of source code}.

Note that people who make modified versions of [name of your program] are not obligated to grant this special exception for their modified versions; it is their choice whether to do so. The GNU General Public License gives permission to release a modified version without this exception; this exception also makes it possible to release a modified version which carries forward this exception.


If you created and own the source code in all 3 repositories without any contributions from others, and without modifying others' projects, with the exception of the use of libraries, then you own full copyrights for the intellectual property in all those 3 repositories.

In this case, you can choose to dual license the software in your repositories. So, Repo #2 can be closed source, and Repo #3 can be open source.

Please see "Under what conditions can someone dual licence existing works?".

Examples of dual licensing software under open source and proprietary terms for software for which you own all the copyrights, are Qt and MySQL. These projects license the open source version under LGPLv3 and GPLv2, while also having providing the same software under a commercial license.

So, what open source license should you use for Repo #3? That's up to you. Since Repo #1 is MIT-licensed (which is free and permissive), you can choose any OSS license for Repo #3.

  • 2
    To my understanding, "dual licensing" refers to a single piece of software that can be licensed under potentially different license alternatives, at the licensees' option. The term would not be used for a collection of software (or a single application) where one part is under license A (only) and another is under license B (only). If you have a single license for Repo #2 and a different single license for Repo #3, that's not dual licensing, even if Repo #3 uses Repo #2. Yes, the licenses need to be compatible, but if there isn't a choice of license, it isn't "dual licensing".
    – R.M.
    Nov 16, 2022 at 15:30

If you own all code in your repositories, you can specify exceptions in the license. For instance, you can license your interfacing part under GPL and leave the implementation proprietary, simply stating "It is permissible to use the library XYZ". This will not earn you too much respect and was more for cases when there is no open source replacement, but exceptions can be added to the license.

Of course, if you do not own the whole code in the GPL part, you cannot add exceptions there.


I would seek to have deliverables that are similar to what would exist if the closed-source portions had been written by someone else and released under a license that allowed them to be freely incorporated into other programs if used unmodified.

Suppose Acme Corporation releases a closed-source driver for a USB device under such terms, some programmer Bob who has no relationship with Acme Co designs a program to do something useful with that device. Bob's program incorporates gnu-licensed code from other people, and Bob also wants to release everything under the most permissive license possible. I don't think any common interpretation of the gcc license would say that Bob could only distribute his program if he could somehow convince Acme to open-source their driver. I think a far more typical interpretation would say that if Bob's obligations would be satisfied if he distributes everything the Acme Corp. license would allow him to distribute, and building the program would not require access to information or resources which other people could not acquire on the same terms as Bob did.

If the USB device and its driver were designed by Bob, rather than an unaffiliated Acme Corp., I don't think it would be fair to say that Bob should have less freedom over how he uses the driver that he wrote, than would have when using a driver written by some unaffiliated entity. If the driver is written and documented well enough that a typical competent programmer could figure out how use it in the same ways Bob's open-source programs does, and Bob's open-source code refrains from exploiting undocumented aspects of the driver in ways programmers without "insider knowledge" could not, I see no reason that Bob should have more obligations than Acme Corp. to release the code to his driver, if he distributes the program in a manner that would cause any incorporation of the driver into the executable to be accomplished on the recipient's machine.

As a demonstration of good faith, it would probably be good for Bob to release an open-source "driver" which could interface with the main application even if it wouldn't be particularly useful as-is but would e.g. output to the console a description of all commands that would be to the external hardware, and receive from the console all responses the external hardware would receive. Someone who wanted to interface with some other hardware device could then replace the console I/O with operations that would interact with the other device.

Some people may squawk about "Tivoization", but a key difference between the above scenario and a TiVo box is that anyone who wants to change aspects of the system which are under the control of open-source code would be free to rebuild the open-source portions and incorporate those changes into the overall system, and someone who wants to replace the closed-source portion with an alternative code package sharing the same API would likewise be free to do so. Essentially, parts of the code whose authors want to allow piecemeal alteration by anyone and everyone could be altered piecemeal by anyone and everyone, and parts whose authors didn't want to allow piecemeal alteration could be removed by anyone who wanted to author a replacement.

If the author of a closed-source portion of a program were to seek to prevent recipients of from making piecemeal alterations to the open-form portions, rebuilding, and using the resulting executable, such action would clearly violate the spirit and possibly letter of the open-source licenses, but allowing open-source and closed-source components to interoperate in ways that uphold the indicated rights would greatly expand the range of tasks that could be accomplished using open-source projects, compared with saying that such projects cannot be designed to interoperate with closed-source components.

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.