How to Choose a Software License for Your Next Project

Quick Summary

Publishing source code without a license leaves it under copyright by default. Other people can view it but may not have permission to use, modify, or share it.
Permissive licenses such as MIT, BSD, and Apache 2.0 allow broad reuse, including in proprietary software.
Copyleft licenses such as the GPL require people who distribute covered derivative work to provide it under the required open-source terms.
Creative Commons licenses suit writing, images, and other creative work rather than software code.
Add the full license text to a LICENSE file and declare the same license in your README and package metadata.
Check the licenses of your dependencies before distributing your project.
Relicensing becomes harder after other people contribute.

AI-generated summary based on the text of the article and checked by the author. Read more about how BUT. Honestly uses AI.

Push code to a public GitHub repository without a license and people can see it. That does not make it open source.

Copyright applies by default. Without permission from you, another person may not have the right to copy, modify, or distribute the code. A LICENSE file tells them which uses you allow and what conditions they must follow.

I choose a license before I invite anyone else to use or contribute to a project. The choice starts with what I want those people to be able to do.

Start With the Permission You Want to Give

When I choose a software license, I need answers to three questions:

Who may use the code?
What may they do with it?
Which conditions must they follow?

Most open-source choices fall into two broad groups.

Permissive licenses let people reuse the code with few conditions. They can often include it in proprietary and commercial software as long as they preserve the required notices.

Copyleft licenses require people who distribute covered derivative work to provide it under the same or compatible open-source terms. The exact obligation depends on the license and how the software is combined and distributed.

I use this distinction to ask a practical question: do I care more about broad adoption, or about keeping distributed derivatives open?

Common Open-Source Licenses

MIT License

The MIT License lets people use, copy, modify, distribute, sublicense, and sell the software. They must keep the copyright and license notice.

I consider MIT when I want a small library or educational project to spread with little friction.

I’d use it for: projects where broad reuse matters more than keeping derivatives open.

GNU General Public License

The GNU General Public License gives people permission to use, study, modify, and share covered software. If they distribute covered derivative work, the GPL requires them to provide the corresponding source under its terms.

WordPress and the Linux kernel use GPL-family licenses under different version terms. The details can become complex when GPL code interacts with other code, so I check compatibility before combining or distributing it.

I’d use it for: projects whose authors want distributed derivatives to remain open.

Apache License 2.0

Apache License 2.0 is permissive and includes an explicit patent grant from contributors. It also contains a patent-termination clause for certain patent claims.

I consider it when patent terms matter or when a company needs a familiar permissive license with more detail than MIT.

I’d use it for: larger libraries, company-backed projects, and projects that want explicit patent terms.

BSD Licenses

The 2-Clause and 3-Clause BSD licenses resemble MIT. The 3-Clause version adds a condition preventing contributors’ names from being used to endorse derived products without permission.

I’d use it for: projects that want short, permissive terms. The 3-Clause version also addresses endorsement.

Creative Commons Licenses

Creative Commons licenses are designed for creative works such as writing, documentation, images, and videos. Creative Commons recommends using established software licenses for software code.

Common options include:

CC BY: allows reuse with attribution.
CC BY-SA: requires attribution and the same license for adaptations.
CC BY-NC-SA: adds a non-commercial restriction.
CC0: waives rights to the extent the law allows so others can reuse the work without attribution.

I’d use it for: documentation, tutorials, artwork, and other non-code material.

License Comparison

License	Modify	Redistribute	Commercial Use	Keep Notice	Share Covered Derivatives	Explicit Patent Grant
MIT	✅	✅	✅	✅	❌	❌
GPL	✅	✅	✅	✅	✅	❌
Apache 2.0	✅	✅	✅	✅	❌	✅
BSD (2/3-Clause)	✅	✅	✅	✅	❌	❌
CC BY-SA	✅	✅	✅	✅	✅	❌
CC BY-NC-SA	✅	✅	❌	✅	✅	❌
CC0	✅	✅	✅	❌	❌	❌

This table leaves out details that can change the answer for a specific project. Read the license text before relying on a row.

Keeping a Project Proprietary

You do not need an open-source license for internal tools, client work, or software you want to keep proprietary.

An all-rights-reserved notice can make that intent clear:

Copyright © [Year] [Your Name or Company]
All rights reserved.

If you distribute proprietary software, an End User License Agreement can define how customers may install and use it. A lawyer should draft or review terms that govern a commercial product.

How I Narrow the Choice

1. Decide what should happen to reused code

I begin with the outcome:

Broad reuse, including proprietary products: MIT, Apache 2.0, or BSD.
Distributed derivatives must remain open: a GPL-family license.
No public reuse permission: all rights reserved or a proprietary agreement.
Creative material rather than software: a suitable Creative Commons license.

The short list is a starting point, not a substitute for reading the terms.

2. Check every dependency

A dependency’s license may place conditions on how I distribute my project. I check direct dependencies, bundled assets, copied snippets, and generated code whose origin I can identify. That includes code I produce while vibe coding.

Compatibility can depend on how two works interact and whether I distribute the result. I do not guess when the combination is unclear.

3. Account for contributors

Relicensing code becomes harder after other people own copyright in their contributions. I choose a known license before accepting contributions and explain the terms in the contribution process.

Some projects use a Contributor License Agreement. Others rely on the inbound license of each contribution. Either approach needs to be clear before the first pull request.

4. Use a standard license

A standard license gives users terms they can recognise and compare. I avoid writing a custom license unless a lawyer and a specific business need justify it.

These tools help me review established options:

Choose a License provides plain-language summaries.
GitHub’s license picker adds common licenses to a repository.
The SPDX License List provides standard identifiers and license texts.
TLDRLegal summarises common permissions and conditions.

5. Ask a lawyer when the consequences justify it

I would get legal advice before combining licenses I do not understand, relicensing code with several contributors, enforcing a license, or attaching custom terms to a commercial product.

Add the License to the Project

Choosing a license does not help users if they cannot find it.

Add the full text

I put the complete license text in a plain-text file named LICENSE or LICENSE.txt at the repository root. I fill in the holder and year when the official template includes those fields. Otherwise, I preserve the license text.

For MIT, the file begins like this:

MIT License

Copyright (c) 2026 Nicola Mustone

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction...

I copy the text from the license steward, Choose a License, or the SPDX list rather than recreating it from memory.

Declare it in package metadata

Package registries and dependency tools read the license from project metadata.

For npm:

{
  "name": "my-project",
  "license": "MIT"
}

For Python, the current packaging specification supports SPDX expressions in pyproject.toml:

[project]
license = "MIT"

For Composer:

{
  "license": "GPL-2.0-or-later"
}

I use the correct SPDX identifier and keep it consistent with the LICENSE file.

Mention it in the README

A short README line helps someone find the terms:

Licensed under the MIT License. See LICENSE for details.

Dual-licensed projects need to state the available choices and where each set of terms applies.

Add notices where the license requires them

Some projects add a short license header to source files that may travel on their own. The right notice depends on the license and project. I do not paste a long template into every file without checking what the chosen license asks me to preserve.

Changing a License Later

You can release future versions under a different license if you own the necessary rights. The new choice does not cancel permissions already granted for earlier releases.

If other people contributed code, you may need their permission before relicensing their work. A contributor agreement may have granted the project enough rights, but the agreement itself controls that answer.

I document a change in the repository and release notes so users can tell which versions use which terms.

If I publish the wrong license and notice it at once, I still do not assume rewriting Git history solves the problem. Someone may already have received a copy under those terms. I correct the repository, record what changed, and get legal advice if the mistake has consequences.

If Someone Breaks the Terms

I would begin by checking the license and documenting the suspected breach. A missing attribution notice, an unpublished source obligation, and unlicensed use raise different questions.

Black and white lithograph of diverse individuals, including a nun and a man using a magnifying glass, reading intensely at a library table. — Image from The New York Public Library on Unsplash

If the facts look clear, a private message may resolve the problem. I would include the project, the license term, and the action I want the other person to take.

A formal takedown or legal claim carries risks. Before escalating, I would preserve emails, repository links, releases, and screenshots, then speak with a lawyer. For GPL projects, organisations such as the Free Software Foundation and Software Freedom Conservancy publish compliance guidance.

I would ask them to comply rather than punish them.

Choose Before You Publish

The LICENSE file tells another developer whether they may use your work, which conditions follow it, and whether their own project can include it.

I choose before publishing, check my dependencies, and put the same answer in the license file and package metadata. That gives someone who wants to use the code a clear place to begin.

The Licenses on This Site

When I rebuilt this site from WordPress in Astro, I kept separate terms for its code and content.

The essays and images I own on this site use Creative Commons Attribution-NonCommercial-ShareAlike (CC BY-NC-SA) unless a page says otherwise. You may share and adapt them for non-commercial purposes with attribution and the same license.

Code I publish here uses GNU GPL v2 or later unless I specify another license. Third-party images, quotations, and code remain under their respective terms.