An open-source license tells people what they may do with software's source code and what conditions they must follow. A repository being public does not, by itself, grant permission to reuse its code. The license you choose affects how other developers can build on your project, and the license on a dependency affects what you can ship in your own product.
This guide explains common license families and gives you a practical checklist for choosing or evaluating a license. It is general information, not legal advice.
What does an open-source license do?
The Open Source Definition from the Open Source Initiative describes criteria for open-source licenses, including access to source code and permission to redistribute and create derived works under the license's terms. In practice, the license is the permission grant: it sets conditions for using, changing, and sharing the covered work.
Making code visible is different from licensing it. If a repository has no license, copyright still applies by default; GitHub's licensing guide explains that other people generally do not automatically get permission to reproduce, distribute, or create derivative works. Check the repository's LICENSE file and any notices before using code. For background on how a version control system tracks a project's changes, see our guide to version control systems.
An open-source license does not promise that software is free of charge, maintained, secure, stable, or supported. Those are separate questions to investigate. A project can charge for software or services while licensing code openly, and a no-cost download is not a substitute for a license grant. See Snyk's open-source license overview for another introduction.
Common open-source license types
The examples below are starting points, not a complete legal comparison. Read the exact license text and version before relying on a summary.
| License | General approach | Often considered when |
|---|---|---|
| MIT | Permissive. The license requires preserving its copyright and license notices when sharing copies or substantial portions. | You want broad reuse with relatively few conditions. |
| Apache-2.0 | Permissive, with notice requirements and an express patent grant from contributors. | You want permissive reuse and clear patent terms. |
| GPL-3.0 | Copyleft. Conditions apply when you distribute covered or derivative works, including source-code and licensing requirements. | You want distributed derivatives to remain under the GPL's terms. |
| AGPL-3.0 | Copyleft with an additional source-offer condition for users interacting with a modified version over a network. | Network access to a modified program is important to your sharing goals. |
These descriptions simplify complex terms. Whether code forms a derivative or combined work depends on the facts and applicable law; do not assume that a short table decides whether a license is compatible with your project.
How to choose a license for your project
- Decide how you want others to reuse the code. If your priority is broad adoption, compare permissive options such as MIT and Apache-2.0. If you want conditions on distributed derivatives, consider whether a copyleft license fits your goals.
- Think about how the software is delivered. A library shipped to customers, an application distributed as a download, and a network service can raise different questions. Compare GPL and AGPL requirements against your actual distribution and deployment model.
- Consider patent terms and notices. Apache-2.0 includes an express patent grant. Whichever license you select, follow its requirements for copyright notices, license copies, and any
NOTICEfile. - Check dependencies and other assets. Review direct and transitive dependency licenses, bundled fonts, images, and other included material. License compatibility depends on the licenses and how components are combined and distributed. A scanner can help inventory dependencies, but it cannot replace checking the license texts and notices.
- Make the choice explicit. Include the complete license text in a
LICENSEfile and use the matching SPDX identifier in package metadata where supported. Recheck the identifier and notices when changing license versions or dependencies.
For a repository you contribute to, verify the license text and SPDX identifier you publish, and make sure your dependency notices match the software you ship.
License obligations are separate from project health
A license describes permissions and obligations; it does not tell you whether a project is maintained or suitable for production. Before adopting a dependency, check its recent releases, issue and security history, supported versions, documentation, and whether you can replace or maintain it if needed. Also review each dependency's license and preserve required notices in your distribution.
If you are publishing a product, combining code under different licenses, or unsure whether a specific use is permitted, consult a qualified lawyer. The SPDX License List is useful for identifying standard license names and identifiers, but an identifier is not a substitute for reviewing the full license.
