Glossary of software-licensing terms
This is a plain-language reference for the key terms used across the Software Licensing & Agreements path. Definitions are short on purpose; each links to the lesson that explains the idea in full. Terms are grouped by theme and roughly ordered from foundational to advanced within each group, following the shape of the path itself. This is educational material, not legal advice.
Foundations & IP
License — Permission from a rights holder to do things with software that copyright would otherwise forbid, such as copying, modifying, or distributing it. See What is a software license?
Copyright — The automatic legal right an author has over an original work, including source code, controlling who may copy, modify, or distribute it. See Copyright & software ownership
Copyright registration — The optional step of recording a copyright with a government office, which in the US is required before you can sue for infringement and unlocks stronger remedies. See Copyright & software ownership
Work made for hire — A work whose copyright belongs to the employer or commissioning party rather than the person who created it, common for code written by employees. See Copyright & software ownership
Patent — A time-limited monopoly on an invention, which in software can cover a method or process and is a separate right from copyright. See Patents, trademarks & trade secrets
Trademark — A name, logo, or mark that identifies the source of a product, protecting branding rather than the code itself. See Patents, trademarks & trade secrets
Trade secret — Valuable information kept confidential, such as proprietary source code or algorithms, protected only as long as it stays secret. See Patents, trademarks & trade secrets
License grant — The clause in a license that spells out exactly what rights you are given and under what conditions. See License vs contract
Contract — A legally binding agreement formed by mutual assent and consideration, which a license may or may not also be depending on how it is presented. See License vs contract
Click-wrap — An agreement you accept by clicking a button such as “I agree”, generally enforceable because you took a clear action to consent. See License vs contract
Browse-wrap — An agreement that claims to bind you simply by using a site or product, which courts enforce less reliably because consent is not explicit. See License vs contract
The licensing spectrum — The full range of license types, from public domain through permissive and copyleft open source to source-available and fully proprietary. See The licensing spectrum
Jurisdiction — The legal system whose rules apply to a license or dispute; copyright and contract law differ from one country to the next. See Licensing across jurisdictions
Open source
Open source — Software released under a license that grants users the freedoms to use, study, modify, and redistribute it, as defined by the Open Source Initiative. See What open source really means
OSI (Open Source Initiative) — The organization that maintains the Open Source Definition and reviews whether licenses qualify as open source. See What open source really means
Free software — Software that respects users’ freedom to run, study, change, and share it, a movement and definition maintained by the Free Software Foundation. See What open source really means
Four freedoms — The Free Software Foundation’s criteria for free software: the freedom to run, study, redistribute, and improve a program. See What open source really means
FOSS — A catch-all abbreviation for “free and open-source software”, covering both the free-software and open-source framings. See What open source really means
Source-available — Software whose source code you can read but whose license withholds one or more open-source freedoms, so it is not open source. See What open source really means
The open-source licenses
Permissive license — An open-source license that lets you do nearly anything with the code, including using it in closed products, as long as you keep the notices. See Permissive vs copyleft
Copyleft — A licensing approach that requires derivative works to be released under the same license, keeping the code and its descendants open. See Permissive vs copyleft
Reciprocity — The copyleft principle that anyone who benefits from the code must share their changes back under the same terms. See Permissive vs copyleft
Strong copyleft — Copyleft that extends to a whole combined work, so linking the licensed code into a program can pull the whole program under the license. See Permissive vs copyleft
Weak copyleft — Copyleft scoped to the licensed files or library, so you can combine it with proprietary code while only the original component stays open. See Weak copyleft: LGPL, MPL, EPL
MIT license — A short, very permissive license that requires only that the copyright notice and license text be preserved. See MIT & BSD: minimal permissive
BSD license — A family of minimal permissive licenses (2-clause and 3-clause) similar to MIT, with the 3-clause version adding a no-endorsement term. See MIT & BSD: minimal permissive
Apache License 2.0 — A permissive license that, unlike MIT or BSD, includes an explicit patent grant and rules for handling NOTICE files. See Apache 2.0: permissive with a patent grant
Patent grant — A clause in which contributors license any patents that cover their contribution, protecting users from patent claims by those contributors. See Apache 2.0: permissive with a patent grant
NOTICE file — A file used by Apache-2.0 projects to carry required attributions that downstream users must preserve and pass along. See Apache 2.0: permissive with a patent grant
GPL (GNU General Public License) — The best-known strong-copyleft license, requiring that anyone who distributes the software also make its source available under the GPL. See The GPL: strong copyleft
GPLv2 — The 1991 version of the GPL, still widely used (notably by the Linux kernel) and not always compatible with GPLv3. See The GPL: strong copyleft
GPLv3 — The 2007 revision of the GPL, adding explicit patent terms, anti-tivoization rules, and clearer compatibility provisions. See The GPL: strong copyleft
AGPL (GNU Affero General Public License) — A GPL variant that closes the “network loophole”, requiring source disclosure even when the software is offered to users over a network rather than distributed. See The AGPL: copyleft over the network
LGPL (GNU Lesser General Public License) — A weak-copyleft license that lets you link a covered library into proprietary software while keeping the library itself open. See Weak copyleft: LGPL, MPL, EPL
MPL (Mozilla Public License) — A weak-copyleft license that applies copyleft at the level of individual files, so changed files stay open but new files can be proprietary. See Weak copyleft: LGPL, MPL, EPL
EPL (Eclipse Public License) — A weak-copyleft license common in the Java ecosystem, with file-level reciprocity and its own patent terms. See Weak copyleft: LGPL, MPL, EPL
CDDL (Common Development and Distribution License) — A file-level weak-copyleft license derived from the MPL, known for its incompatibility with the GPL. See Weak copyleft: LGPL, MPL, EPL
Public domain — Works with no copyright, which anyone may use for any purpose; software rarely falls into it automatically and usually needs a deliberate dedication. See Public domain, Unlicense & CC0
CC0 — A Creative Commons tool that waives copyright as far as the law allows, used to place a work as close to the public domain as possible. See Public domain, Unlicense & CC0
Unlicense — A short public-domain dedication aimed at software, combining a waiver with a fallback permissive license. See Public domain, Unlicense & CC0
0BSD — A zero-clause BSD license that grants permissive rights without even requiring attribution, behaving much like a public-domain dedication. See Public domain, Unlicense & CC0
Choosing & combining
License compatibility — Whether two licenses can legally coexist in the same combined work; some open-source licenses cannot be merged at all. See License compatibility
Derivative work — A new work based on or substantially incorporating an existing one, which can inherit the original’s license obligations. See License compatibility
Distribution (conveying) — Giving software to others, the act that typically triggers a license’s obligations such as providing source or notices. See License compatibility
CLA (Contributor License Agreement) — An agreement contributors sign to grant a project the rights it needs to use and relicense their contributions. See Contributor agreements: CLAs & DCO
DCO (Developer Certificate of Origin) — A lightweight alternative to a CLA where contributors certify, via a sign-off line, that they have the right to submit their code. See Contributor agreements: CLAs & DCO
Inbound=outbound — The convention that contributions come in under the same license the project ships under, avoiding the need for a separate CLA. See Contributor agreements: CLAs & DCO
Dual licensing — Offering the same code under two licenses at once, typically an open-source license plus a paid commercial one. See Dual licensing & relicensing
Relicensing — Releasing existing code under a different license, which generally requires holding or gathering rights from all contributors. See Dual licensing & relicensing
Open-source risk — The supply-chain and legal exposure that comes from depending on third-party open source, from abandonment to license violations. See The risks of depending on open source
Proprietary & commercial
Proprietary / closed source — Software whose owner keeps the source code private and licenses only limited rights to use it. See Proprietary & closed-source licensing
Perpetual license — A license to use software indefinitely after a one-time purchase, usually with optional paid upgrades or support. See Commercial license models
Subscription license — A license that grants use for as long as you keep paying a recurring fee, after which the rights lapse. See Commercial license models
Per-seat license — Pricing tied to the number of named users or devices that may use the software. See Commercial license models
Usage-based license — Pricing tied to how much you use the software, such as per API call, per transaction, or per unit of compute. See Commercial license models
OEM license — A license to embed or resell another company’s software as part of your own product. See Commercial license models
Open core — A business model where a permissively or copyleft-licensed core is paired with proprietary paid add-ons. See Source-available & “fair source”
BSL (Business Source License) — A source-available license that restricts production use for a period before converting to an open-source license. See Source-available & “fair source”
SSPL (Server Side Public License) — A source-available license, derived from the AGPL, that imposes broad source-disclosure duties on those who offer the software as a service. See Source-available & “fair source”
Fair source — A category of licenses that publish source and allow most uses while reserving commercial rights, sitting between open source and proprietary. See Source-available & “fair source”
Using open source in products
Permissive compliance — Meeting the lightweight duties of permissive licenses, chiefly preserving copyright notices and license text in what you ship. See Meeting permissive obligations
Attribution — Crediting the authors of a component as a license requires, often by including its license text and copyright notice. See Meeting permissive obligations
Viral licensing — The informal name for strong copyleft’s tendency to extend its terms to a whole combined work, the central worry when using copyleft in products. See Copyleft in products: the viral question
SBOM (Software Bill of Materials) — A formal inventory of all the components and dependencies in a piece of software, used for license and security tracking. See Auditing dependencies & SBOMs
SPDX — A standard format and identifier list for describing licenses and software components, widely used in SBOMs. See Auditing dependencies & SBOMs
CycloneDX — An SBOM standard focused on security use cases, an alternative to SPDX for listing components and their licenses. See Auditing dependencies & SBOMs
License scanning — Using tools to detect the licenses of your dependencies automatically and flag obligations or conflicts. See Auditing dependencies & SBOMs
Reading & other agreements
EULA (End User License Agreement) — The agreement that governs an end user’s right to use a piece of software, typically presented at install or first run. See EULAs & terms of service
Terms of service (ToS) — The rules you agree to in order to use an online service, covering acceptable use, accounts, liability, and more. See EULAs & terms of service
Acceptable use policy — The part of an agreement that lists what you may not do with a product or service, such as abuse, illegal use, or reverse engineering. See EULAs & terms of service
Warranty disclaimer — A clause stating the software is provided “as is” with no guarantees, shifting the risk of defects to the user. See The risk clauses: who pays when it breaks
Limitation of liability — A clause that caps or excludes how much one party can be made to pay if something goes wrong. See The risk clauses: who pays when it breaks
Indemnification — A promise by one party to cover certain losses or legal claims the other party suffers, common around IP infringement. See The risk clauses: who pays when it breaks
Governing law — The clause that names which jurisdiction’s law applies and where disputes will be heard. See The main clauses, decoded
Termination — The clause setting out when and how an agreement ends and what happens to your rights afterward. See The main clauses, decoded
Privacy policy — A document that explains what personal data a service collects, how it is used, and the rights users have over it. See Privacy policies & data agreements
GDPR — The European Union’s General Data Protection Regulation, a strict data-protection law with wide reach over how personal data is handled. See Privacy policies & data agreements
CCPA — California’s Consumer Privacy Act, a US state law granting consumers rights over their personal data. See Privacy policies & data agreements
DPA (Data Processing Agreement) — A contract that governs how one company processes personal data on behalf of another, often required under GDPR. See Privacy policies & data agreements
Controller — Under data-protection law, the party that decides why and how personal data is processed. See Privacy policies & data agreements
Processor — Under data-protection law, the party that processes personal data on a controller’s behalf and under its instructions. See Privacy policies & data agreements
Sub-processor — A third party a processor brings in to help handle personal data, who must be disclosed and bound by similar terms. See Privacy policies & data agreements
SLA (Service Level Agreement) — A commitment about service quality, typically uptime, with remedies if the provider falls short. See SLAs & support agreements
Service credit — Compensation, usually a billing discount, owed to a customer when a provider misses its SLA targets. See SLAs & support agreements
NDA (Non-Disclosure Agreement) — A contract in which parties agree to keep shared confidential information secret. See NDAs & the rest of the landscape
MSA (Master Services Agreement) — An umbrella contract setting the standing terms between two parties, under which specific work is then ordered. See NDAs & the rest of the landscape
SOW (Statement of Work) — A document under an MSA that defines a specific project’s scope, deliverables, timeline, and price. See NDAs & the rest of the landscape
Choosing & process
Decision framework — A structured way to decide how to license your software, weighing your goals, dependencies, and business model. See A framework for choosing
License chooser — A step-by-step method or tool for narrowing down to the right license for your project. See Choosing your license, step by step
Agreement inventory — The set of agreements a given piece of software actually needs, from a license to a privacy policy to an SLA, depending on how it is delivered. See Which agreements does your software need?