Software Licenses: The Complete Guide

Every piece of software you download, copy, link against or ship comes with a license, and the license, not the price, decides what you may do with it. This guide lists the licenses you will actually meet, explains what each one allows and demands, shows which projects use them, and ends with practical rules: how to pick one for your own code, how to comply when you use other people's code, and which combinations do not mix.

Published: November 5, 2026 (7531-11-15 in the Bulgarian calendar)

This is an engineering guide, not legal advice. For a product decision with money behind it, show the actual license text to a lawyer.

Contents

1. The six questions every license answers
2. The license families
3. Comparison matrix
4. Permissive licenses
5. Public domain and "do whatever you want" licenses
6. Weak copyleft licenses
7. Strong copyleft licenses
8. Network copyleft
9. License exceptions
10. Source-available licenses (not open source)
11. Proprietary software and the "no license" trap
12. Licenses for content, fonts, hardware, data and AI models
13. Historical and niche licenses you may still meet
14. Compatibility: what can be combined with what
15. How to choose a license for your project
16. How to apply a license correctly
17. How to comply when you use other people's code
18. Contributing to others: CLA, DCO and relicensing
19. Tools for license scanning and SBOMs
20. Common mistakes
21. FAQ
22. Glossary

1. The six questions every license answers

Licenses look different but they all answer the same handful of questions. Once you can read these off a license, you can place any license you meet.

2. The license families

With those questions in hand, every license falls into one of a few families, ordered from the fewest obligations to the most.

3. Comparison matrix

The matrix covers the licenses you will meet in nine out of ten dependency trees. "GPL-compatible" means code under that license may be combined into a GPLv3 program; the GPLv2 column differs because Apache 2.0 and GPLv2 do not mix. SPDX identifiers are the short names machines and package managers use.

4. Permissive licenses

Permissive licenses ask one thing: keep the notice. They are the default choice for libraries that want maximum adoption, including inside proprietary products. The differences between them are small but real: patents, the NOTICE file, and whether the notice must also appear in binaries.

MIT License

• What it says: Do anything with the software, provided the copyright notice and the permission notice are included in all copies or substantial portions. No warranty.
• Obligations: Keep the notice. That is all. In practice you ship a LICENSE file or a credits screen listing the MIT components.
• Patents: Not mentioned. Most practitioners treat the broad "deal in the Software without restriction" wording as an implied grant, but if patents matter to you, prefer Apache 2.0.
• Used by: Node.js, React (moved from BSD+Patents to MIT in 2017 after community pushback), Ruby on Rails, Angular, Vue, jQuery, .NET, Bootstrap, Lodash, the X Window System (the "X11" variant).
• When to use it: You want the widest possible reuse, you do not care whether downstream users publish their changes, and patents are not a concern. It is the most popular license on GitHub.
• Variants: MIT-0 (MIT No Attribution) drops even the notice requirement; Amazon uses it for code samples. X11 adds a no-endorsement sentence. Expat is the name the FSF uses for the plain MIT text.

BSD 2-Clause ("Simplified" or "FreeBSD") License

• What it says: Redistribution in source form must keep the copyright notice and disclaimer; redistribution in binary form must reproduce them in the documentation or other materials. No warranty.
• Obligations: The same as MIT, stated more precisely for binaries.
• Used by: FreeBSD, NetBSD, many C libraries.
• When to use it: Interchangeable with MIT. Pick whichever your ecosystem favours.

BSD 3-Clause ("New" or "Modified") License

• What it says: BSD-2 plus a third clause: the names of the copyright holder and contributors may not be used to endorse or promote derived products without written permission.
• Obligations: Keep the notice; do not advertise with the authors' names.
• Used by: Go, Django, Flask, NumPy, SciPy, pandas, Valkey, Redis before March 2024, Chromium, the old LLVM (NCSA/BSD) code.
• When to use it: You are a company or university and want it explicit that forks cannot trade on your name. Google and many academic projects default to it.
• History: The original BSD 4-Clause had an "advertising clause" demanding that all advertising mention the University of California. It is GPL-incompatible and effectively dead; do not pick it.

ISC License

• What it says: Functionally identical to MIT and BSD-2, written in fewer words.
• Used by: OpenBSD, OpenSSH, BIND 9, and it is the default license npm init writes into a new package.json.
• When to use it: You like short licenses. There is no practical difference from MIT.

Apache License 2.0

• What it says: A permissive grant like MIT, but written out in full legal detail. Section 3 grants every contributor's patents that cover their contribution; the grant terminates for anyone who files a patent suit claiming the work infringes. Section 4 requires that you keep notices, mark modified files as changed, and preserve the NOTICE file if the project ships one. Section 6 says the license grants no trademark rights.
• Obligations: Keep LICENSE and NOTICE; add a note to files you changed; keep attribution notices in source. The NOTICE file is the obligation people forget: if a dependency has one, its contents must travel with your distribution.
• Patents: The explicit patent grant plus retaliation clause is the reason large companies prefer Apache 2.0 over MIT for anything that might touch their patent portfolio.
• Compatibility: Compatible with GPLv3 (the FSF lists it as such). Not compatible with GPLv2: the patent termination clause is a restriction GPLv2 does not allow. This matters for anything that must link into the Linux kernel, which is GPLv2-only.
• Used by: Kubernetes and nearly all CNCF projects, Android (AOSP), TensorFlow, Apache Kafka, Hadoop, Spark, Swift, Rust (dual MIT or Apache 2.0), OpenSearch, OpenSSL 3.x, most Mistral and Qwen AI models.
• When to use it: The default for company-backed open source, foundations, and anything where patents could plausibly exist. If you would have picked MIT but want patent protection, pick this.

zlib License

• What it says: Permissive; altered source versions must be plainly marked as altered and must not be misrepresented as the original; the notice may not be removed from source distributions. Binaries need no notice at all.
• Used by: zlib, libpng (its own near-identical license), SDL 2, Bullet physics, many game-development libraries.
• When to use it: Libraries aimed at games and embedded products where a credits screen is impractical.

Boost Software License 1.0

• What it says: Permissive; the notice must be kept in source copies but, explicitly, not in machine-executable binaries.
• Used by: Boost, Catch2, Hyperscan, some SQLite extensions.
• When to use it: Header-only C++ libraries, where "ship the notice with every binary" is a nuisance.

PostgreSQL License

• What it says: An MIT-style notice-only license with a slightly different warranty disclaimer.
• Used by: PostgreSQL and most of its extensions.

Python Software Foundation License

• What it says: A permissive, GPL-compatible license covering CPython; derived works must include a brief summary of changes. It is a stack of historical licenses (CWI, CNRI, BeOpen, PSF) because of Python's corporate history.
• Used by: CPython itself. Most Python packages use MIT, BSD or Apache instead.

Artistic License 2.0

• What it says: Permissive with a twist: you may distribute modified versions, but either under this license, or you must make your changes freely available, or you must rename the modified version so it is not confused with the original.
• Used by: Perl 5 (dual Artistic 1.0 or GPL), Raku, many CPAN modules.
• Note: Version 1.0 is considered vague and is not GPL-compatible; 2.0 fixed both.

University of Illinois / NCSA License

• What it says: MIT's permission combined with BSD-3's no-endorsement clause.
• Used by: LLVM and Clang until 2019 (they moved to "Apache-2.0 WITH LLVM-exception").

Microsoft Public License (MS-PL)

• What it says: Permissive with a patent grant; derived source must stay under MS-PL, binaries may use any license that complies. Not GPL-compatible.
• Used by: Older Microsoft open source releases. Microsoft now uses MIT for almost everything (.NET, VS Code, TypeScript, PowerShell).

5. Public domain and "do whatever you want" licenses

A public domain dedication gives up copyright entirely. The trouble is that several countries, including Germany and France, do not let an author waive their rights, so a bare "this is public domain" statement is legally uncertain outside the United States. The licenses below exist to get the same result in a way that works everywhere.

CC0 1.0 Universal

• What it says: The author waives all copyright and related rights to the fullest extent allowed, and where a waiver is not possible grants an unconditional license instead.
• The catch: CC0 explicitly does not grant any patent rights. For that reason the Fedora project stopped accepting CC0 for code in 2022, and the Open Source Initiative never approved it. It remains excellent for data, images and text.
• Used by: Government data sets, Wikimedia Commons uploads, many icon and photo collections, the SQL standard test suites.

The Unlicense

• What it says: A public domain dedication with a fallback unconditional license and a warranty disclaimer, written for software.
• Used by: youtube-dl, many small utilities and code samples.
• Note: OSI-approved, GPL-compatible. Lawyers at large companies sometimes still prefer 0BSD or MIT-0 because those are clearly licenses rather than dedications.

0BSD (Zero-Clause BSD)

• What it says: The ISC permission, with the notice-preservation requirement removed. It is a license, not a dedication, so it works in every jurisdiction.
• Used by: Toybox, parts of Android and Linux firmware, a growing share of Rust crates and TypeScript packages.
• When to use it: You want "no obligations at all" and want it to be unambiguous. This is the safest way to say it.

WTFPL

• What it says: "Do What The F*** You Want To Public License." It is one sentence long.
• Note: GPL-compatible per the FSF, not OSI-approved, and the wording makes corporate legal reviewers nervous. Use 0BSD if you mean it seriously.

SQLite's public domain

SQLite is the best-known public domain software. Its authors dedicate the code to the public domain and, for companies whose lawyers cannot accept that, sell a Warranty of Title. That sale exists precisely because of the jurisdictional problem described above.

6. Weak copyleft licenses

Weak copyleft draws a boundary around the licensed code. Inside the boundary, changes must be shared under the same license. Outside it, your own code may be proprietary. The licenses differ in where they draw the line: a file, a module, or a library.

Mozilla Public License 2.0

• The boundary: the file. Any file that contains MPL code, or that you created by copying from MPL files, must stay under MPL and its source must be available to recipients. Files you wrote yourself, even in the same program, even statically linked, are yours.
• Patents: Explicit grant with retaliation.
• Compatibility: MPL 2.0 was designed to combine with the GPL family: an MPL file may be included in a GPL, LGPL or AGPL program under those licenses, unless the project added the "Incompatible With Secondary Licenses" notice.
• Used by: Firefox, Thunderbird, LibreOffice, OpenTofu, HashiCorp's Terraform, Vault, Consul and Nomad until August 2023, Eigen, the Servo engine.
• When to use it: You want fixes to your library to come back, but you do not want to stop anyone from using it inside a closed product. It is the gentlest copyleft and the easiest to explain to a legal department.

GNU Lesser General Public License 2.1 and 3.0

• The boundary: the library. Modifications to the library itself must be released under the LGPL. A program that merely uses the library may be under any license, provided the user can replace the library with a modified version. In practice that means: dynamic linking is fine; static linking is fine only if you also ship your object files (or source) so the user can relink.
• LGPL 3.0 differences: It is written as a set of exceptions on top of GPLv3, so it inherits GPLv3's patent grant and anti-tivoization terms. GPLv2-only projects cannot use LGPLv3 libraries.
• Used by: glibc (2.1), FFmpeg (2.1 or later, with some GPL parts that turn the whole build GPL if enabled), GTK, GStreamer, libVLC, Qt's open source edition (LGPL 3), Wine, OpenAL Soft, .NET's older Mono runtime.
• When to use it: You are writing a library and want to be usable by proprietary applications while keeping improvements to the library itself open. If you would be happy with MPL 2.0, prefer it; the LGPL's linking rules are harder to comply with for static builds, iOS apps and embedded firmware.

Eclipse Public License 2.0

• The boundary: the module. Modified EPL code must be released under EPL; your own modules that use it may be proprietary.
• Patents: Explicit grant with retaliation.
• Compatibility: EPL 2.0 alone is GPL-incompatible. A project may add the "secondary license" option that lets the code also be used under GPLv2 or later; many Eclipse Foundation projects do.
• Used by: Eclipse IDE, Jakarta EE, JUnit 5, Clojure (EPL 1.0), Jetty (dual EPL 2.0 / Apache 2.0).

Common Development and Distribution License 1.0 / 1.1

• The boundary: the file, like MPL 1.1 from which it was derived by Sun Microsystems.
• Compatibility: GPL-incompatible. This is why OpenZFS, which is CDDL, cannot be merged into the Linux kernel and ships as a separate module, and why Canonical's decision to bundle ZFS with Ubuntu was controversial.
• Used by: OpenZFS, illumos and its distributions, DTrace originally, old NetBeans and GlassFish releases.
• When to use it: Do not pick it for a new project. MPL 2.0 does the same job and is GPL-compatible.

7. Strong copyleft licenses

Strong copyleft follows the code wherever it goes. If you distribute a program that contains GPL code, whether linked, copied or compiled in, the recipient must get the complete corresponding source of the whole program under the GPL. The point is to guarantee that users of the software always have the freedom to study and change it. The cost is that proprietary products cannot incorporate it.

GNU General Public License 2.0

• What it says: You may copy, modify and distribute. Distributing binaries requires providing the complete source, either alongside or by a written offer valid for three years. Modified files must carry notices. The whole work "as a whole" must be under the GPL; "mere aggregation" on the same medium is exempt.
• "only" versus "or later": GPLv2 text says you may use "version 2 or, at your option, any later version" if the author said so. Linux chose "only", so Linux is GPLv2 and nothing else; GPLv3 code cannot be merged into it. Always write which you mean: SPDX uses GPL-2.0-only and GPL-2.0-or-later.
• The Linux syscall note: Linus Torvalds added a note that user-space programs calling the kernel through normal system calls are not derived works. That is why proprietary applications can run on Linux at all, and why out-of-tree proprietary kernel modules remain a grey area.
• Used by: the Linux kernel, Git, MySQL (with a FOSS exception for clients), WordPress (or later), U-Boot, Qt (one of its options), Audacity, Bitcoin Core (MIT, a common mix-up), VirtualBox.
• When to use it: Only when you need to interoperate with an existing GPLv2-only code base. For new work, GPLv3 is the better-drafted license.

GNU General Public License 3.0

• What changed from v2: an explicit patent grant and retaliation clause; the anti-tivoization requirement that consumer devices shipping GPLv3 code include "Installation Information" so the owner can install modified versions; explicit compatibility with Apache 2.0; a cure period for accidental violations; internationalised wording that does not depend on US copyright terms.
• Compatibility: Compatible with Apache 2.0, MPL 2.0, LGPL, and with AGPLv3 through a dedicated clause. Not compatible with GPLv2-only.
• Used by: GCC (with the runtime library exception), Bash, coreutils, GIMP, Ansible, Samba, Emacs, Inkscape, Krita, most GNU software.
• When to use it: You want every distributed derivative to stay free and you are not shipping a web service. Note that many companies forbid GPLv3 on devices because of the installation-information clause; that is the clause working as designed.

European Union Public Licence 1.2

• What it says: A strong copyleft licence written by the European Commission, legally valid in 23 languages, with network use counted as distribution. Its appendix lists licenses a derivative may be relicensed under (GPLv2, GPLv3, AGPLv3, LGPL, MPL 2.0, EPL, CeCILL, OSL and others), which is how it stays compatible with the GPL family despite being a different licence. It is best described as a compatible copyleft: it reaches as far as the AGPL, including software offered as a service, but it was drafted to be enforceable under the law of every EU member state and to combine with the other copyleft licences instead of competing with them.
• Used by: Software published by EU institutions and many European public administrations.
• When to use it: You are a European public body, or you specifically want a copyleft licence drafted under EU law.

Open Software License 3.0

• What it says: Strong copyleft with network use as distribution, from Lawrence Rosen, with a patent grant. GPL-incompatible.
• Used by: Magento Open Source (OSL 3.0), a handful of others. Rare today.

8. Network copyleft

Under the ordinary GPL, running modified software on your own servers and letting the public use it over the network is not distribution, so you owe nobody the source. Companies built whole businesses on that gap, often called the "ASP loophole". Network copyleft closes it.

GNU Affero General Public License 3.0

• What it says: GPLv3 plus section 13: if you modify the program and let users interact with it remotely through a network, you must offer those users the complete corresponding source of your modified version.
• What it does not say: It does not require you to publish your source for merely using an unmodified AGPL program as a service, and it says nothing about data stored in it or about other programs that talk to it over a network protocol. The obligation is triggered by modification plus network interaction.
• Why companies avoid it: Google's internal policy bans AGPL code outright, and many others follow, because the boundary of "modified version" in a large service is hard to prove in either direction. That caution is exactly why projects that want to stop cloud providers from reselling them choose it.
• Used by: Nextcloud, Mastodon, Grafana (since 2021), MinIO (since 2021), Redis 8 (since May 2025, after a year under RSALv2), Elasticsearch and Kibana (as one option since August 2024), Ghostscript, Odoo Community, Plausible Analytics, Bitwarden server, Forgejo (since 2024).
• When to use it: You are shipping a server or a hosted application and want anyone who runs a modified copy for the public to share their changes. Pair it with a commercial license if you plan to sell exceptions.

9. License exceptions

An exception is extra permission attached to a copyleft license to make it workable in a specific situation. SPDX writes them with WITH: GPL-2.0-only WITH Classpath-exception-2.0.

10. Source-available licenses (not open source)

Starting around 2018, a series of venture-backed infrastructure companies moved away from open source licenses because cloud providers were selling hosted versions of their products without contributing back. The replacement licenses let you read, modify and usually run the code, but restrict a specific use, typically "offering it as a competing managed service". None of them is approved by the Open Source Initiative, and most Linux distributions and corporate open source policies treat them as proprietary. Each major switch produced a community fork under a real open source license.

Business Source License 1.1

• What it says: Written by MariaDB. Non-production use is always allowed; production use is allowed only within an "Additional Use Grant" the licensor defines (HashiCorp's grant forbids embedding in a product that competes with HashiCorp). On the "Change Date", at most four years after each release, that version converts automatically to a named open source license, usually MPL 2.0 or Apache 2.0.
• Used by: HashiCorp Terraform, Vault, Consul, Nomad, Boundary and Waypoint; MariaDB MaxScale; Couchbase Server; CockroachDB until 2024.
• Practical reading: You can almost always use BSL software internally. You cannot build a hosted product on it. Each release becomes open source four years later, so old versions are safe.

Server Side Public License 1.0

• What it says: AGPLv3 with section 13 rewritten: if you offer the program as a service, you must release the source of your entire service stack (management software, user interfaces, APIs, monitoring, backup, hosting software) under the SSPL. That demand is considered impossible to meet, which is the intent.
• Used by: MongoDB; Elasticsearch and Kibana as one option from 2021.
• Status: MongoDB withdrew its OSI submission in 2019 after it became clear it would be rejected. Debian, Fedora and Red Hat treat SSPL software as non-free.

Elastic License 2.0

• What it says: A short license with three restrictions: you may not provide the software as a managed service to third parties, you may not circumvent license keys, and you may not remove notices. Everything else is allowed, including commercial use and modification.
• Used by: Elasticsearch and Kibana (one of three options), Airbyte, several Elastic-ecosystem projects.
• Practical reading: The most permissive of the source-available licenses for ordinary users. Only hosting providers are affected.

Redis Source Available License v2

• What it says: Similar in effect to the Elastic License: no managed services, no removing notices. Redis 7.4 shipped under RSALv2 or SSPL; Redis 8 added AGPLv3 as a third option.

Functional Source License

• What it says: From Sentry, 2023. You may use the software for anything except a product that competes with the licensor; after two years each version converts to Apache 2.0 or MIT. It is BSL with a shorter clock and a clearer competition clause.
• Used by: Sentry, GitButler, Codecov.

Commons Clause

• What it says: Not a license but a rider added to an existing one ("Apache 2.0 + Commons Clause") that removes the right to sell the software or a service whose value derives substantially from it. The rider contradicts the base license, which is why Redis Labs dropped it for RSAL after a year. Treat anything carrying it as proprietary.

PolyForm licenses

• What it says: A family of plain-language source-available licenses: PolyForm Noncommercial, Internal Use, Small Business, Shield (no competing products), Perimeter. They are used by small vendors who want something more predictable than a custom EULA.

Fair Source

"Fair Source" is a label, not a license. It describes software published under a source-available license with a delayed conversion to open source, such as the FSL or BSL. Projects use the term to signal that the restriction is temporary.

11. Proprietary software and the "no license" trap

Copyright applies automatically. A repository on GitHub with no LICENSE file is not free to use, copy or fork for any purpose beyond what GitHub's own terms grant (viewing and forking within GitHub). This surprises people constantly. Code posted without a license is "all rights reserved", and a company that copies it into a product has no defence. If you find such code and want to use it, ask the author to add a license.

Proprietary licenses, meaning EULAs and commercial agreements, grant exactly what they say and nothing more. The common clauses to look for: per-seat or per-core limits (see our Licensing Check Before a Migration), no reverse engineering, no redistribution, no benchmarking without consent, audit rights, and automatic renewal. The economics of choosing between a proprietary product and an open source one are covered in Vendor and Licensing Comparison.

Dual licensing combines the two worlds. The same code is offered under a copyleft license (usually GPL or AGPL) to the public and under a commercial license to customers who cannot or will not comply with the copyleft terms. Qt, MySQL, Ghostscript, iText, MongoDB before 2018 and Oracle Berkeley DB all use or used this model. It works only when a single entity holds the copyright, which is why such projects require a contributor agreement.

12. Licenses for content, fonts, hardware, data and AI models

Creative Commons (text, images, audio, video)

Creative Commons licenses are built from four conditions that can be combined. CC itself says they are not suitable for software: they lack patent terms, say nothing about source code, and the NC and ND variants are not free. Use them for documentation, images and data, not for code.

One consequence worth knowing: code pasted from Stack Overflow is CC BY-SA 4.0. Strictly read, copying a non-trivial snippet into a proprietary product requires attribution and, under ShareAlike, could require releasing the containing work. In practice short snippets are treated as unprotectable, but the obligation to attribute is real.

GNU Free Documentation License

A copyleft license for manuals, with awkward "invariant sections" that cannot be changed. Wikipedia started under it and migrated to CC BY-SA in 2009 because the GFDL was impractical for a wiki. GNU manuals still use it. For new documentation, CC BY-SA or CC BY is simpler.

Fonts

• SIL Open Font License 1.1: The standard. Free to use, embed and modify; modified versions must change the "Reserved Font Name"; fonts may not be sold on their own but may be bundled with software. Almost everything on Google Fonts uses it: Roboto is Apache 2.0, nearly all the rest OFL.
• Ubuntu Font License: Similar to OFL with different naming rules.
• Proprietary fonts: Commercial fonts usually license desktop use, web use and app embedding separately. Check before converting a desktop font to WOFF.

Hardware designs

• CERN Open Hardware Licence 2.0: Comes in three variants that mirror software families: CERN-OHL-P (permissive), CERN-OHL-W (weakly reciprocal), CERN-OHL-S (strongly reciprocal). Used by the White Rabbit project, many open hardware boards.
• TAPR Open Hardware License: The older copyleft hardware license from the amateur radio community.
• Solderpad Hardware License: Apache 2.0 adapted for hardware; used by lowRISC and parts of the RISC-V ecosystem.
• Note: Copyright covers design files, not the physical object; patents and design rights are a separate matter. Open hardware licenses do what they can within that limit.

Data

• Open Database License (ODbL): ShareAlike for databases. OpenStreetMap uses it; the famous consequence is that a data set merged with OSM data must be published under ODbL too.
• ODC Attribution and PDDL: The attribution-only and public domain members of the same family.
• Community Data License Agreement (CDLA) 2.0: Linux Foundation licenses in Permissive and Sharing variants, written so that results computed from the data (including trained models) carry no obligations.
• CC BY 4.0 and CC0: The most common choices for government and research data.

AI models and weights

Model weights are a new category and the licensing is unsettled. Whether weights are copyrightable at all is untested in court; licensors act as if they are. The main patterns:

• Apache 2.0 or MIT: Genuinely open. Mistral's open models, most Qwen models, DeepSeek (MIT), Falcon, Phi, OLMo (Apache 2.0, with training data and code published too).
• Llama Community License: Meta's custom license. Free for most uses, but services with more than 700 million monthly active users need a separate license, outputs may not be used to improve other models (relaxed in later versions), and "Built with Llama" branding is required. Not open source by the OSI definition, however it is marketed.
• Gemma Terms of Use: Google's custom terms with a usage policy the licensor may update. Same category as Llama.
• OpenRAIL and CreativeML OpenRAIL-M: "Responsible AI Licenses" that are permissive except for a list of prohibited uses (harassment, disinformation, medical advice and so on). Stable Diffusion 1.x and 2.x, BLOOM. The use restrictions make them not open source by definition, whatever one thinks of the restrictions.
• The Open Source AI Definition: The OSI published version 1.0 in October 2024. It requires that weights, code and enough information about training data be available under open terms to let someone rebuild a substantially equivalent system. Few models qualify.

13. Historical and niche licenses you may still meet

14. Compatibility: what can be combined with what

Two licenses are compatible when code under both can be combined into one program and distributed without violating either. The rules of thumb:

• Permissive code goes anywhere. MIT, BSD, ISC, zlib and 0BSD code can be included in a program under any other license, including proprietary ones, as long as the notices travel along.
• Apache 2.0 goes anywhere except GPLv2-only. Its patent retaliation clause is an extra restriction GPLv2 does not permit. GPLv3 explicitly allows it.
• Weak copyleft fits inside strong copyleft. MPL 2.0 and LGPL code can be used inside a GPL or AGPL program; EPL only with its secondary-license option; CDDL not at all.
• Copyleft flows downhill only. You may take GPLv2-or-later code into a GPLv3 program, LGPL into GPL, GPLv3 into AGPLv3. You may never go the other way: AGPL code cannot become GPL, GPL code cannot become MPL or MIT.
• GPLv2-only and GPLv3 do not mix. The two most common victims: wanting to use a GPLv3 library in a GPLv2-only project, and wanting Apache 2.0 code in a Linux kernel module.
• Nothing copyleft fits inside a proprietary program unless you keep it at arm's length: a separate process talking over a pipe or socket, or an LGPL library dynamically linked with the relinking requirement honoured.

15. How to choose a license for your project

Work through these in order. Most projects are done after the second question.

1. Are you contributing to an existing ecosystem? Use its license. A Rust crate is MIT or Apache 2.0; a Linux kernel module is GPLv2; a Django app is BSD-3; a WordPress plugin is GPLv2-or-later; an Eclipse plugin is EPL 2.0. Fighting the ecosystem costs you users.
2. Do you mind if someone makes it proprietary? If no, pick MIT (simplest) or Apache 2.0 (if patents could matter or a company is behind it). If you do mind, continue.
3. Is it a library? Pick MPL 2.0. Changes to your files come back, and proprietary applications can still use it. Pick LGPL only if your ecosystem expects it.
4. Is it an application that users run locally? Pick GPLv3. Anyone who ships it must ship the source.
5. Is it a server, a SaaS product or a database? Pick AGPLv3. Anyone who runs a modified copy for the public must publish their changes. Decide now whether you will also sell commercial licenses; if so, you need a CLA from day one.
6. Do you want to forbid competitors from hosting it? Then you have left open source. Be honest about it, use FSL or BSL with a short conversion clock, and expect the community to treat the project as proprietary.
7. Is it a sample, a snippet or a tutorial? Pick 0BSD or CC0 so nobody has to carry a notice for ten lines of code.
8. Is it not code? Documentation: CC BY 4.0 or CC BY-SA 4.0. Fonts: OFL 1.1. Data: CC BY 4.0, CC0 or ODbL. Hardware: CERN-OHL.

Two useful sites: choosealicense.com (GitHub's guide, short) and opensource.org/licenses (the authoritative list of what counts as open source). The FSF keeps a commented list with GPL compatibility for each license.

Whatever you choose, do not write your own. A custom license is a liability for every user who has to get it reviewed, and most "I just removed one clause" licenses have unintended effects. The one legitimate customisation is an exception attached to a standard license.

16. How to apply a license correctly

1. Add a LICENSE file at the root of the repository containing the full, unmodified license text. GitHub, GitLab and package registries detect it from there. Name it LICENSE or LICENSE.txt; for the GPL family COPYING is traditional.
2. Fill in the copyright line where the license has one: Copyright (c) 2026 Your Name or Company. A year range is fine; do not bother updating it every January.
3. Declare it in the package metadata. The license field in package.json, pyproject.toml, Cargo.toml, composer.json, the pom, the gemspec. Use the SPDX identifier exactly: MIT, Apache-2.0, GPL-3.0-or-later, not "GPL" or "GPLv3".
4. Add SPDX headers to source files. One comment line at the top of each file: SPDX-License-Identifier: Apache-2.0. The Linux kernel, LLVM and most large projects do this; it lets scanners classify every file without guessing. The REUSE specification from the FSFE standardises the layout and has a linter.
5. For Apache 2.0, consider a NOTICE file with attribution lines you want downstream to carry. Keep it short; everything in it becomes an obligation for your users.
6. For GPL or AGPL, write "or later" or "only" explicitly in the header and metadata. Silence creates arguments later.
7. For dual licensing, say so in the README and name both licenses: "Licensed under either MIT or Apache 2.0, at your option" is the Rust convention, with both files present.
8. Mention the license in the README in one line, with a link to the file.
9. Do not change the license text. If you need extra permission, add a separate exception file and reference it. If you need extra restriction, you are no longer using that license and must not call it by its name.

SPDX license expressions cover the combinations: MIT OR Apache-2.0 for dual licensing, GPL-2.0-only WITH Classpath-exception-2.0 for an exception, Apache-2.0 AND MIT for a package that contains parts under each. The full identifier list is at spdx.org/licenses.

17. How to comply when you use other people's code

Compliance is a function of two things: what license the code is under, and whether you distribute it. Internal use, meaning your own employees running it on your own machines, triggers no obligations under any open source license. Distribution means giving a copy to someone outside your legal entity: selling a device with the code on it, publishing an app, shipping a container image to a customer, pushing an image to a public registry, or (AGPL only) letting the public use a modified version over the network.

Permissive dependencies (MIT, BSD, ISC, Apache 2.0)

• Ship the license text and copyright notices of every dependency with your product. For a web app, a /licenses page or a THIRD-PARTY-NOTICES file; for a mobile app, an "Open source licenses" screen; for a device, a file on the device or in the manual.
• For Apache 2.0 dependencies, include the contents of their NOTICE files and note which files you modified.
• Do not use the project's name or logo as if you were affiliated.

Weak copyleft dependencies (MPL, LGPL, EPL)

• If you changed the dependency, publish your modified files (MPL) or modified library (LGPL) under the same license, and tell recipients where to get them.
• For LGPL, link dynamically, or if you must link statically, provide your object files or source so the user can relink against a modified library. Mobile and embedded builds often fail this test; many teams simply avoid LGPL there.
• Keep the license text and notices as for permissive code.

Strong copyleft dependencies (GPL, AGPL)

• If GPL code is compiled or linked into your program and you distribute it, the whole program must be released under the GPL with its complete corresponding source: everything needed to build and install it, including build scripts, but not the compiler or the operating system.
• Provide the source in one of the permitted ways: alongside the binary, or a written offer valid for three years (GPLv2) or a network server available as long as you offer the product (GPLv3), or for a user-run package, a download link next to it.
• GPLv3 on consumer devices: ship the installation information (signing keys or instructions) that lets the owner install a modified version, unless the device's firmware is not updatable at all.
• Keeping the GPL program as a separate process that your proprietary code talks to over a socket, pipe or command line is generally accepted as not creating a derived work. Shared memory, plugins loaded into the same process, and tight RPC designed to evade the license are not. This line is argued over; get advice before relying on it.
• AGPL: if you modify the program and users interact with it over a network, add a visible "Source" link that leads to your modified source. If you did not modify it, nothing is required, but prove that you can show the hash of the deployed version matches an upstream release.
• GPL does not require you to publish to the world. You must give source to the people you distributed binaries to; they are free to publish it onward.

Keep an inventory

You cannot comply with licenses you do not know you have. Generate a software bill of materials (SBOM) in the build, in SPDX or CycloneDX format, with the license of each component. The tools in section 19 do this. Review it at every release and whenever a dependency changes its license, which happens more often than people expect, as section 10 shows.

18. Contributing to others: CLA, DCO and relicensing

When you contribute code to a project, the project needs to know it has the right to distribute your contribution under its license. There are two mechanisms, and the choice tells you something about the project.

• Developer Certificate of Origin (DCO): You add Signed-off-by: Name <email> to each commit, certifying that you wrote the code or have the right to submit it under the project's license. You keep your copyright. The Linux kernel, Docker, GitLab and most Linux Foundation projects use it. There is nothing to sign.
• Contributor License Agreement (CLA): A document you (or your employer) sign once, granting the project owner a broad license to your contribution, sometimes including the right to relicense it. Apache projects, Google, Microsoft, the Python Software Foundation and most companies with dual-licensing models require one. Some CLAs are copyright assignments, which transfer ownership entirely; the FSF requires those for GNU projects.

The practical consequence is relicensing. A project can change its license only with the consent of every copyright holder, or if a CLA gave the owner the right to do it unilaterally. HashiCorp, Elastic, Redis and MongoDB could switch to source-available licenses because contributors had signed CLAs. Projects without CLAs, like the Linux kernel, are effectively locked to their license forever, which some maintainers consider a feature. If you contribute substantial work to a CLA project, understand that the owner may later take it proprietary; the open version you contributed to remains open, but the future does not.

Employees: your employer usually owns code you write on the job, and in many contracts code you write at home on the same subject too. Check before contributing, and expect company-backed projects to require a corporate CLA signed by someone authorised to sign for the company.

19. Tools for license scanning and SBOMs

20. Common mistakes

• No LICENSE file. Your project is proprietary by default and nobody can legally use it. Half the "open source" repositories on GitHub have this problem.
• Thinking "free" means "no obligations". Even MIT requires the notice. Shipping a product with MIT code and no attribution file is a license violation, just a rarely enforced one.
• Forgetting the Apache NOTICE file. It is the most commonly missed obligation in permissive compliance.
• Using Creative Commons for code, or CC0 for code in a corporate setting. CC says not to; the patent gap is the reason.
• Copying Stack Overflow answers without attribution. They are CC BY-SA.
• Writing "GPL" without a version. Which one? Only or later? Scanners and lawyers both need the answer.
• Mixing GPL into a proprietary product because "we only use a small part". There is no small-part exception.
• Mixing Apache 2.0 into a GPLv2-only program, most often a kernel module.
• Assuming AGPL applies to clients or data. It applies to the modified server program, not to what talks to it.
• Assuming AGPL does not apply to SaaS. It applies to SaaS; that is its sole purpose.
• Treating source-available as open source. BSL, SSPL and ELv2 software fails most corporate open source policies and all Linux distribution policies.
• Changing the license of code others contributed without their consent or a CLA that allows it.
• Vendoring a dependency and dropping its license header. Copying the file is fine; removing the notice is not.
• Using the project's trademark. Shipping a rebuilt Firefox as "Firefox" or a rebuilt Docker as "Docker" violates trademark law regardless of the code license. Debian's "Iceweasel" era is the historical example.
• Trusting package metadata blindly. The license field is self-reported and sometimes wrong; "MIT" packages with GPL files inside exist.
• Writing a custom license. Every user has to get it reviewed, and most reviewers will say no.

21. FAQ

Can I use GPL software commercially?

Yes. Every open source license allows commercial use. The GPL restricts how you may distribute it, not whether you may charge for it. Red Hat built a company selling GPL software.

Can I use GPL software in my company without publishing anything?

Yes, as long as you do not distribute it outside the company. Internal use is not distribution. For AGPL, running a modified copy that the public interacts with over the network is the exception.

Does running MIT or Apache code in my SaaS product obligate me to anything?

Technically a SaaS product is not distributed, so even the notice requirement is arguably not triggered. Publishing a licenses page anyway is good manners and costs nothing.

If I use an MIT library, must my project be MIT?

No. Permissive licenses impose nothing on the containing work. Your project can be proprietary, GPL or anything else, as long as the MIT notice is kept.

If I use an MPL library, must my project be MPL?

No. Only the MPL files themselves, and files you created from them, must stay MPL. Your own files are yours.

If I use a GPL library, must my project be GPL?

If you distribute the combination, yes. If you keep it internal, no. If the library is LGPL and you link dynamically, no.

What happens if I violate a license?

The license terminates and you are infringing copyright. In practice the copyright holder or an organisation like the Software Freedom Conservancy writes to you, you fix it, and the GPLv3 reinstates your license if you cure within 30 days. Court cases are rare but real: Artifex vs Hancom (Ghostscript), the BusyBox cases, and in 2024 the Vizio case in California, which recognised that users can enforce the GPL as third-party beneficiaries.

Can a project change its license?

Only with every copyright holder's consent or a CLA that grants the right. The old versions remain under the old license forever; nobody can take back a license already granted on code already released. That is why forks of relicensed projects are legal.

Is a license a contract?

Courts in the United States have treated open source licenses as both licenses and contracts depending on the claim (Jacobsen v. Katzer, Artifex v. Hancom). In Germany the GPL has been enforced repeatedly as a valid license. Practically, assume it is enforceable.

Which license do most projects use?

MIT, by a wide margin, then Apache 2.0, then GPLv3 and BSD-3. Copyleft's share has fallen steadily since 2010 as company-backed projects came to dominate.

What does "copyleft" actually mean?

A copyright license that uses the author's exclusive rights to require that derivative works carry the same freedoms. The word is a pun on copyright; the GPL is the canonical example.

What is "OSI-approved" and why does it matter?

The Open Source Initiative reviews licenses against the Open Source Definition and keeps a list of those that pass. Corporate policies, Linux distributions and funding bodies often say "OSI-approved licenses only", so a project on a non-approved license, however permissive, is excluded from them.

22. Glossary

Licence texts referenced: opensource.org, gnu.org/licenses, mozilla.org/MPL, apache.org, creativecommons.org, spdx.org. Project license facts are as published by each project at the date above; projects change licenses, so check the LICENSE file of the version you use.