为什么需要协议

一个容易被忽略的法律事实：代码创作完成即自动受著作权保护。如果没有明确的许可，他人无权使用、修改或分发。

"开源"不等于"没有版权"。开源许可证，恰恰是版权持有者主动授予他人某些权利的协议。

所以没有许可证的代码仓库，在法律上默认是"保留所有权利"的。

主要协议分类

宽松型（Permissive）

MIT：最简洁宽松。允许任何人使用、复制、修改、合并、发布、分发、再授权和销售，唯一要求是保留版权声明和许可声明。

Apache 2.0：比 MIT 多了两项重要内容：

  • 明确的专利授权：贡献者授予使用者与其贡献相关的专利许可；
  • 专利报复条款：如果你起诉该项目侵犯你的专利，你的专利授权自动终止。

BSD：与 MIT 类似，有二条款、三条款版本，三条款版本增加了"未经许可不得用作者名义背书"的限制。

弱著佐权型（Weak Copyleft）

LGPL：主要针对类库。允许专有软件动态链接LGPL 库，但修改 LGPL 代码本身则必须开源。

MPL（Mozilla Public License）：文件级别的 copyleft。修改后的 MPL 文件必须保持开源，但可以与其他专有代码组合在同一项目中。

强著佐权型（Strong Copyleft）

GPL：最具"传染性"。任何基于 GPL 代码的衍生作品，在分发时必须以同样的 GPL 协议开源。

AGPL：针对网络服务的补充。GPL 的触发条件是"分发"，而 AGPL 把"通过网络提供服务"也视为分发——即如果你修改了 AGPL 代码并提供网络服务，必须公开源代码。

Copyleft 的逻辑

GPL 的设计哲学是：既然你从开源社区获益，就应该回馈。

它不限制使用，但要求衍生作品保持同样的开放，防止有人把开源代码改一改就变成专有产品。

怎么选

选 MIT/Apache，如果你希望：代码被尽可能广泛地使用，包括被商业闭源产品采用；不在意他人是否回馈。

选 GPL/AGPL，如果你希望：确保衍生作品保持开源；防止他人拿你的工作去做专有产品。

选 LGPL/MPL，如果你希望：在库/组件层面保持开放，同时允许被更广泛地集成。

企业视角

企业在选择开源依赖时，会特别关注许可证的传染性。使用 GPL 依赖可能要求整个产品开源，这是很多商业产品要规避的。

因此，基础设施类的库通常倾向于选择宽松协议（MIT、Apache），以最大化采用率；而面向终端用户的完整产品更可能选择 GPL 类协议。

一个提醒

选择许可证时要考虑兼容性：并非所有协议都能互相组合。比如 GPL v2 与 Apache 2.0 在某些解释下存在兼容性争议。

说明：本文为开源法律协议的公开知识整理，不构成法律建议。