在开发者决定开始一个开源项目时，第一件事应该是选择开源许可证。目前经开源促进协会 OSI（Open Source Initiative）认证的许可证已有近百个。通过选择许可证，开发者可以较为自由地决定自己的开源项目可以在什么条件下开放哪些许可。
开源许可证内容
为了帮助开发者厘清不同许可证的区别，进而做选择。很多开发者和组织机构对许可证做过区分或说明。下面介绍三个分类说明体系，渐进式理解许可证结构和要素。
本节可帮助理解和区分许可证，不构成选择建议。
6个常用许可证的简单区分
流传最广的一张划分图，用5个关键问题区分6个常用许可证。包括发布开源项目之后，是否允许他人修改源码之后再闭源；新增代码是否需要采用同样的许可证；是否可以使用原作者名字做广告促销等。对这些问题，开放许可较多的许可证被称为是宽松许可证，如 MIT 和 Apache 许可证，而限制条件较多的则被称为限制型许可证，如 LGPL 许可证。
![]()
许可证主要内容分类
实际上关于开放许可的内容和条件，还有更多更复杂的规则。choicealicense.com 项目网站对照了约40个常见许可证，并对许可证的内容做了归类。
许可证的内容被分为三部分，根据这些划分，开发者可以对比选择更适合项目的许可证。
一是许可授予。开源许可证在承认著作权的基础上，授予公众一些许可，使公众可在某些方面自由使用许可项目。该网站罗列的所有许可证，都授予私人使用和商业用途、以及修改、二次分发的许可。按照 choicealicense 的划分，许可内容分为5项：
- 商业用途，授予使用在商业用途上使用项目的源代码和衍生品的权利。
- 分发，授予再分发权利。
- 修改，授予修改原作品的权利。
- 专利使用，有明确的专利授予许可。
- 私人使用，授予私人使用和修改的权利。
二是许可授予条件。大多数开源许可证的许可授予必须遵守一些条件，常见的一些条件包括：
- 公开来源。分发被许可的材料时，必须提供源代码。
- 许可与版权声明。许可和版权声明的副本必须包含在受许可证保护的材料中。但有些许可证中这一项只针对源代码文件，二进制文件中不是必须的。
- 网络使用即分发。通过网络与许可材料进行交互的用户被授予接收源代码副本的权利。
- 采用相同许可证。分发该许可证保护的材料时，必须沿用相同许可证发布修改，在某些情况下，可以使用类似或者相关的许可证，或者该条件可能不适用于将许可材料用作图书作品。有些许可证下的这一条件是针对现有文件的，如 Mozilla 公共许可证2.0，在允许分发该许可证保护的材料时，必须沿用该许可证发布对现有文件的修改。
- 状态变更。必须记录对许可证保护材料所做的更改。
三是声明免除保证和责任限制：
- 责任。该许可证采用有限责任制。
- 商标使用。该许可证有明确声，表示不授予商标权。即便没有类似生命，许可证本身可能也隐含不授予商标权的含义。
- 保证。该许可证声明不提供任何保证。
![]()
（来源：choicealicense.com 网站截图）
上图中，绿色的点代表许可证的第一项内容：许可授予；蓝色的点代表许可授予条件；红色的点代表免除保证和责任限制。横轴规定了每一栏表示的具体内容，纵轴表示不同许可证。
如第一个 BSD 许可证，绿色的点有四个，对应横轴内容，表示 BSD 许可证授予商业用途、分发、修改、私人使用的权利；无蓝色点，表示授权时，无表格中这些限制；红色的点有两个，表示 BSD 采用有限责任制，并声明不提供任何保证。
关于此分类的详细情况，以及此模式下对不同许可证的区分解读，可查看项目官网了解详情。
许可证结构概览
除了主要授权内容及条件限制，一个许可证还包含其他要素，北大教授周明辉向我们介绍了其团队关于许可证的研究结果：
一个许可证会有序言；基本信息，包括许可证名称、版本号、发布日期、版权声明、链接地址；条款与条件，包括定义、授权、使用修改分发的行为限制、违约与授权终止、担保与责任限制、版本与兼容性；使用说明，包括作品描述、作品版权声明、许可证原文链接、联系方式。
![]()
也就是说，如果开发者想要全面了解一个开源许可证，还要看该许可证的版权声明、对一些责任主体的定义等等。以下也是周明辉团队对许可证条目结构的概括：
![]()
多语言问题
许可证存在多语言问题。GNU 官网上只有非正式的 GPL 许可证翻译版本。并且明确声明官方不发行翻译，原因是避免法律纠纷和节省成本：
自由软件基金会 FSF 不批准许可证的翻译是正式有效的。原因是审阅困难又昂贵，需要其他国家的双语律师。而且如果有一处错误，可能对整个自由软件社区造成灾难性的结果。只要翻译版不是正式的，那么它们就不会造成任何法律上的危害。
周明辉解释，这种情况是普遍的，几乎没有多语言的开源许可证，因为很多法律风险是在应用过程中才会被发现。这也是木兰许可证建立的一个重要原因。
中国第一个国际通用的开源许可证是木兰开源许可证第二版（MulanPSL v2）。今年3月，MulanPSL v2 通过 OSI 审核。实际上，去年8月木兰就发布了第一个版本《木兰宽松许可证，第 1 版》，12月向 OSI 提交第一版的认证申请，但这一版本有两个问题还需讨论，其中之一就是多语言问题，Mulan PSL 采用中英双语，但两种语言的解释可能冲突从而存在潜在风险。经社区讨论修改后，今年1月再次提交的新版本 Mulan PSL v2 增加了语言条款，声明中文为规范语言，在与英文版本发生冲突时以中文为准。
Mulan PSL v2 授予“贡献者”版权许可和专利许可，无商标许可。
分发时需保留一定版权信息：
您可以在任何媒介中将“软件”以源程序形式或可执行形式重新分发，不论修改与否，但您必须向接收者提供“本许可证”的副本，并保留“软件”中的版权、商标、专利及免责声明。
同时也有免责声明和责任限制：
“软件”及其中的“贡献”在提供时不带任何明示或默示的担保。在任何情况下，“贡献者”或版权所有者不对任何人因使用“软件”或其中的“贡献”而引发的任何直接或间接损失承担责任，不论因何种原因导致或者基于何种法律理论，即使其曾被建议有此种损失的可能性。
中国目前并没有可以证明开源许可证法律效力的判例，
开源许可证变更
开源项目选择一个许可证之后，往往不会变更。周明辉介绍，变更许可证会影响到一开始的商务考虑，也会使软件本身的可持续性变得复杂，“厂商选择不同许可证都是有其考虑的，例如 GPL 就是为了逼着所有人代码开放，因此基础共享，Apache 许可证就是商业超级友好。使用开源软件的厂商也会考虑他使用开源软件的许可证是什么类别，因为会影响到他的商业选型。”
但近两年因新的技术浪潮与许可授权新问题的出现，一些厂商会变更许可证，以下通过两个实例主要涉及商业化与专利权引发的摩擦，这两点也是开发者在选择许可证时，尤其需要结合自身特性考虑的地方。
一是开源厂商与云厂商之间的纠纷，导致一些云计算基础性开源项目改用商业受限许可证。宽松许可证允许修改后的代码闭源，因此，一些云厂商集成开源软件时，可以不受限制地使用、修改这些软件，并且集成到自己的服务中再商业化，却不会回馈开源社区。这便违背了开源许可证想要自由与分享的初衷。
MongoDB 2019 年 10 月份宣布将开源 License 从 GNU AGPLv3 切换到 Server Side Public License（SSPL），SSPL 明确要求托管 MongoDB 实例的云厂商要么获取商业许可证，要么向社区开放其服务源码，以此回应 AWS 等云厂商将 MongoDB 以服务的形式（DBaaS）提供给用户而没有回馈开源社区的行为。
另一例涉及人工智能领域对算法专利权的看法。2020 年 5 月 22 日，OpenCV 技术委员会在一次会议中提出，拟将授权协议从 BSD 协议改为 APL 2 协议。因为 BSD 协议不授予专利许可，OpenCV 举了一个例子说明不授予专利的影响：
试想这样一种情况：某名为“发明”的公司为某算法申请了专利，并发表了论文。因算法效果优秀，某 CV 爱好者依论文编写了代码，并以 BSD 协议将代码提交到 OpenCV。这个过程中没人知道算法已申请专利，隐患便被埋下。
另一名为“发财”的公司将 OpenCV 中的这个算法应用到其产品中。依照现有 BSD 协议，此公司可以商业销售产品，只需注明产品使用了 OpenCV，而无需对用户开源。
“发明”发现“发财”使用了其专利技术，遂起诉“发财”要求赔偿和停止侵权，并顺带起诉或要求开源社区停止侵权。一旦发生这样的案例，“发财”肯定要破财。开源软件声誉也会受到负面影响。
有声音指出没有专利许可算法的风险：一般来说职务发明的专利所有人是大学而非教授，如果几年后有公司从大学购买了专利，那么如何保证公司不去追究已经使用了该算法的用户？所以 OpenCV 选择有专利许可的协议，可以提高安全性。
但反过来，开发者在为自己的算法选择许可证时，如果不开放专利许可，则会将降低开发界的接受度。而外界对不同项目和许可证的接受程度也是需要综合考虑的。
云厂商更改协议意在防止商业化的软件的无偿使用，OpenCV 更改协议则是为了组织下的开源人工智能算法和项目不会给使用者带来专利权纠纷。这些案例或可作为开发者在选择开源许可证时的借鉴，即考虑清楚自身的商业需求，专利权需求，以及开发界对某许可证的接受程度。
开源与自由
开源软件上世纪末从自由软件运动中分流出来，经过20多年的发展变化，在许多方面与自由软件并无明显区别，表现在开源许可证上也是同样。
此前，《大教堂与集市》中文译者卫剑钒发表文章《使用 Apache 许可证的是自由软件吗？》，指出，使用 Apache 协议的是开源软件，也是自由软件，并在文末总结：“开源软件、自由软件其实差不多的，copyleft 则有更强烈的理想信念”。文中还引用了 FSF 官网上的类似观点：
开源软件和自由软件或多或少是同一类软件，虽然并不是完全相同：开源所接受的一些许可证我们看来限制过多，还有一些我们认可的自由软件他们不认可。但不管怎样，差异是很小的：几乎所有的自由软件都是开源软件，几乎所有的开源软件都是自由软件。
类似 Apache 许可证这样协议还有：
如此便可能出现问题：开发者为软件选择了上述之一的开源许可则，之后发现这个许可证也被定义为自由软件许可证，那么这个软件该怎么定义，是不是就变成了自由软件？
对此卫剑钒认为，软件叫什么不重要，是自由软件也不可怕，自由软件和开源软件并没有什么不同，关键还是看许可证。
这也可以理解为，仅从使用来看，开发者可以忽略自由与开源的界定，只需关注许可证本身的内容是否适合项目。不过如果开发者有自己的开源理念，并根据理念选许可证那就另当别论了，比如更喜欢 RMS 对自由软件的态度时，GPL 是不二选择；而更认可 OSI 对开源软件的定义及方式时，宽松型的开源许可证可能是较佳选择。
周明辉及其团队也专门研究了如何选择一个开源许可证的课题。第一个因素便是开源理念。此外还包括：对利益的评估、组织观念、社区偏好、许可证流行度和复杂度、许可证兼容性、其他项目影响、对项目特征的评估、许可证选择结果的影响。
![]()
开源许可证的研究还有很多，许可证涉及到的法律、商业化等问题也颇为广泛。本篇概括了一些许可证的选择方法和相关风险提示，关于许可证研究的细节和其他问题，开源中国会持续关注，之后还会有更多相关文章，敬请关注……
