给仓库选许可证时，最容易陷入两种极端：完全不想管（默认空仓库），或把许可证讨论当成哲学辩论。对个人副业与小工具来说，我后来用三条问题就把范围缩到很小——不求最完美，求误伤面最小。
Disclaimer：这不是法律意见；若涉及公司资产、专利或合规审计，应走正式法务流程。
1. 谁会改、谁会再分发？
若只希望「随便用、随便改、闭源商用也行」，MIT 或 BSD-2-Clause 往往足够简单。Apache-2.0 在类似宽松度上，额外显式处理专利授权表述（对大企业友好，文本也更长）。
若希望衍生作品也必须开源（copyleft），才进入 GPL 家族的地盘。这条会显著影响采用意愿，尤其是商业集成场景。
2. 是否介意云服务「只用不发布」？
GPL 的边界讨论里，常出现「通过网络提供服务是否触发义务」这类问题。若对此敏感，有人会看 AGPL——但它对采用方更苛刻，可能直接吓跑集成者。
我的个人经验是：先想清楚项目要不要靠云托管商业模式活着。若要，许可证选择会牵动整条产品路线，不能事后补丁。
3. 署名、商标与「看起来官方」
宽松许可证仍要求保留版权声明。除此之外，若项目名容易被冒充，我会：
- 在 README 写清「非官方分支」提示；
- 必要时单独写 商标政策（许可证本身不一定覆盖商标）。
许可证解决的是版权与（部分）专利授权，不自动解决品牌被滥用。
4. 文档与示例代码
有时仓库里混有文档、图片与示例代码，默认与主代码同许可证可能不合适。可以：
- 在子目录放
LICENSE； - 或在 README 分段声明「文档用 CC-BY-4.0」等。
混乱的许可比严格许可更麻烦——接手的人会不知道边界在哪。
5. 我的默认起点
对个人玩具与工具库，我常用 MIT：文本短、理解成本低、生态兼容广。若涉及专利敏感或希望与大型企业流程对齐，再评估 Apache-2.0。
需要 copyleft 时，我会先问：是不是其实想要的是「商业授权双协议」——那又是另一条产品路径了。
6. 收束
选许可证，本质是在选希望别人如何对待自己的劳动。把问题拆成「分发链条 + 闭源容忍度 + 专利/商标」，决策会快很多。其余的不确定性，留给具体场景与专业法律意见，而不是评论区吵架。
7. 「没写许可证」到底意味着什么？
在不少司法实践里，没有显式授权并不等于「公共领域」。别人不能自动获得复制、修改、分发的权利；反过来说，若把代码公开在 GitHub，平台条款可能授予有限的展示许可，但那不等于全世界可以拿去闭源卖钱。
所以「懒得选」的最小成本动作，通常是：明确写上 MIT 或 Unlicense 或 CC0（视是否愿意放弃更多权利而定），并在 README 写一行「以仓库根目录 LICENSE 为准」。
8. MIT、BSD-2、Apache-2.0：宽松三兄弟怎么分
三者都给闭源商用留出了巨大空间，差别主要在文本长度与专利条款：
- MIT：最短。版权 + 免责声明。全球可读性高，兼容性好。
- BSD-2-Clause：与 MIT 极接近，措辞略不同，常见于学术与系统软件圈。
- Apache-2.0：显式包含专利授权（在遵守协议前提下，贡献者授予必要专利许可），并有NOTICE 文件要求。大企业供应链审计里更「好交差」，但文件与合规心智成本更高。
若项目可能进入「被大公司打包进发行版」的路径，我会偏向 Apache-2.0；若只是小库、脚本、个人工具，MIT 往往足够。
9. GPL 家族：copyleft 不是「更道德」，是「更粘」
GPL 的核心不是「必须免费」，而是：再分发衍生作品时，源码可得性要沿链传递（简化表述）。这会影响：
- 静态链接 vs 动态链接的边界讨论（尤其在 C/C++ 世界）；
- 插件、脚本、驱动是否与主程序构成「衍生作品」。
LGPL 试图在「库」这一层放松一些边界，让专有程序可以动态链接 LGPL 库——但具体工程形态是否合规，仍要看链接方式、修改是否回传等细节。
AGPL 进一步把「通过网络提供服务」纳入触发条件的一种思路（实务解读分歧存在），对 SaaS 只跑不改、也不分发二进制 的场景也可能构成压力。结果是：采用意愿骤降，除非项目目标就是强制下游开放服务侧改动。
我的实践态度是：先假设 AGPL 会吓跑 80% 的潜在集成者，再决定值不值得。
10. 依赖与「许可证兼容」： SPDX 是共同语
package.json、Cargo.toml、go.mod 拉下来的依赖树，许可证可能是混合的。个人项目至少可以做到：
- 根目录
LICENSE声明本仓库许可； - README 或
NOTICE列出直接依赖的 SPDX 标识（不必手抄全文，但要可追溯）。
兼容性的典型雷区：把 GPL 代码与不允许 copyleft 的专有链路硬缝在一起。宽松许可之间大多可并存，但「再分发时整包义务」仍可能由最严的那条决定。
11. 资源文件：代码用 MIT，美术用 CC
仓库里常有贴图、字体、音乐。MIT 只擅长覆盖代码文本；美术资源更常见做法是 CC-BY / CC-BY-SA / CC0 等（字体还要另看字体的授权书）。我会避免「整个仓库一个 MIT 打穿」，除非确定所有二进制资源的版权都干净且愿意同等授权。
12. 双协议与商业授权：产品问题先行
若真实需求是「开源引流 + 企业付钱买闭源豁免」，那是商业模式，不是单选许可证能偷偷解决的。常见形态是：
- AGPL + 商业许可（或 GPL + 商业许可）；
- 核心扩展闭源、内核开源（边界要极其清晰，否则信任崩盘）。
这类路线需要在最早把版权归属、商标、贡献者协议想清楚，而不是等 star 上万再补。
13. 贡献者协议（CLA）要不要？
当多人贡献、且可能涉及专利或将来要改许可证时，CLA / DCO 会成为议题。对个人小项目，DCO（Signed-off-by） 有时比厚重 CLA 更轻量；对公司主仓，法务常有固定模板。
这不是「开源精神」问题，是权属与诉讼成本问题。
14. 收束（第二段）
许可证讨论最容易滑向道德表演。我把它拉回工程：默认无授权、宽松三兄弟、copyleft 粘性、云分发边界、依赖 SPDX、资源另授权、商业双协议另开产品线。这几层想完，再打开 choosealicense 或找律师填最后一块拼图，会省掉大量回旋镖。