一、常见开源许可证之Apache、MIT、BSD解读及合规使用
1、Apache 许可证
（1）概述
Apache是Apache软件基金会发布的自由软件许可证，最初为Apache http服务器而撰写。
Apache 1.0版是最原始的Apache许可证。
Apache 1.1版在2000年由Apache软件基金会公布，相较于1.0最主要的改变在于广告条款，衍生产品只需要在文件里注明，而不像1.0需要在所有的地方注明。
Apache 2.0版在2004年1月由Apache软件基金会公布。以Apache 2.0公布的代码，可以被合并入专有软件，并且在各种各样的限制性条件下发布。允许闭源商用，也允许更换许可证，将衍生软件以其它许可证分发。
Apache许可证是宽松型许可证，商业软件最爱，主要条件是要求保留原始版权和许可声明，同时原始开发者/贡献者向使用者明确授予专利权。使用者可以自由修改，进行商业使用，大型项目可以不同的条款分发，没有开源要求，修改源代码需要记录变更。
相关网址：http://www.apache.org/licenses/LICENSE-2.0
（2）使用要求
A. 分发作品或者衍生作品，须要明确给予接收者许可证副本；
B. 分发修改后的作品中，须在作品中明确声明已经修改的内容；
C. 必须在衍生作品的源代码中明确保留原作品的版权、专利、商标和相关通知说明；
D. 如果原作品中包含“NOTICE”文件，则衍生作品中须包含该“NOTICE”文件；
E.专利报复条款：若某一使用者针对任何主体主张该开源项目的程序侵犯其专利权，则在该使用者提起专利诉讼之日起，该使用者在该开源项目下享受的专利许可权利终止。
F. 禁止将名称“Apache”用于衍生产品，或表示对衍生产品的认同。禁止以任何可能声明或暗示基金会认可你的分发版本或创建Apache 软件的形式下使用 Apache 软件基金会拥有的标志。
2、BSD 许可证
（1）概述
The BSD License（BSD）是Berkeley Software Distribution License的缩写。BSD起源自加州大学柏克莱分校，最原始分发的BSD拥有者是加州大学董事会。
最初的BSD是由四个主要条款构成的，其中广告条款的存在让许多后来参与修改原始码的使用者均会将其名字加入声明之中，而遭受GNU计划（GNU Project）的批评：该广告条款造成非常冗长的声明内容，是相当不便利，且易发生使用上困扰而与GPL不相容。BSD的官方主导人William Hoskins遂在1999年7月22日率先将该广告条款自BSD中删除，也引发其他使用BSD者的跟进，删除广告条款之后的BSD被称为“三条款 BSD”（3-clause BSD）或者”BSD-new”，而原本的被称为“四条款BSD”（4-clause BSD）。
BSD许可证是一种宽松型许可证，允许商业发布和销售。使用者可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
相关许可证：https://opensource.org/licenses/BSD-3-Clause
（2）使用要求
A. 源代码的发布必须保留BSD许可证中的版权声明和免责条款；
B. 目标代码的发布必须保留BSD许可证中的版权声明、免责条款和必要的其他信息；
C. 未经事先书面批准，不得将源代码中的作者信息、机构名称和修订者姓名等信息用于支持或推广开源软件的衍生产品。
3、MIT许可证
（1）概述
MIT许可证是宽松型许可证，最常用的许可证之一，只为作者保留版权，而无任何其他限制。人们可以对该项目进行任何操作，即使是制作和分发封闭源代码版本。MIT许可证之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），其内容与三条款BSD许可证（BSD 3-Clause license）内容颇为近似，但是赋予软件被授权人更大的权利与更少的限制。被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软件及软件的副本，可根据程序的需要修改授权条款为适当的内容。在软件和软件的所有副本中都必须包含版权声明和许可声明。
MIT许可证，又称“X条款”（X License）或“X11条款”（X11 License）。
网址：http://www.opensource.org/licenses/mit-license.php
（2）使用要求
A. 开源软件使用过程中，须保留软件的版权说明；
B. 开源软件使用过程中，须保留许可证中的授权说明；
C. 开源软件使用过程中，须保留许可证中的免责申明。
BSD和MIT等部分开源许可协议并未包含明确的专利许可条款用以许可用户使用软件所包含的相关专利，开源使用者很可能被开源贡献者提起专利诉讼并收取专利许可费。
为了避免上述风险，可开展专利预警分析、FTO分析规避专利侵权风险。此外，还可通过加入OIN等开源专利联盟组织，降低企业的专利侵权风险。
二、开源许可证兼容性分析
（一）概述
不同许可证的权利和义务的规定可能存在冲突。当将两个不同许可证下的代码合并成一个程序时，需注意两个许可证要兼容。兼容性问题是开发者就开源项目选择许可证主要考虑的因素之一。
所谓兼容是指为了合并两个程序（或者它们的一部分）到一个大型的系统，如果两个程序的许可证的授权协议容许，则两个许可证就是兼容的。如果没办法确保，则是不兼容的。
两个许可证不兼容，意味着修改合并后形成的一个更大的程序将无法同时满足两个许可证的要求，当把该两个许可证下的程序合并时，最终的程序只能按照某一个许可证发布，必将造成对另外一个许可证的违反。
一般来说，强传染性的许可证可以向下兼容弱传染性的许可证，这意味着软件最终许可证取决于强传染性许可证。
（二）常见开源许可证之间的兼容性
下图显示了常见开源软件许可证之间的条款兼容性的大致情况。
图中的箭头具有方向性，若两个许可证可透过一个或多个顺向的箭头从此端连至彼端，则此该两个许可证是兼容的，也就是说这两个许可证下的代码可以进行合并，合并后的整个作品须以箭头终点的许可证条款或其后箭头所指向的许可证条款进行授权。例如，MIT /X11 透过箭头，可直接或间接指向图中的所有其他许可证，即代表不论开发者是以何种授权的程序代码，皆可与 MIT/X11的程序代码相互合并。在MIT/X1→BSD→Apache2.0→MPL2.0→LGPLv2.1+→GPLv2+ 这条单向链路上，任意两个许可证都是兼容的。在Apache2.0←BSD→MPL1.1该双向链路上, Apache2.0与MPL1.1之间没有箭头连接，因此，表示Apache2.0与MPL1.1不兼容。此外，值得注意的是MPL1.1允许用户将MPL1.1许可下的代码以MPL1.1以后的版本分发（distribute），即可以MPL2.0分发，但是MPL1.1与Apache 2.0以及（L）GPL类许可证不兼容，因此MPL1.1与MPL12.0在图中没有箭头连接。
（三）各种GNU许可证组合的兼容性
下图是各种 GNU 许可证组合的兼容性的详细列表，它可以作为一个具体案例的快速参考。假定有一个软件使用了其中一个许可证，而你想把它的代码组合到你要发布的项目中（无论是你自己的原创，还是你对其他软件的修改版）。在表格的第一行找到你的项目要用的许可证，然后在左边第一列找到你要组合的软件的许可证。这一行一列的交叉表格就是你是否可以组合两个软件的答案。
“复制代码” 是指从一个软件取了一部分代码，改或不改都行，然后把它添加到你的程序中构成一个作品。“使用库” 是指没有直接复制源代码，而是在编译或运行时通过连接、导入或其他典型的机制把软件绑定在一起。
表格中有 GPLv3 的地方, 其兼容性的陈述对 AGPLv3 也适用。
各种 GNU 许可证组合的兼容性
参考网址：https://www.gnu.org/licenses/gpl-faq.html#SeparateAffero
上图中的数字1-9的含义如下：
1: 在这种情况下合并代码时，你必须遵循 GPLv2 的条款。你不能利用 GPL 以后版的优势。
2: 在这种情况下，你可以按照 GPLv2 或者其以后版发布你的项目（无论是原创还是改进），但是要注意你使用的其他代码必须继续只使用 GPLv2 许可证。只要你的项目还依赖于其他代码，你就不能把你的项目许可证升级为 GPLv3 或者其以后版本，而整个作品（你的项目和其他代码的组合）只能使用 GPLv2 来输送。
3: 如果你能够按照 GPLv2 或者其以后版本发布你的项目，那么你就可以选择使用 GPLv3 或者其以后版本来发布——一旦你这样做了，你就可以组合其他按照 GPLv3 发布的代码。
4: 如果你能够按照 GPLv2.1 或者其以后版本发布你的项目，那么你就可以选择使用 GPLv3 或者其以后版本来发布——一旦你这样做了，你就可以组合其他按照 GPLv3 发布的代码。
5: 在这种情况下合并代码时，你必须遵循 GPLv2.1 的条款。你不能利用 GPL 以后版的优势。
6: 如果你这样做了，那么只要项目的代码包含只遵循 LGPLv2.1 的代码，你就不能把该项目的许可证升级到 LGPLv3 或者其以后版本。
7: LGPLv2.1 允许你把代码重新按照 GPLv2 以后的 GPL 许可证发布。此时，如果你可以把 LGPL 代码按照合适的 GPL 发布（如表格所示），那么你就可以进行该组合。
8: LGPLv3 是 GPLv3 加上一些额外的许可，在这种情况下，你不用考虑这些额外的许可。
9: 由于 GPLv2 不允许和 LGPLv3 组合，所以此时你必须按照 GPLv3 的条款输送项目的代码，GPLv3 允许该组合。
通过第二期（上）（下）两篇，我们解读了常见的各类开源许可证，分享了各类许可证下的代码使用要求及兼容性分析，下期我们将从开源许可证热点问题和企业合规角度继续进行分享。
1、Apache 许可证
（1）概述
Apache是Apache软件基金会发布的自由软件许可证，最初为Apache http服务器而撰写。
Apache 1.0版是最原始的Apache许可证。
Apache 1.1版在2000年由Apache软件基金会公布，相较于1.0最主要的改变在于广告条款，衍生产品只需要在文件里注明，而不像1.0需要在所有的地方注明。
Apache 2.0版在2004年1月由Apache软件基金会公布。以Apache 2.0公布的代码，可以被合并入专有软件，并且在各种各样的限制性条件下发布。允许闭源商用，也允许更换许可证，将衍生软件以其它许可证分发。
Apache许可证是宽松型许可证，商业软件最爱，主要条件是要求保留原始版权和许可声明，同时原始开发者/贡献者向使用者明确授予专利权。使用者可以自由修改，进行商业使用，大型项目可以不同的条款分发，没有开源要求，修改源代码需要记录变更。
相关网址：http://www.apache.org/licenses/LICENSE-2.0
（2）使用要求
A. 分发作品或者衍生作品，须要明确给予接收者许可证副本；
B. 分发修改后的作品中，须在作品中明确声明已经修改的内容；
C. 必须在衍生作品的源代码中明确保留原作品的版权、专利、商标和相关通知说明；
D. 如果原作品中包含“NOTICE”文件，则衍生作品中须包含该“NOTICE”文件；
E.专利报复条款：若某一使用者针对任何主体主张该开源项目的程序侵犯其专利权，则在该使用者提起专利诉讼之日起，该使用者在该开源项目下享受的专利许可权利终止。
F. 禁止将名称“Apache”用于衍生产品，或表示对衍生产品的认同。禁止以任何可能声明或暗示基金会认可你的分发版本或创建Apache 软件的形式下使用 Apache 软件基金会拥有的标志。
2、BSD 许可证
（1）概述
The BSD License（BSD）是Berkeley Software Distribution License的缩写。BSD起源自加州大学柏克莱分校，最原始分发的BSD拥有者是加州大学董事会。
最初的BSD是由四个主要条款构成的，其中广告条款的存在让许多后来参与修改原始码的使用者均会将其名字加入声明之中，而遭受GNU计划（GNU Project）的批评：该广告条款造成非常冗长的声明内容，是相当不便利，且易发生使用上困扰而与GPL不相容。BSD的官方主导人William Hoskins遂在1999年7月22日率先将该广告条款自BSD中删除，也引发其他使用BSD者的跟进，删除广告条款之后的BSD被称为“三条款 BSD”（3-clause BSD）或者”BSD-new”，而原本的被称为“四条款BSD”（4-clause BSD）。
BSD许可证是一种宽松型许可证，允许商业发布和销售。使用者可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
相关许可证：https://opensource.org/licenses/BSD-3-Clause
（2）使用要求
A. 源代码的发布必须保留BSD许可证中的版权声明和免责条款；
B. 目标代码的发布必须保留BSD许可证中的版权声明、免责条款和必要的其他信息；
C. 未经事先书面批准，不得将源代码中的作者信息、机构名称和修订者姓名等信息用于支持或推广开源软件的衍生产品。
3、MIT许可证
（1）概述
MIT许可证是宽松型许可证，最常用的许可证之一，只为作者保留版权，而无任何其他限制。人们可以对该项目进行任何操作，即使是制作和分发封闭源代码版本。MIT许可证之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），其内容与三条款BSD许可证（BSD 3-Clause license）内容颇为近似，但是赋予软件被授权人更大的权利与更少的限制。被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软件及软件的副本，可根据程序的需要修改授权条款为适当的内容。在软件和软件的所有副本中都必须包含版权声明和许可声明。
MIT许可证，又称“X条款”（X License）或“X11条款”（X11 License）。
网址：http://www.opensource.org/licenses/mit-license.php
（2）使用要求
A. 开源软件使用过程中，须保留软件的版权说明；
B. 开源软件使用过程中，须保留许可证中的授权说明；
C. 开源软件使用过程中，须保留许可证中的免责申明。
BSD和MIT等部分开源许可协议并未包含明确的专利许可条款用以许可用户使用软件所包含的相关专利，开源使用者很可能被开源贡献者提起专利诉讼并收取专利许可费。
为了避免上述风险，可开展专利预警分析、FTO分析规避专利侵权风险。此外，还可通过加入OIN等开源专利联盟组织，降低企业的专利侵权风险。
二、开源许可证兼容性分析
（一）概述
不同许可证的权利和义务的规定可能存在冲突。当将两个不同许可证下的代码合并成一个程序时，需注意两个许可证要兼容。兼容性问题是开发者就开源项目选择许可证主要考虑的因素之一。
所谓兼容是指为了合并两个程序（或者它们的一部分）到一个大型的系统，如果两个程序的许可证的授权协议容许，则两个许可证就是兼容的。如果没办法确保，则是不兼容的。
两个许可证不兼容，意味着修改合并后形成的一个更大的程序将无法同时满足两个许可证的要求，当把该两个许可证下的程序合并时，最终的程序只能按照某一个许可证发布，必将造成对另外一个许可证的违反。
一般来说，强传染性的许可证可以向下兼容弱传染性的许可证，这意味着软件最终许可证取决于强传染性许可证。
（二）常见开源许可证之间的兼容性
下图显示了常见开源软件许可证之间的条款兼容性的大致情况。
图中的箭头具有方向性，若两个许可证可透过一个或多个顺向的箭头从此端连至彼端，则此该两个许可证是兼容的，也就是说这两个许可证下的代码可以进行合并，合并后的整个作品须以箭头终点的许可证条款或其后箭头所指向的许可证条款进行授权。例如，MIT /X11 透过箭头，可直接或间接指向图中的所有其他许可证，即代表不论开发者是以何种授权的程序代码，皆可与 MIT/X11的程序代码相互合并。在MIT/X1→BSD→Apache2.0→MPL2.0→LGPLv2.1+→GPLv2+ 这条单向链路上，任意两个许可证都是兼容的。在Apache2.0←BSD→MPL1.1该双向链路上, Apache2.0与MPL1.1之间没有箭头连接，因此，表示Apache2.0与MPL1.1不兼容。此外，值得注意的是MPL1.1允许用户将MPL1.1许可下的代码以MPL1.1以后的版本分发（distribute），即可以MPL2.0分发，但是MPL1.1与Apache 2.0以及（L）GPL类许可证不兼容，因此MPL1.1与MPL12.0在图中没有箭头连接。
（三）各种GNU许可证组合的兼容性
下图是各种 GNU 许可证组合的兼容性的详细列表，它可以作为一个具体案例的快速参考。假定有一个软件使用了其中一个许可证，而你想把它的代码组合到你要发布的项目中（无论是你自己的原创，还是你对其他软件的修改版）。在表格的第一行找到你的项目要用的许可证，然后在左边第一列找到你要组合的软件的许可证。这一行一列的交叉表格就是你是否可以组合两个软件的答案。
“复制代码” 是指从一个软件取了一部分代码，改或不改都行，然后把它添加到你的程序中构成一个作品。“使用库” 是指没有直接复制源代码，而是在编译或运行时通过连接、导入或其他典型的机制把软件绑定在一起。
表格中有 GPLv3 的地方, 其兼容性的陈述对 AGPLv3 也适用。
各种 GNU 许可证组合的兼容性
参考网址：https://www.gnu.org/licenses/gpl-faq.html#SeparateAffero
上图中的数字1-9的含义如下：
1: 在这种情况下合并代码时，你必须遵循 GPLv2 的条款。你不能利用 GPL 以后版的优势。
2: 在这种情况下，你可以按照 GPLv2 或者其以后版发布你的项目（无论是原创还是改进），但是要注意你使用的其他代码必须继续只使用 GPLv2 许可证。只要你的项目还依赖于其他代码，你就不能把你的项目许可证升级为 GPLv3 或者其以后版本，而整个作品（你的项目和其他代码的组合）只能使用 GPLv2 来输送。
3: 如果你能够按照 GPLv2 或者其以后版本发布你的项目，那么你就可以选择使用 GPLv3 或者其以后版本来发布——一旦你这样做了，你就可以组合其他按照 GPLv3 发布的代码。
4: 如果你能够按照 GPLv2.1 或者其以后版本发布你的项目，那么你就可以选择使用 GPLv3 或者其以后版本来发布——一旦你这样做了，你就可以组合其他按照 GPLv3 发布的代码。
5: 在这种情况下合并代码时，你必须遵循 GPLv2.1 的条款。你不能利用 GPL 以后版的优势。
6: 如果你这样做了，那么只要项目的代码包含只遵循 LGPLv2.1 的代码，你就不能把该项目的许可证升级到 LGPLv3 或者其以后版本。
7: LGPLv2.1 允许你把代码重新按照 GPLv2 以后的 GPL 许可证发布。此时，如果你可以把 LGPL 代码按照合适的 GPL 发布（如表格所示），那么你就可以进行该组合。
8: LGPLv3 是 GPLv3 加上一些额外的许可，在这种情况下，你不用考虑这些额外的许可。
9: 由于 GPLv2 不允许和 LGPLv3 组合，所以此时你必须按照 GPLv3 的条款输送项目的代码，GPLv3 允许该组合。
通过第二期（上）（下）两篇，我们解读了常见的各类开源许可证，分享了各类许可证下的代码使用要求及兼容性分析，下期我们将从开源许可证热点问题和企业合规角度继续进行分享。