Open Source Licensing: Choosing the Right License for Your Project

TL;DR: Permissive vs copyleft explained: MIT, Apache-2.0, BSD, GPL, AGPL and more. A practical decision framework for choosing a license: and what happens when you do not.

A license is the legal contract that makes code "open." Without one, copyright law defaults to "all rights reserved": nobody can legally use, modify, or redistribute your code, and nobody can prove they are allowed to contribute to it. The license is the single most important file in an open source repository after the code itself.

The Two Families: Permissive vs Copyleft. All licenses fall into two families. Permissive licenses (MIT, Apache-2.0, BSD) impose minimal conditions: anyone can use the code, including in closed-source commercial products. Copyleft licenses (GPL, AGPL) require that derivative works be distributed under the same license: if you modify and distribute the code, you must open your changes under the same terms. Neither family restricts commercial use; both allow selling software. The difference is what you must give back.

MIT: the default choice. One condition: include the copyright notice and license text when redistributing. Nothing else. It is the most widely used license on GitHub and the safest choice when your goal is maximum adoption. Libraries want MIT because companies can adopt them without legal review. If you do not know what to pick, pick MIT: you can never go wrong for small to medium projects.

Apache-2.0: MIT plus a patent grant. Apache-2.0 adds an explicit patent license: users cannot sue you for patents covering the code you contributed, and you grant them the right to use it. It also has clear terms for handling contributed work. Large foundations and companies (Google, Netflix, Apache projects) prefer it. Choose Apache-2.0 when you expect corporate contributors or users who care about patent exposure.

BSD-2 and BSD-3: MIT's cousins. Nearly identical to MIT with one extra clause in BSD-3: you cannot use the project's name to endorse products. BSD-2 drops even that. If you care about trademark protection for your brand, BSD-3 or Apache-2.0 is the pick; otherwise MIT is simpler.

GPL-3.0: the strong copyleft. If you distribute a modified version, it must be GPL-3.0 and you must provide the source. The practical effect: companies can use GPL code internally and sell products, but they cannot ship a closed-source derivative. This makes GPL unpopular inside corporations and popular in the Linux/free-software world. Choose GPL when your mission is to guarantee that all derivatives stay open.

AGPL-3.0: GPL for the network age. Adds the "network clause": using modified AGPL code as a server-side service counts as distribution. A company can host your AGPL code behind an API without shipping it: and still must publish their modifications. This is why cloud-native infrastructure projects (MongoDB originally, then SSPL; MinIO under AGPL) choose it: it protects against cloud providers reselling your work without contributing back. Choose AGPL when your software is primarily used as a hosted service.

LGPL and MPL: copyleft at the file level. LGPL allows linking from closed-source applications (only the library itself must stay LGPL): ideal for programming libraries used as dependencies. MPL (Mozilla Public License) applies copyleft only to the files you modify, leaving everything else free: good middle ground for larger codebases with mixed components.

No license means no permission. Code without a LICENSE file is protected by default copyright: nobody may legally use it, copy it, or contribute to it. Forks, tutorials, and even AI training corpora that scrape GitHub avoid unlicensed repos precisely because permission is missing. If you want any of the benefits of open source, the license file is the switch that turns them on.

Changing a license later is nearly impossible. Once code is released under a license, every contributor holds copyright over their changes: relicensing requires consent from all of them. Real-world examples: Redis moved to RSAL/SSPL, Elasticsearch moved to the Elastic License, HashiCorp moved Terraform to BSL, and the OpenTofu fork was born. Each move forked communities. The lesson: choose the license the project deserves on day one, because it becomes a constitution you cannot easily rewrite.

A practical decision framework.

- Maximum adoption, libraries, teaching, personal projects -> MIT

- Corporate contributors, patent-sensitive domains, large projects -> Apache-2.0

- Guarantee derivatives stay open, desktop/Linux software -> GPL-3.0

- Server-side infrastructure, SaaS products -> AGPL-3.0

- A library you want embedded everywhere (open or closed) -> MIT, LGPL, or MPL

- Trading communities and marketplaces -> check platform rules; many restrict GPL

The employer question. If you write code as part of employment, your employment contract may assign ownership to your employer: including open source you publish. Before releasing a project, check your company's invention assignment and open source policy. Many companies require nothing for small personal projects but reserve rights over code in their domain. A one-line written approval is cheap insurance.

The AI era changed the license conversation. Many popular "open" AI models are not open source by OSI standards: permissive "open weights" licenses (Llama community license, SAIL, gemma) allow most uses but restrict redistribution of weights or require a license for services above size thresholds. In 2025 the OSI ratified the Open Source AI Definition, giving the community an official yardstick. And if you train models on open source code, licenses matter twice: some require attribution in redistributed models, and whether copyleft survives training remains legally unsettled. Read licenses before feeding repositories into your training pipeline.

Tooling. choosealicense.com is the best interactive picker for quick decisions. TLDRLegal summarizes each license in plain language. GitHub's license picker (New repo -> Add license) generates the file for you. For inventorying dependencies later, FOSSA or ScanCode scan your stack and produce a license report that keeps legal teams happy.

The license is not a checkbox to tick before you forget about it. It is the constitution of your project: it decides who can use it, who must give back, and whether your community survives a commercial fork. Write it before your first contributor arrives, because every contributor is implicitly agreeing to it.