Oss License

oss-license — 开源协议选择与合规框架

开源协议的本质是版权许可合同: 它规定别人拿到你的代码后能做什么、必须回报什么。选错或用错的代价不是"风格问题",而是法律义务——可能被迫开源闭源代码、丢掉专利防御、或踩中"无协议=保留全部权利"导致根本不可用。本 skill 把这套判断落地为可执行的选择 / 合规流程。

⚠️ 本 skill 提供工程决策框架, 不是法律意见。涉及收购、诉讼、重大商业授权时, 咨询执业律师。协议事实核对至 2026-06。

待分析的协议问题

$ARGUMENTS

核心戒律(一句话)

先问"代码要去哪、要换回什么"——分发方式(闭源分发 / SaaS / 内部 / 库)决定义务是否触发, 协议家族决定义务有多重。 脱离分发场景谈"哪个协议好"是空话。

第一动作: 分流

工作流 A: 为自己项目选 License(按序)

决策树(选自己项目的协议)

要不要允许别人闭源商用你的代码?
├─ 允许(最大化采用) → 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(选定前): 确认三件事——(1)该协议是否 OSI 认证(决定能否标"开源", source-available 不是开源); (2)是否与你的已有依赖协议冲突(见工作流 B 红线); (3)若图商业护城河, 是否已读 references/commercial.md 的双授权 / relicensing 反噬案例(社区 fork 风险, 如 Terraform→OpenTofu、Redis→Valkey)。

工作流 B: 依赖合规审查(按序)

合规红线(命中=必须处理)

兼容性方向的铁律: permissive → copyleft 单向流入。MIT/BSD/Apache 可被并入 GPL 项目; 反之 GPL 代码不能并入并仍标 permissive。完整兼容矩阵 + Apache/GPLv2 法律争议 + EUPL 附录兼容机制见 references/compatibility.md。

五大家族速查

每个家族的代表协议权责详解见 references/families.md; 全 60+ 协议带 SPDX/OSI/专利标注见 references/registry.md。

关键决策启发式

• 不确定就 Apache-2.0(库/框架)或 MIT(小项目): permissive + 专利防御, 采用阻力最小。
• 想要"用我可以、白嫖不行": 不是选更严的开源协议, 而是 AGPL-3.0(仍开源)或 双授权(AGPL + 商业)。
• 想延迟开源 / 留窗口期: BSL-1.1 / FSL——但接受"现在不算开源", 且预期可能被社区 fork。
• CC0 / CC-BY 用于代码 = 错: Creative Commons 官方明确不建议, 它不处理专利。代码用 MIT/Apache/0BSD。
• GPL-2.0-only vs GPL-2.0-or-later: 前者锁死 v2(与 Apache-2.0、GPLv3 不兼容), 后者可升 v3 化解冲突——默认选 or-later。
• 依赖合规先看分发方式再看协议: 纯内部使用几乎不触发 copyleft 义务; 一旦对外分发或 SaaS, 立刻重审。

失败模式(触发 → 一线修复 → 仍失败兜底)

与上方「合规红线」区别: 红线是法律义务触发, 本表是 skill 用起来卡壳时怎么办。

适用边界

• 本框架覆盖软件代码协议的工程决策; 不覆盖商标、专利申请、出口管制、数据合规(GDPR 等)。
• 协议事实(尤其 source-available 与 relicensing)变动快, registry 核对至 2026-06; 合规关键场景以 opensource.org / spdx.org/licenses 实时列表 + 协议原文为准。
• 跨法域的 copyleft 可执行性、"链接是否构成衍生作品"等存在法律灰区, 高风险场景须律师介入。

参考集(按需读)