Every time you install an app, download a library, or copy a snippet from a public repository, you are agreeing to a software license. These short legal documents quietly shape what you, your team, and your business are allowed to do with code: whether you can copy it, modify it, sell it, embed it in a product, or publish it inside a service. They are easy to ignore until a customer, lawyer, or auditor asks the awkward question — under what terms are you using this?
This guide explains the most common software license families in plain English, with concrete examples and the official sources that define them. It is not legal advice, but it should give you a confident mental map so you can recognize a license, understand its typical obligations, and know when to escalate to counsel.
What a Software License Actually Controls
In most jurisdictions, software is protected by copyright the moment it is written. According to the U.S. Copyright Office, computer programs are treated as literary works for registration purposes, which means the author has exclusive rights over copying, distributing, and creating derivative works. A software license is the legal mechanism that grants other people permission to do some of those things under stated conditions.
In practical terms, a license usually addresses questions such as:
- Who may use the software, on how many devices, and for what purpose?
- May the user modify the source code, and if so, must changes be shared?
- May the user redistribute the software, in original or modified form?
- Are there attribution, notice, or branding requirements?
- Are patent rights granted along with copyright permissions?
- What warranties and liabilities are disclaimed?
The answers vary dramatically across license families. The same line of code, released under different licenses, can be treated as a public gift in one project and as a strictly controlled commercial asset in another.
Open Source vs. Proprietary Licenses
At the highest level, licenses fall into two broad camps: open source and proprietary. The Open Source Initiative (OSI) maintains a list of approved licenses that meet the Open Source Definition, which requires, among other things, free redistribution, available source code, and the right to create derivative works. If a license is not on the OSI list, calling the software “open source” is at best imprecise.
Open Source in Brief
Open source licenses grant broad permissions to use, study, modify, and redistribute the code, usually in exchange for preserving notices and respecting any source-sharing obligations. They are typically free of monetary cost, but “free” here refers to freedom, not necessarily price.
Proprietary in Brief
Proprietary licenses keep most rights with the vendor. Users normally receive a limited right to install and run the software for a specific purpose, often tied to a paid subscription, a per-seat count, or a particular device. Source code is rarely included, and modification or redistribution is usually forbidden.
Neither camp is inherently better. The right choice depends on your business model, distribution plans, risk tolerance, and how much control you need over how the code evolves.
Permissive Licenses: MIT, BSD, and Apache 2.0
Permissive licenses are the most flexible category of open source. They allow nearly any use, including in closed-source commercial products, as long as the original copyright and license notices are preserved.
MIT License
The MIT License is famously short. It permits use, copying, modification, merging, publication, distribution, sublicensing, and sale of the software, provided that the copyright notice and permission notice appear in all copies. The SPDX identifier MIT is commonly used to declare it in package metadata.
BSD Licenses
The BSD family (notably BSD-2-Clause and BSD-3-Clause) is similar in spirit to MIT. The 3-clause variant adds a non-endorsement provision, preventing the use of contributors’ names to promote derivative products without permission. Projects such as FreeBSD and many academic libraries use BSD-style terms.
Apache License 2.0
The Apache License 2.0, published by the Apache Software Foundation, is also permissive but more detailed than MIT or BSD. According to its official text, it includes an express grant of patent rights from contributors and a defensive termination clause that ends those patent rights if a licensee initiates patent litigation over the work. It also requires distributors to state significant modifications and preserve NOTICE files. Apache 2.0 is widely used by projects such as Kubernetes, Android core components, and many cloud-native tools.
Copyleft Licenses: GPL, LGPL, AGPL, and MPL
Copyleft licenses, championed by the GNU Project and the Free Software Foundation, also grant broad permissions but add a condition: if you distribute a derivative work, you must release it under the same (or a compatible) license, including the source code. The intent is to keep the software and its descendants free for downstream users.
GNU GPL (Strong Copyleft)
The GNU General Public License (GPL), in versions such as GPL-2.0 and GPL-3.0, is the canonical strong copyleft license. If you distribute a program that links to or incorporates GPL code, the combined work generally must be offered under the GPL, with source available to recipients. GPLv3 also includes explicit patent terms and provisions addressing tivoization and DRM.
GNU LGPL (Weak Copyleft)
The GNU Lesser General Public License (LGPL) softens the copyleft for libraries. Applications that merely link to an LGPL library can usually remain under a different license, while modifications to the library itself must still be shared under the LGPL. It is a common choice for reusable components that the authors want widely adopted.
GNU AGPL (Network Copyleft)
The GNU Affero General Public License (AGPL) closes the so-called “SaaS loophole.” If you run modified AGPL code as a network service, you must offer the corresponding source to your users, not just to those who receive a binary. This makes AGPL popular for projects that want to discourage closed-source forks running as competing cloud services.
Mozilla Public License (MPL)
The Mozilla Public License 2.0 is a file-level weak copyleft license. Modifications to MPL-licensed files must be shared under the MPL, but you can combine MPL files with proprietary files in a larger work. Firefox and several Mozilla projects use it.
Commercial, Proprietary, and EULA-Based Licensing
Most software that you pay for arrives with a proprietary license, usually presented as an End-User License Agreement (EULA), a master subscription agreement, or an enterprise contract. Pricing models and exact terms vary by vendor and change over time, so always check the current agreement directly rather than relying on memory or third-party summaries.
Common Proprietary Models
- Perpetual licenses: a one-time fee for the right to use a specific version indefinitely, sometimes with optional paid upgrades.
- Subscription or SaaS licenses: recurring fees that grant access while the subscription is active, often tied to a hosted service.
- Per-seat or per-user licensing: the number of paid seats limits how many named individuals or concurrent users may access the software.
- Trialware and freemium: limited-time or limited-feature use intended to encourage upgrades to a paid plan.
- OEM and bundled licenses: software licensed for distribution with specific hardware or another product, often with tighter restrictions on transfer.
Enterprise agreements may also include negotiated terms around audits, indemnification, data residency, and service levels. These provisions matter far more in practice than the surface license name.
Public Domain, Source-Available, and Dual Licensing
Several models are routinely confused with open source but are technically distinct.
Public Domain and CC0-Style Releases
Authors sometimes try to release code into the public domain, but public domain status is not recognized identically in every jurisdiction. Dedications like CC0 or the Unlicense attempt to waive copyright as broadly as possible while providing a fallback permissive license where waiver is not possible.
Source-Available Licenses
Source-available licenses publish the source code but impose restrictions that disqualify them from the Open Source Definition. Examples include licenses that forbid competing commercial hosting or that limit use to non-production environments. They can be attractive for vendors who want transparency and community contributions without enabling cloud rivals, but reusing such code in your own product can carry meaningful constraints.
Dual Licensing
Under dual licensing, the same code is offered under two different licenses, typically a strong copyleft license (such as the GPL or AGPL) for community use and a paid commercial license for organizations that cannot or do not want to comply with copyleft terms. Database engines and embedded toolkits frequently use this model.
Quick Comparison of Common License Families
The table below summarizes the high-level shape of each family. Always consult the actual license text and, where stakes are high, qualified legal counsel.
| Family | Examples | Modify & Redistribute? | Must Share Source? | Typical Use |
|---|---|---|---|---|
| Permissive | MIT, BSD, Apache 2.0 | Yes | No | Libraries embedded in any product |
| Weak Copyleft | LGPL, MPL 2.0 | Yes | Only for modified files/library | Reusable components with shared improvements |
| Strong Copyleft | GPL, AGPL | Yes | Yes, for entire combined work | Software intended to stay free downstream |
| Proprietary / EULA | Vendor-specific | Usually no | No (source not provided) | Commercial apps, SaaS, enterprise tools |
| Source-Available | BSL, SSPL-style | Limited | Sometimes | Transparent but commercially restricted code |
| Dual Licensed | Many DB engines, toolkits | Depends on chosen license | Depends on chosen license | Community + paid commercial split |
How to Read a License Before Using Software
Before adopting a new dependency or installing a vendor tool, walk through a short checklist. It takes minutes and prevents most accidental violations.
- Find the license file. Look for
LICENSE,LICENSE.txt,COPYING, or license headers in source files. For commercial software, locate the EULA or master agreement. - Identify it with an SPDX identifier. The SPDX License List provides standardized short IDs such as
MIT,Apache-2.0,GPL-3.0-only, orMPL-2.0. Matching the text to an SPDX ID is the fastest way to know what you have. - Check redistribution and modification rules. Can you ship the code inside your product? Can you change it? Must you offer source to your users?
- Note attribution and notice requirements. Many licenses require preserving copyright notices,
NOTICEfiles, or attribution in documentation. - Look for patent terms. Apache 2.0 and GPLv3, for example, include explicit patent provisions worth understanding.
- Identify copyleft triggers. Does linking, modifying, or running as a network service obligate you to share source?
- Check organizational policy. Many companies maintain an allowlist of acceptable licenses. Confirm before introducing a new one.
Common Mistakes to Avoid
Most licensing problems are not exotic legal puzzles; they are predictable mistakes that compound silently until release day.
- Assuming code on GitHub is free to use. Public visibility is not a license. If no license file is present, default copyright applies and you generally have no permission to reuse the code.
- Stripping notices. Removing copyright headers,
NOTICEfiles, or attribution lines is one of the most common ways to violate otherwise generous permissive licenses. - Mixing incompatible licenses. Combining strong copyleft code with proprietary components, or mixing two copyleft licenses with conflicting terms, can create distribution problems that are difficult to unwind later.
- Ignoring transitive dependencies. A permissive top-level library can pull in copyleft dependencies. Use SBOM and license-scanning tools to see the full picture.
- Treating SaaS as license-free. Network use can still trigger AGPL obligations and is almost always governed by a service agreement.
- Confusing source-available with open source. The former can restrict commercial use in ways open source licenses do not.
- Relying on summaries alone. Articles like this one, including this one, are starting points. For high-stakes decisions, read the license text and consult a lawyer.
Bringing It All Together
Software licenses are the connective tissue between authors and users, between communities and commerce. Permissive licenses such as MIT, BSD, and Apache 2.0 make it easy to embed code almost anywhere. Copyleft licenses such as the GPL, LGPL, AGPL, and MPL preserve user freedom downstream. Proprietary EULAs, source-available licenses, and dual-licensing models fill the spaces in between, offering different balances of openness, control, and revenue.
The practical takeaway is simple: treat licenses as a first-class part of every software decision. Identify them early, record them with SPDX IDs, respect their obligations, and review them whenever your distribution model changes. Do that consistently, and software licensing becomes a manageable engineering discipline rather than a last-minute legal scramble.
Official references
- U.S. Copyright Office – Circular 61: Copyright Registration of Computer Programs – Authoritative U.S. government reference for how computer programs are treated under copyright, which underpins software licensing.
- Open Source Initiative – Licenses – Official list of OSI-approved open source licenses and a strong anchor for explaining what qualifies as open source.
- SPDX License List – Standardized identifiers and canonical references for common software licenses such as MIT, BSD, Apache-2.0, GPL, LGPL, and MPL.
- GNU Project / Free Software Foundation – Licenses – Primary source for GNU GPL, LGPL, AGPL, and explanations of free software and copyleft licensing.
- Apache Software Foundation – Apache License 2.0 – Official license text for Apache License 2.0, a common permissive software license with patent-related terms.
