Open Source License Vocabulary

Permissive licenses (MIT, Apache 2.0, BSD) allow commercial use and closed-source distribution with minimal requirements.

License categories:
• Permissive (MIT, Apache 2.0, BSD) — use freely in commercial closed-source products; just keep the copyright notice
• Copyleft / Strong copyleft (GPL) — if you distribute software using GPL code, your entire work must also be GPL
• Weak copyleft (LGPL) — can link to LGPL libraries in a proprietary product, but modifications to the LGPL library itself must be open
• Network copyleft (AGPL) — GPL-level requirement triggered even by running the software as a service (targeting SaaS providers)

Key difference between MIT and Apache 2.0:
• MIT — extremely short; just preserve the copyright notice
• Apache 2.0 — also provides patent grant: the licensor explicitly grants you rights to any patents embodied in the contribution
For commercial products, Apache 2.0 is often preferred because of this patent protection.

Key vocabulary:
• Permissive license — a license with minimal restrictions, compatible with proprietary software
• Copyleft — a licensing requirement that derivative works must use the same license
• Proprietary software — software whose source code is not available to the public
• Patent grant — an explicit license to use any patents held by the contributor
• Distribution — providing a copy of software to others (triggers many license requirements)

GPL compliance requires choosing one of three paths: comply (publish), remove, or replace the GPL-licensed component.

Why you cannot simply pay to avoid GPL (Option A):
• GPL is a license grant from the copyright holder, not a subscription
• You can only pay for a commercial license if the author explicitly offers one (dual licensing)
• Not all GPL authors offer commercial licenses

The three compliance paths:
1. Comply — publish the complete source code of the GPL-linked components under GPL (the copyleft obligation)
2. Remove — eliminate the GPL dependency from your product entirely
3. Replace — substitute a permissively-licensed library with equivalent functionality
4. Negotiate commercial license — if the author dual-licenses (e.g., MySQL/MariaDB model), pay for proprietary use rights

GPL enforcement is real — the Software Freedom Conservancy and others actively enforce GPL compliance against commercial products.

Key vocabulary:
• GPL compliance — fulfilling the obligations imposed by the GNU General Public License on software distributors
• Copyleft propagation — the mechanism by which GPL requirements spread from used code to the entire distribution
• GPL violation — distributing GPL-licensed code in a way that doesn't meet the license's requirements
• Dual licensing — offering software under both an open source and a separate commercial license
• Source code disclosure — making the source code available to recipients of the distributed binary

The AGPL "network use is distribution" clause was specifically created to prevent the "SaaS loophole" in GPL.

The GPL SaaS loophole:
• GPL only triggers on "distribution" — giving someone a copy of the software
• If you run GPL-licensed server software and let users access it via HTTP, you haven't "distributed" a copy
• Companies like Google ran GPL-licensed software internally without releasing source (technically compliant)

AGPL closes this loophole:
• AGPL adds: "if users can interact with the software over a network, you must make the source available"
• Triggering condition: any network interaction, not just distribution of a binary
• This is why MongoDB, Elastic, and others originally used AGPL — to prevent cloud providers from offering their software as a service without contributing back

Practical implication: If you use AGPL code in a SaaS product, you must release your entire application's source code under AGPL.

Key vocabulary:
• AGPL (Affero General Public License) — a GPL variant that extends copyleft to network service usage
• SaaS loophole — the ability to use GPL software in a cloud service without triggering the copyleft requirement
• Network use clause — the AGPL provision requiring source disclosure for network-accessible software
• Distribution trigger — the event (distributing a copy) that activates GPL's copyleft obligations
• Cloud provision — running software as a hosted service accessible to users over the internet

BSD 3-Clause is permissive — three conditions: preserve copyright notice, preserve license text, and don't use names for promotion without permission.

BSD 3-Clause requirements (all three must be met):
1. Copyright notice — retain the original copyright notice in source code redistribution
2. License text — reproduce the license text in binary distribution (README, docs, about page)
3. Non-endorsement clause — don't use the project's name or contributors' names to endorse your product without explicit permission

What BSD does NOT require:
• No copyleft — you can keep your source code private
• No patent grant (unlike Apache 2.0)
• No "share-alike" requirement
• No contribution back requirement

BSD 2-Clause (Simplified BSD / FreeBSD) drops only the non-endorsement clause — the distinction matters rarely in practice.

Key vocabulary:
• BSD 3-Clause License — a permissive open source license with copyright retention and non-endorsement clauses
• Non-endorsement clause — a license provision prohibiting use of the original author's name to promote derivative works
• Attribution requirement — the requirement to include copyright notices and license text in distributions
• Binary distribution — distributing compiled software without source code
• Permissive license conditions — minimal requirements (attribution) as opposed to copyleft requirements

Relicensing requires copyright ownership over all contributions — the copyright holder decides the license, not the OSI or the community.

When relicensing is straightforward:
• Single author (startup with no external contributors) — the copyright holder can relicense at will
• All contributors signed a CLA assigning copyright to the maintainer — the maintainer can relicense

When relicensing is complex:
• External contributors retain copyright in their patches
• You need consent from every contributor whose code is currently in the project
• This is practically impossible for popular projects with hundreds of contributors (e.g., Linux kernel is stuck with GPL because Linus Torvalds doesn't own all the contributions)

Why people sign CLAs:
• They explicitly grant the project maintainer the right to relicense their contribution
• This is why projects like Apache Foundation require CLAs — future license changes remain possible

The "permanently GPL" misconception:
• GPL is not a one-way ratchet imposed by the license itself
• It's a practical constraint based on copyright ownership, not a legal absolute

Key vocabulary:
• Relicensing — changing the license under which software is distributed
• Copyright holder — the person or entity with the exclusive right to determine how a work is licensed
• Contributor License Agreement (CLA) — an agreement where contributors grant the project the right to use and relicense their contributions
• Copyright assignment — a CLA type where contributors transfer copyright ownership to the project maintainer
• Inbound license — the license terms under which a contributor submits their code to a project