Choosing an open source license is a crucial decision for your project. It will affect who can use your code and how, what contributions you might get, and how it interacts with other software. Here are some guidelines and considerations when selecting a license:
Evaluating license compatibility
When your software includes or interacts with other open source components, license compatibility becomes important. License compatibility refers to whether two different licenses can be compiled simultaneously when code is merged or distributed together. If you’re writing all the code yourself, you just choose a license for your project. But if you are incorporating libraries, or you expect others might combine your code with other code, consider how those licenses will mix.
Some key points on compatibility:
- Non-reciprocal licenses are broadly compatible. Permissive licenses (MIT, Apache, BSD) generally impose so few requirements that they can be combined with almost any other license. For example, MIT-licensed code can be included in a GPL project or a proprietary project without conflict – the MIT conditions (keep notice, no liability) don’t clash with those environments. Apache 2.0 licensed code can also be included in GPLv3 projects (the Free Software Foundation has said Apache 2.0 is GPLv3-compatible) because the Apache terms (like patent grant) are acceptable under GPLv3. However, Apache 2.0 is not compatible with GPLv2 in the absence of “or later” clause, because GPLv2 didn’t anticipate the Apache patent clause (thus, a GPLv2-only project can’t merge Apache code). In general, non-reciprocal licenses are easiest to combine with others because they don’t impose share-alike terms.
- Reciprocal licenses can conflict. If you combine code under two different copyleft licenses, you might have a problem: each license wants the combined whole to be under its terms. For instance, GPLv2 and CDDL are both copyleft but are famously incompatible – you cannot mix CDDL code (like OpenSolaris’s ZFS) into a GPLv2 project (like Linux) because you would violate one license or the other when distributing the combined work. Even GPLv2 and GPLv3 are incompatible with each other unless permissions are granted to relicense (many GPLv2 projects say “v2 or any later version” to allow upgrading). So, when using copyleft components, you must ensure they share a common licensing path. The GPL family (GPL, LGPL, AGPL) is designed to be compatible (LGPLv3 can be combined with GPLv3 projects; AGPLv3 and GPLv3 code can merge if you release it all as AGPL for network use, etc.). But mixing different copyleft licenses (like MPL code into GPL code) could require using dual licensing or alternate arrangements. The OSI observed that having many copyleft licenses created “incompatible islands” of code – so today most people stick to a few standard ones to maximize compatibility.
- Library usage vs derivative works: A practical guide is to ask: are you just linking to a library, or copying code, or creating a derived work? If you are linking to an LGPL library, that’s allowed by LGPL in closed code. If you are copying GPL code into yours, then your code must be GPL. If you have code under license X and you want to include a snippet under license Y, you need to see if you can apply both licenses at once. Often, one license will effectively “win” (for example, GPL will require the whole to be GPL). If that “winning” license isn’t acceptable for some part, then they’re incompatible.
- License compatibility resources: The Free Software Foundation’s license list is a good resource that spells out whether each license is GPL-compatible or not. Also, choosealicense.com and tldrlegal.com sometimes discuss compatibility issues. There are even charts and tools (like OSS Compass charts) that illustrate compatibility. But generally, if you stick to common licenses, known combinations have known outcomes (e.g., MIT + GPL = combined work can be GPL, with MIT conditions trivially met by including notice; Apache 2.0 + GPLv3 = combined work GPLv3, fine; Apache 2.0 + GPLv2-only = not okay; MPL + GPL = can distribute them side-by-side but not combine into one file; etc.).
If your project will have multiple dependencies, try to choose a license that is compatible with all of them. For instance, if you use a GPLv3 library in your app, you must license your app as GPLv3 (or AGPLv3) to comply – so you wouldn’t choose MIT for your app in that case because MIT would not satisfy the GPL’s requirement (the app would effectively become GPL anyway). If you want to keep your project permissive but you need to use a GPL component, you have a problem – you might look for an alternative library under a permissive license, or reconsider if you’re willing to go GPL.
License compatibility example: Suppose you have a project and you want to use some open source libraries:
- Library A is MIT licensed – you can use it no matter what license your project is, just keep its notice. No conflict.
- Library B is LGPL licensed – you can use it even in a closed-source project, as long as you don’t modify B (or if you do, you release those modifications LGPL). If your project is Apache or MIT or GPL, it’s fine to include an LGPL library (you just have to allow relinking if someone wanted to swap the LGPL part).
- Library C is GPLv3 licensed – if you include this, your whole project must be GPLv3-compatible. So you should likely license your project as GPLv3 as well (or AGPLv3) to comply. If you are not willing to do that, you cannot use Library C.
- Library D is MPL 2.0 – you can include it alongside your code without your code becoming MPL, but any changes you make inside Library D’s code must be released as MPL. MPL is file-scoped, so as long as D remains its own file or module, your overall project can be, say, Apache or MIT, and just ship MPL code as a part. But note, combining MPL and GPL in one program can be tricky when distributing, which is why MPL code often offers a GPL-compatible dual license.
As you can see, it can get complex. For a beginner-friendly approach: choose a license for your project that is the same as or more permissive than the licenses of your dependencies. That way you won’t violate anything. If you use any strong copyleft component, your project likely needs to be that same strong copyleft. If you want to keep things simple and permissive, ensure all components you use are permissive or at most weak copyleft that doesn’t impact you.
Don’t create a new license (avoiding license proliferation)
Please resist the temptation to write your own license or heavily modify an existing one. With dozens of well-established open source licenses available, it’s almost always better to use an existing, OSI-approved license than to invent your own terms. Crafting a new license is highly discouraged in the open source community for several reasons:
- Legal robustness: Standard licenses (MIT, GPL, Apache, etc.) have been vetted by legal experts and tested in real-world use. A homemade license may have unforeseen legal loopholes or incompatibilities. Unless you have a team of lawyers and a very unique need, your custom license might do more harm than good.
- Community trust and adoption: Developers and companies are familiar with the common licenses and know how to comply with them. A weird, new license will make people wary – they might avoid your project simply because they aren’t sure what they’re allowed to do. A well-known license acts as a shorthand; a custom license raises questions. As GitHub’s guide advises, a standard open source license serves as a proxy for laypeople to understand usage rights, whereas non-standard terms create a barrier to adoption.
- License proliferation: The OSI has identified license proliferation as a problem – too many redundant or niche licenses fragment the open source landscape and cause confusion. More licenses mean more complexity for developers trying to mix code or choose a license. Please do not write a new license if an existing one suffices.
- OSI Approval and Open Source Definition compliance: If you make a new license and call your project “Open Source,” you must get that license approved by OSI to ensure it actually meets the OSD. This is a non-trivial process. Until it’s approved, calling it “open source” is confusing at best or misleading at worst. Unless you have a compelling reason, it’s better to use an OSI-approved license so there’s no ambiguity.
If you don’t use an approved license, please don’t call it Open Source.
Be a good open source citizen: use a known license.
