The essence of an open source license is acopyright license contract: it defines what others can do after they get your code and what they must give back. The cost of choosing or using it wrongly is not a "style issue" but alegal obligation—you may be forced to open source closed-source code, lose patent defenses, or fall into "no license = all rights reserved" making it fundamentally unusable. This skill turns this set of judgments into an executable selection / compliance process.
⚠️ This skill provides anengineering decision framework, not legal advice. For acquisitions, litigation, or major commercial licensing, consult a practicing lawyer. License facts verified as of 2026-06.
License question to be analyzed
$ARGUMENTS
Core commandment (in one sentence)
First ask "where is the code going, and what do you want back"—the distribution method (closed-source distribution / SaaS / internal / library) determines whether obligations are triggered, and the license family determines how heavy the obligations are. Discussing "which license is good" apart from the distribution scenario is empty talk.
First action: triage
| Your situation | Which path to take |
|---|---|
| I want to release / open source aproject of my own, which license to choose | Workflow A |
| In my project Iused third-party dependencies, worried about compliance / whether it can be used commercially in closed source | Workflow B |
| I want to use a license to create acommercial moat(prevent cloud vendors from freeloading / delayed open sourcing) | A + references/commercial.md |
| I just want to look up the rights and obligations / SPDX identifier of a specific license | references/registry.md(full table of 60+) |
Workflow A: Choose a License for Your Own Project (in order)
| Step | Action | Key question | Completion criterion |
|---|---|---|---|
| 1 | Set the goal | Maximize adoption / require derivative contributions back / prevent commercial freeloading—choose one of the three, which determines the general direction | One of the three has been chosen, and the reason can be stated clearly in one sentence |
| 2 | Walk the decision tree(see below) | Converge layer by layer to a specific license based on "whether closed-source commercial use is allowed" | The decision tree has reached a leaf node, landing on a single specific SPDX id (or an explicit dual-licensing combination) |
| 3 | Check dependency constraints | If any library you bring in has copyleft, your license cannot be more permissive than it(see Workflow B red lines) | All mandatory dependencies' licenses have been listed, and each has been checked to confirm none is stricter than your chosen license |
| 4 | Land the identifier | Add a LICENSE file + write SPDX-License-Identifier: <id>in source file headers; fill the package management license field with the SPDX |
LICENSE The file has been created, and both the source headers and the package management field have been filled with the corresponding SPDX id |
| 5 | Self-check for multi-file projects | The original license notices of third-party code must be retained (especially Apache NOTICE / BSD attribution); do not apply a single license across the board in a monorepo; use the REUSE specification per file SPDX-License-Identifier Header Clear Source Protocol |
The SPDX headers of each source file have been fully verified; in monorepo scenarios reuse lint passed (if applicable) |
Decision Tree (Choose the License for Your Own Project)
要不要允许别人闭源商用你的代码?
├─ 允许(最大化采用) → permissive
│ ├─ 企业级 / 要专利防御 ........ Apache-2.0 (有专利授权+报复终止)
│ ├─ 极简 / 小库 / 生态惯例 ...... MIT 或 ISC
│ ├─ 连署名都不强制 ............. 0BSD / Unlicense (准公有)
│ └─ 同时想兼容 GPLv2 代码 ....... Apache-2.0 OR MIT 双授权(Rust 范式)
│
├─ 要求衍生开源(copyleft) →
│ ├─ 只保护"库本身", 允许被闭源程序链接调用 .. LGPL(库级) 或 MPL-2.0(文件级)
│ ├─ 整个衍生项目都要开源 ................... GPL-3.0(反Tivo+专利) 或 GPL-2.0-or-later
│ └─ 想堵"SaaS 不分发即白嫖"漏洞 ............ AGPL-3.0(网络交互=分发)
│
└─ 不接受被白嫖, 也接受"非开源"标签 → source-available(非 OSI)
├─ 愿意 N 年后自动转开源 ........ BSL-1.1(默认4年) / FSL(2年, 转 MIT/Apache)
├─ 只想禁"托管转售竞品" ......... Elastic-2.0 / SSPL / Confluent
└─ 模块化限制(非商业/小企业) .... PolyForm 系列
🔴 CHECKPOINT (Before Deciding): Confirm three things—(1) whether the license is OSI-approved (this determines whether you can label it "open source"; source-available is notopen source); (2) whether it conflicts with yourexisting dependencieslicenses (see Workflow B red lines); (3) if you are aiming for a commercial moat, whether you have read
references/commercial.mdthe dual-licensing / relicensing backlash cases (community fork risk, such as Terraform→OpenTofu, Redis→Valkey).
Workflow B: Dependency Compliance Review (In Order)
| Step | Action | Tool / Method | Completion Criteria |
|---|---|---|---|
| 1 | List all dependencies | Generate an SBOM (SPDX / CycloneDX); scanning tools ScanCode (open source) / FOSSA (commercial) | SBOM has been generated and covers direct dependencies and transitive dependencies |
| 2 | Classify each dependency by family | Compare against references/registry.md to label permissive / copyleft / network / source-available |
Every item in the dependency list has been labeled by family, with no unclassified omissions |
| 3 | Determine your distribution method | Closed-source binary distribution? SaaS? Purely internal? Static vs dynamic linking?—this determines which obligations are triggered | The distribution method has been clarified to a single category (rather than "uncertain"); when LGPL is involved, the static/dynamic linking method has been confirmed |
| 4 | Go through the red lines one by one(see below) | If hit, it must be handled: replace the dependency / change the distribution method / fulfill open source obligations / buy a commercial license | Each dependency has been checked one by one against the red line table, and every hit has been given a handling plan (replace/isolate/open source/license) |
| 5 | Continuous monitoring | Relicensing can make the old version compliant and the new version non-compliant—lock versions + rescan periodically (see recent cases) | Dependency versions have been locked, and the review cycle (e.g., quarterly) has been scheduled |
Compliance Red Lines (Hit = Must Handle)
| Red Line | Consequence | Handling |
|---|---|---|
| GPL/AGPL code entersclosed-source distributionproduct | The entire product is required to be open-sourced under GPL | Switch to a permissive alternative / isolate the process / or accept open source |
| AGPL dependency runs as SaaS without providing source code | Violates Section 13 network clause | Provide source code / switch dependencies / buy a commercial license |
| Static linking an LGPL library and not allowing users to replace it | Triggers stronger obligations | Change todynamic linking, or provide .o files so users can relink |
| Apache-2.0 and GPLv2 code mixed and distributed | License incompatibility | Find a GPLv3-or-later version / use an MIT replacement |
| CDDL code incorporated into GPL project (e.g., ZFS into the kernel) | Incompatible | Distribute as a separate module, do not statically merge |
| source-available(BSL/SSPL/Elastic) dependency is used forcompeting product/resale | Violates non-compete clause | Read the specific terms; most prohibit "providing as a hosted service" |
| DependencyNo LICENSE at all | All rights reserved by default = cannot be legally used | Contact the author to add a license / don't use |
Iron rule of compatibility direction: permissive → copyleft one-way flow. MIT/BSD/Apache can be incorporated into GPL projects; conversely, GPL codecannotbe incorporated and still labeled permissive. Full compatibility matrix + Apache/GPLv2 legal controversy + EUPL appendix compatibility mechanism see
references/compatibility.md。
Five Major Families Quick Reference
| Family | In one sentence | Representatives (SPDX) | Closed-source commercial use? |
|---|---|---|---|
| Permissive | Almost only requires retaining notices | MIT BSD-3-Clause Apache-2.0 ISC 0BSD |
✅ Yes |
| Weak copyleft | Modified parts must be open-sourced, the rest is free | LGPL-3.0(library-level) MPL-2.0(file-level) EPL-2.0 |
✅ Callers can remain closed-source |
| Strong copyleft | The entire derivative work must be open-sourced under the same license | GPL-2.0 GPL-3.0 |
❌ Distribution triggers infection |
| Network copyleft | Even SaaS counts as distribution | AGPL-3.0 |
❌ Providing the service triggers it |
| Source-available, non-OSI | You can see the source code butit is not open source, with non-compete restrictions | BUSL-1.1 SSPL-1.0 Elastic-2.0 FSL |
⚠️ Depends on specific terms |
For detailed rights and obligations of each family's representative licenses see references/families.md; for all 60+ licenses with SPDX/OSI/patent annotations see references/registry.md。
Key Decision Heuristics
- When unsure, go with Apache-2.0(libraries/frameworks) or MIT(small projects): permissive + patent defense, lowest adoption friction.
- Want "you can use me, but no free-riding": don't pick a stricter open-source license, instead AGPL-3.0(still open source) or dual licensing(AGPL + commercial).
- Want to delay open-sourcing / keep a window period: BSL-1.1 / FSL—butaccept that "it doesn't count as open source now", and expect it may be forked by the community.
- Using CC0 / CC-BY for code = wrong: Creative Commons officially advises against it, as it doesn't address patents. For code use MIT/Apache/0BSD.
GPL-2.0-onlyvsGPL-2.0-or-later: the former locks in v2 (incompatible with Apache-2.0 and GPLv3), the latter can upgrade to v3 to resolve conflicts—choose or-later by default。- For dependency compliance, look at the distribution method first, then the license: purely internal use almost never triggers copyleft obligations; once distributed externally or offered as SaaS, re-review immediately.
Failure Modes (trigger → first-line fix → fallback if still failing)
Difference from the "Compliance Red Lines" above: red lines arelegal obligation triggers, while this table is what to do when the skill gets stuck in use。
| Trigger | First-line fix | Fallback if still failing |
|---|---|---|
| Dependency list incomplete (no SBOM / transitive dependencies missed) | Use ScanCode/FOSSA to scan the full tree + reverse-engineer from lock files | Still incomplete → mark "inventory incomplete, compliance conclusion covers only known dependencies", do not give a "all green" guarantee |
| A dependency's license is not in the registry / cannot be found | Check the official SPDX list + the project's LICENSE text to classify the family | No LICENSE text at all → per the red line "no license = all rights reserved", contact the author to add a license or do not use |
| The user cannot clearly state the distribution method (closed-source distribution/SaaS/internal) | 🔴 STOP Use AskUserQuestion to confirm item by item — whether obligations are triggered depends entirely on this | The user still has not decided → perthe strictest scenario(external distribution) give a conclusion, mark "can be relaxed if only for internal use" |
| source-available terms (BSL/SSPL/Elastic) cannot be understood | Read references/commercial.md corresponding clause breakdown + original text |
Competition/resale boundaries are still unclear → mark "non-compete clauses have gray areas", refer high-risk scenarios to a lawyer |
| High risk (acquisition/litigation/major licensing) exceeds engineering judgment | 🔴 Clearly state "this skill is an engineering framework, not legal advice", give a preliminary assessment + list of risk points | The user wants a definitive conclusion → refuse to endorse it on behalf of the law, recommend a practicing lawyer, leave only decision inputs |
Scope of application
- This framework coverssoftware code licensesengineering decisions; it does not cover trademarks, patent applications, export controls, or data compliance (GDPR, etc.).
- License facts (especially source-available and relicensing)change quickly, registry verified as of 2026-06; for compliance-critical scenarios, rely on the opensource.org / spdx.org/licenses real-time list + the original license text.
- The enforceability of copyleft across jurisdictions, "whether linking constitutes a derivative work", etc. involve legal gray areas; high-risk scenarios require lawyer involvement.
Reference set (read as needed)
| File | Purpose |
|---|---|
references/families.md |
Detailed clause-by-clause rights and obligations of the five major families + representative licenses (MIT/Apache/GPL/LGPL/AGPL/MPL/EPL/CDDL, etc.), patent clause comparison, static vs dynamic linking |
references/registry.md |
SPDX quick-reference library for all licenses (60+, grouped by family, marked with OSI certification / patents / key restrictions) |
references/compatibility.md |
Compatibility matrix (who can merge into whom) + dependency compliance review process + Apache/GPLv2 controversy + CDDL/GPL + EUPL appendix compatibility + toolchain |
references/commercial.md |
Business strategy: dual licensing / AGPL to prevent SaaS free-riding / source-available (BSL/SSPL/Elastic/FSL) / history of relicensing cases in recent years and fork backlash |