Choosing an Open-Source License for a New Project
The license you pick determines who can build on your project commercially, and what they owe back. Here's how to actually decide.
By The Internet Compass Editorial Team — Data Infrastructure Desk
The real question is what you want back from adoption
Every open-source license grants broad rights to use, modify and redistribute code. What separates license families is what they require in return, and that requirement should follow directly from what you're trying to achieve — maximum adoption, or a guarantee that improvements flow back to the community.
Work through these questions in order
Most license decisions become obvious once these are answered honestly, in this sequence.
- 1
Do you want companies to build proprietary products on top of your code?
If yes without reservation, a permissive license (MIT, Apache 2.0) removes the friction entirely. If you want commercial derivatives to remain open, copyleft is the mechanism that enforces it.
- 2
Are you contributing to, or forking from, an existing project?
You inherit that project's license family in most cases. Changing license terms on a fork of copyleft code is often legally impossible without every contributor's consent — check before assuming you have a free choice.
- 3
Do you need explicit patent protection?
If your project could plausibly touch patented techniques, Apache 2.0's explicit patent grant is meaningfully safer than MIT or BSD, which don't address patents at all.
- 4
Is this a library or an application?
Libraries meant to be linked into other people's proprietary software are almost always better served by a permissive or weak-copyleft (LGPL) license — strong copyleft on a library discourages exactly the adoption most library authors want.
License choice is close to permanent
Relicensing an existing project after it has multiple external contributors generally requires either unanimous consent from every contributor who holds copyright in their contribution, or rewriting the affected code — both are expensive enough that most projects never do it. The license chosen at the start is the license that sticks.
This is the strongest argument for making the decision deliberately at the outset rather than defaulting to whatever a project template or ecosystem convention suggests.
Frequently asked questions
- What license do most popular open-source projects use today?
- Permissive licenses — MIT, Apache 2.0 and BSD variants — are the most common choice for new infrastructure and library projects, largely because they impose the fewest conditions on commercial adoption, which maximises usage.
- Can I use different licenses for different parts of the same project?
- Yes — dual-licensing and mixed-license monorepos are both common, particularly separating a permissively-licensed SDK or client library from a copyleft-licensed core server.