License Compliance Vocabulary

GPL's copyleft (or "viral") provision is the key commercial concern — incorporating GPL code into a distributed product triggers a requirement to release the entire product under GPL, eliminating proprietary protection.

The GPL "distribution trigger" is the critical nuance: (1) using GPL software as an internal tool (not distributed) does not trigger copyleft — many companies use GPL-licensed developer tools freely; (2) distributing a product that contains GPL code to customers or users triggers the obligation to provide source under GPL. The GPL v2 and v3 differ in how they handle network-access scenarios (GPL v3's AGPL variant also triggers on network use). LGPL (Lesser GPL) is a weaker copyleft that permits linking without triggering the full copyleft — this is why many commercial-friendly open source libraries use LGPL. Companies typically allow: MIT, BSD, Apache 2.0, ISC (permissive licenses) for products; GPL for internal tools; LGPL on a case-by-case review.

Key vocabulary:
• copyleft — a license condition that requires derivative works to be released under the same (or compatible) license
• GPL (GNU General Public License) — a strong copyleft license that requires source release when distributing software containing GPL code
• distribution trigger — the act of distributing software to users that activates copyleft obligations

FOSS audits are standard practice in M&A due diligence and enterprise sales processes — undisclosed license violations can block acquisitions or enterprise deals and create legal liability.

FOSS audit tools (Black Duck, FOSSA, Snyk, WhiteSource) scan package manifests, binary files, and source code for known open source components and map them to their licenses. The audit produces a "bill of materials" (SBOM) listing every open source component and license. Common violations found in audits: (1) GPL/AGPL components in distributed products without source release; (2) missing copyright attribution notices required by MIT/BSD licenses; (3) incompatible license combinations (e.g., GPL code combined with Apache 2.0 code in a single executable, which some GPL versions restrict); (4) components with no identifiable license (legally risky — all rights reserved by default). The remediation path for each violation depends on the specific license and use case.

Key vocabulary:
• FOSS audit — a systematic scan of a software product's open source components to verify license compliance
• SBOM (Software Bill of Materials) — a complete inventory of all software components in a product with their versions and licenses
• license violation — using open source software in a way that doesn't comply with the terms of its license

Dual licensing is a monetisation strategy: give the open source community free access under copyleft terms; charge commercial users who need proprietary use rights. MySQL, Qt, and MongoDB (formerly) used this model.

The model works because the copyleft license (GPL) is commercially unattractive for proprietary software developers — they must either open-source their work or pay for the commercial alternative. The copyright holder profits from the commercial licenses while maintaining an active open source community. The dual-license model requires "contributor license agreements" (CLAs) from all contributors — the copyright holder needs to own or have full rights to all contributions to legally offer them under both licenses. Without a CLA, contributors could block the commercial license by asserting their copyright. This is why many dual-licensed projects have strict CLA requirements that single-license permissive projects don't need.

Key vocabulary:
• dual-license model — offering the same software under both a copyleft (free for open source) and a commercial (paid for proprietary) license
• CLA (Contributor License Agreement) — a legal agreement giving the project copyright holder the rights to use contributions under the dual license
• open core — a related model where the core is open source but enterprise features are proprietary; distinct from pure dual licensing

REUSE solves the "which file is under which license?" problem — in large projects with multiple license types or mixed-origin code, REUSE makes per-file license information machine-readable and unambiguous.

The REUSE specification (reuse.software) defines three requirements: (1) Each file must have an SPDX short identifier comment (e.g., "SPDX-License-Identifier: MIT") and a copyright notice ("SPDX-FileCopyrightText: 2024 Jane Smith"); (2) The full license texts must live in a LICENSES/ directory named by SPDX identifier (e.g., LICENSES/MIT.txt); (3) The project can be checked with the reuse tool (a CLI linter). REUSE is increasingly required in high-compliance environments (government, automotive, medical devices) where auditors need to verify per-file license provenance. It is also the basis for generating accurate SBOMs because the license metadata is machine-readable from the source itself.

Key vocabulary:
• REUSE specification — a standard for embedding per-file copyright and license metadata in software projects using SPDX identifiers
• SPDX identifier — a short, standardised license code (e.g., MIT, Apache-2.0, GPL-3.0-only) used in REUSE and SBOM tooling
• license metadata — machine-readable information embedded in or alongside source files that identifies the applicable copyright and license

The permissive vs. copyleft distinction is the most fundamental license taxonomy in open source — it determines whether incorporating a dependency into a commercial product is straightforward or legally complex.

Spectrum of license restrictiveness: (1) Public domain / CC0 — no restrictions at all; (2) Permissive (MIT, BSD-2, BSD-3, ISC, Apache 2.0) — attribution required, but no limits on use or derivative works; (3) Weak copyleft (LGPL, MPL) — copyleft applies to the library itself but not to programs that merely link to it; (4) Strong copyleft (GPL v2, GPL v3) — copyleft applies to the full program that includes GPL code; (5) Network copyleft (AGPL) — copyleft also triggers when software is provided as a network service. For commercial software developers: permissive licenses are generally safe for product use (check Apache 2.0 patent terms); LGPL requires careful review; GPL/AGPL prohibit product use without commercial license or source release.

Key vocabulary:
• permissive license — a license that allows use in proprietary products with minimal conditions (attribution); MIT, BSD, Apache 2.0
• copyleft license — a license that allows use but requires derivative works to be released under compatible terms when distributed
• weak copyleft — copyleft that applies only to the licensed library itself (LGPL, MPL), not to the full program that uses it

The MIT license is known for its permissive nature. This means it grants broad usage rights – including commercial use and modification – without imposing conditions like requiring you to open-source your own derivative work. The key difference from copyleft licenses (like GPL) is the lack of these obligations.

Apache 2.0 requires you to include the original license and copyright notice alongside your code, typically in a README file. This demonstrates compliance and allows others to understand their rights regarding the licensed code. It's not about modifying the source or obtaining explicit permission for commercial use – those are aspects of other licenses.

'Source Available' is an older term often used to describe licenses that allow you to examine and understand the source code. However, it *doesn't* necessarily grant modification or redistribution rights; it usually comes with significant restrictions. It's crucial to always check the specific license terms.

The GPLv3 is a 'copyleft' license. This means that if you incorporate GPL-licensed code into your project, any derivative works *must* also be licensed under the GPLv3. Including the entire library source code demonstrates an attempt to comply with this requirement – it doesn't eliminate the potential for triggering the copyleft provisions, but shows awareness.

The core difference lies in the 'viral' effect. Copyleft licenses (like GPL) impose conditions that derivative works must also be open-sourced under the same license, ensuring continued openness. Permissive licenses (like BSD) grant much broader rights, allowing you to use, modify, and distribute the code commercially without these obligations.