开源合规建议
企业研发活动涉及开源的主要有两种情况，一是企业作为开源项目发起方自主开源某个项目，另一个是企业在研发创新过程中使用到他人已开源的开源代码。
（一）自主开源
当进行开源软件的发布时，需要注意以下内容：
（1）组件情况审核：确定开源项目所使用到的组件信息，包括内部组件和外部组件，核查组件的来源出处、组件所适用的许可证，并根据组件的具体情况为开源项目选取合适的许可证。对于使用的外部组件，需审核对此类组件的使用是否符合相应许可证的规定。对于企业自主开发的组件，应保证版权权利完整性，避免版权权利瑕疵。
（2）知识产权风险评估
专利：对于使用到的外部组件，评估是否存在专利侵权风险；对于企业自主开发的软件部分，可通过FTO（freedom-to-operate）分析评估是否存在专利侵权风险；
商标：审核是否存在不当使用商标的情况；
版权：审核拟开源项目的版权是否完整。
（3）知识产权布局
对于自主开源的项目，应积极进行知识产权布局，包括专利申请、版权登记和商标注册。
（4）数据安全及隐私审核：
审核数据内容是否符合国家法律法规对数据安全的要求；审核数据内容是否符合公司对数据安全的要求。
（5）声明审核、许可证选择及兼容性评估
A.声明审核
开源项目的发布通常需进行著作权声明、许可证声明、免责声明、修改声明等，需确认这些声明文件随项目一起发布。
B.许可证选择
根据开源项目特点及开源目的，确定合适的许可证。这里需结合项目使用到的组件所适用的许可证进行综合评估。
C.兼容性评估
若项目中引入了其他开源组件，同时需进行许可证兼容性评估。
（二）开源软件的使用
第一，我们大多数开发人员在引入开源软件的时候不够谨慎，给后续埋下无穷的安全隐患。当这些引入的开源软件随着产品发布上网，出现了问题给后续的维护带来极高的成本，甚至于违反法律造成巨大的经济损失。所以，在软件引入的那一刻，就需要对开源软件进行仔细的评估。包括许可证传染性评估、兼容性评估等，具体可参见上期内容，这里不再赘述。
第二，充分了解所使用的开源软件的许可证所赋予的权利和义务，严格遵循开源许可证（具体内容可参见上期内容）。同时，为了避免代码被传染，可采用一定的技术处理方式将代码进行隔离，将使用开源软件开发的程序与未使用开源软件开发的程序进行隔离。对于著佐权型的开源许可证，即有传染性条款的开源许可证，隔离程序有利于将其他未使用开源软件的程序，形成独立程序，避免受到开源许可证传染性的约束。同时，在有条件的情况下，考虑不同软件在功能、分工、所用技术等方面的差别，进行分别独立打包、部署、进行计算机软件登记，这有利于其他联合的软件被认定为独立软件从而不被传染。
第三，在产品开发过程中检测和拦截漏洞及不合规的license，以免这些问题扩散到网上。
第四，定期了解开源软件的情况，能够持续跟踪企业内正在使用的开源软件的社区情况、版本更新情况、开源许可证变更情况、社区发展情况及安全漏洞情况等，定期对相关信息进行分析、评估和处置。如出现许可证变更，尤其是由宽松型许可证变更为严格型许可证时，应及时评估许可证变更带来的风险，对已经应用了开源软件的信息系统是否被传染进行评估和判断；对于长期不更新的开源软件应予以重视，评估开源软件的先进性和自身维护成本；对于开源软件漏洞应定期跟踪，及时反馈给软件维护方进行修复和处置。
第五，根据定期跟踪的结果，判断当前开源软件是否适应所应用的场景，对于有风险及“老旧”的开源软件应建立合理的退出机制，根据实际情况制定开源软件退出、替换等规划。
开源许可证热点问题解析
（一）GPL下的源代码是否必须公开
1、GPL许可证的义务在分发代码时才会被触发，若仅为私人使用且不分发“distribution”，则源代码可不公开。这也适用于组织（包括公司）。一个组织可以建立自己的修改版本，在内部使用它，而永远不在组织外发布它。
2、对遵循GPL的源代码进行分发，无论是否修改，均需遵循GPL的规定公开源代码。在一个公司或组织内使用多份复件，不被认为是分发。但提供给其他公司、组织或个人（组织外），则会被认为是分发。
（二）GPL下源代码如何公开
1、二进制软件包分发时，伴随相应源代码一起分发。
2、商业分发不带源代码的二进制软件包，须包含一份至少三年内有效的，承诺提供源代码的书面文件，并且提供源代码的价格不得超过实际发布源代码所需成本；或通过网络服务器免费提供这些对应源代码的访问。若是以指定的地点提供存取位置供人复制可执行码或目标代码，则应当在相同地点提供源代码以供复制。
3、分发GPL程序时，应保留原程序版权声明及无担保声明；维持所有有关GPL许可协议以及无担保声明的原貌（Provided as is）；并将GPL许可协议的副本连同GPL程序一起传播给任何其它他接收者。
（三）是否可以发布一个私有系统，私有系统中包含GPL软件
可以随私有系统发布GPL软件。要正当的这么做，必须确保自由和非自由程序不能过于紧密地通信，就是不能以实际上它们是一个程序的方式组合它们。
紧密地通信和一个程序的方式组合：
如何界定组合两个部分到一个程序，一个恰当的准则是基于通信的机制（exec，pipes，rpc，共享地址的函数调用，等等）和通信的语义（交换什么类型的信息）。如果模块是在相同的可执行文件中包含的，它们很明确是组合到一个程序的。如果模块被设计为连接在一起并在共享地址空间运行的，基本上可以肯定他们是组合到一个程序的。
作为对比，管道、socket和命令行参数是两个独立程序通常使用的通信机制。所以当使用它们通信，模块通常都是独立的程序。但如果通信机制足够亲密，交换复杂的内部数据结构，那也可能把这两个部分组合到一个更大的程序。
（四）GPL、LGPL、MPL传染性的区别
概况地说，GPL、LGPL和MPL三者传染性的范围大致可以区分如下：
MPL: 以文件传染，适用于包含MPL代码的文件。（The copyleft applies to any files containing MPLed code.）
LGPL: 适用于基于LGPL代码的库作品。（The copyleft applies to any library based on LGPLed code.）
GPL: 适用于基于GPL代码的软件(无论是否修改）。（The copyleft applies to all software based on GPLed code.）
（五）GPL下传染性的例外：聚合作品
GPLv1：仅将本程序（或基于本程序的程序，即衍生作品）与另一项独立作品聚合到一定数量的存储或分发介质上，并不会导致该独立作品受GPL协议的约束。
GPLv2：仅仅将另一个作品（并非基于开源软件）和开源软件或者开源软件的衍生作品聚合在一起，并不会导致该另一个作品受到GPL协议的约束。
GPLv3：将GPL下的覆盖作品（指适用GPL协议的程序或者基于适用GPL协议的程序所开发出来的作品）和其它独立功能的作品在一个储存库或分发介质上“聚合”在一起，如果这些独立功能作品本质上不是覆盖作品的扩展作品，而且也不是与覆盖作品合并在一起生成一个更大的程序，且对该聚合作品所进行的版权限制性规定不能超过其中独立功能作品的版权限制规定，则这样的联合体可称为“聚合作品”。在聚合作品中的覆盖作品适用GPL协议，而独立功能的作品则可不受GPL协议约束。
（六）LGPL传染性——"基于函数库的作品" Vs "使用函数库的作品"
在涉及LGPL下的函数库时，需要关注"基于函数库的作品" 以及 "使用函数库的作品"之间的差异：前者包含来自函数库修改过的原始码；而后者则必须与函数库结合才能执行。LGPL规定"基于函数库的作品"，必须以LGPL发布。
对遵循 LGPL 的函数库进行任何改动和/或再次开发并予以发布的作品(基于函数库的作品），必须继承 LGPL 协议。如果程序仅对遵循 LGPL 的软件进行任何动态连接、调用而不是包含，则程序可不遵循LGPL，允许在有私有的程序中使用LGPL下的函数库。
（七）动态链接与静态链接的区别
LGPL许可证，适用于特殊设计的函数库。准许非自由的程序可以与这些函数库连接。在以LGPL发布的库的基础上开发新的库的时候，新的库必须以LGPL发布，但是如果仅仅是动态链接，那么则不受任何限制。
静态链接库：程序与库的链接是在编译的时候创建的。代码经过合并形成了一个单一的可执行文件。静态链接后形成的可执行文件被认为是原程序的衍生作品，如果是基于GPL/LGPL代码，则需强制适用GPL/LGPL许可证。
动态链接库：库的代码并没有在编译的时候被拷贝到一个新的可执行文件，仍然以原有库文件的形式存储。当计算机在运行程序时，它将调入库文件中的模块，使程序与库链接。动态链接在GPL许可证下被认为是衍生作品，强制适用GPL许可证，但在LGPL下更自由，可以不适用LGPL许可证。
（八）MPL的被授权人是否可以其它许可证发布自己的软件程序
MPL的被授权人可以为程序的执行形式选择非MPL条款来授权，不过这个非MPL条款的内容必须不违背MPL，并且不可以尝试去限制或改变到MPL所赋与程序原始码接收者的权利。
此外，被授权人可以将MPL程序码与其他程序码结合在一起，成为一个「广义著作（Larger Work）」，即使这个广义著作中的其他程序码并非适用MPL授权也可以，只要被授权人依照MPL规定遵行义务即可。
企业研发活动涉及开源的主要有两种情况，一是企业作为开源项目发起方自主开源某个项目，另一个是企业在研发创新过程中使用到他人已开源的开源代码。
（一）自主开源
当进行开源软件的发布时，需要注意以下内容：
（1）组件情况审核：确定开源项目所使用到的组件信息，包括内部组件和外部组件，核查组件的来源出处、组件所适用的许可证，并根据组件的具体情况为开源项目选取合适的许可证。对于使用的外部组件，需审核对此类组件的使用是否符合相应许可证的规定。对于企业自主开发的组件，应保证版权权利完整性，避免版权权利瑕疵。
（2）知识产权风险评估
专利：对于使用到的外部组件，评估是否存在专利侵权风险；对于企业自主开发的软件部分，可通过FTO（freedom-to-operate）分析评估是否存在专利侵权风险；
商标：审核是否存在不当使用商标的情况；
版权：审核拟开源项目的版权是否完整。
（3）知识产权布局
对于自主开源的项目，应积极进行知识产权布局，包括专利申请、版权登记和商标注册。
（4）数据安全及隐私审核：
审核数据内容是否符合国家法律法规对数据安全的要求；审核数据内容是否符合公司对数据安全的要求。
（5）声明审核、许可证选择及兼容性评估
A.声明审核
开源项目的发布通常需进行著作权声明、许可证声明、免责声明、修改声明等，需确认这些声明文件随项目一起发布。
B.许可证选择
根据开源项目特点及开源目的，确定合适的许可证。这里需结合项目使用到的组件所适用的许可证进行综合评估。
C.兼容性评估
若项目中引入了其他开源组件，同时需进行许可证兼容性评估。
（二）开源软件的使用
第一，我们大多数开发人员在引入开源软件的时候不够谨慎，给后续埋下无穷的安全隐患。当这些引入的开源软件随着产品发布上网，出现了问题给后续的维护带来极高的成本，甚至于违反法律造成巨大的经济损失。所以，在软件引入的那一刻，就需要对开源软件进行仔细的评估。包括许可证传染性评估、兼容性评估等，具体可参见上期内容，这里不再赘述。
第二，充分了解所使用的开源软件的许可证所赋予的权利和义务，严格遵循开源许可证（具体内容可参见上期内容）。同时，为了避免代码被传染，可采用一定的技术处理方式将代码进行隔离，将使用开源软件开发的程序与未使用开源软件开发的程序进行隔离。对于著佐权型的开源许可证，即有传染性条款的开源许可证，隔离程序有利于将其他未使用开源软件的程序，形成独立程序，避免受到开源许可证传染性的约束。同时，在有条件的情况下，考虑不同软件在功能、分工、所用技术等方面的差别，进行分别独立打包、部署、进行计算机软件登记，这有利于其他联合的软件被认定为独立软件从而不被传染。
第三，在产品开发过程中检测和拦截漏洞及不合规的license，以免这些问题扩散到网上。
第四，定期了解开源软件的情况，能够持续跟踪企业内正在使用的开源软件的社区情况、版本更新情况、开源许可证变更情况、社区发展情况及安全漏洞情况等，定期对相关信息进行分析、评估和处置。如出现许可证变更，尤其是由宽松型许可证变更为严格型许可证时，应及时评估许可证变更带来的风险，对已经应用了开源软件的信息系统是否被传染进行评估和判断；对于长期不更新的开源软件应予以重视，评估开源软件的先进性和自身维护成本；对于开源软件漏洞应定期跟踪，及时反馈给软件维护方进行修复和处置。
第五，根据定期跟踪的结果，判断当前开源软件是否适应所应用的场景，对于有风险及“老旧”的开源软件应建立合理的退出机制，根据实际情况制定开源软件退出、替换等规划。
开源许可证热点问题解析
（一）GPL下的源代码是否必须公开
1、GPL许可证的义务在分发代码时才会被触发，若仅为私人使用且不分发“distribution”，则源代码可不公开。这也适用于组织（包括公司）。一个组织可以建立自己的修改版本，在内部使用它，而永远不在组织外发布它。
2、对遵循GPL的源代码进行分发，无论是否修改，均需遵循GPL的规定公开源代码。在一个公司或组织内使用多份复件，不被认为是分发。但提供给其他公司、组织或个人（组织外），则会被认为是分发。
（二）GPL下源代码如何公开
1、二进制软件包分发时，伴随相应源代码一起分发。
2、商业分发不带源代码的二进制软件包，须包含一份至少三年内有效的，承诺提供源代码的书面文件，并且提供源代码的价格不得超过实际发布源代码所需成本；或通过网络服务器免费提供这些对应源代码的访问。若是以指定的地点提供存取位置供人复制可执行码或目标代码，则应当在相同地点提供源代码以供复制。
3、分发GPL程序时，应保留原程序版权声明及无担保声明；维持所有有关GPL许可协议以及无担保声明的原貌（Provided as is）；并将GPL许可协议的副本连同GPL程序一起传播给任何其它他接收者。
（三）是否可以发布一个私有系统，私有系统中包含GPL软件
可以随私有系统发布GPL软件。要正当的这么做，必须确保自由和非自由程序不能过于紧密地通信，就是不能以实际上它们是一个程序的方式组合它们。
紧密地通信和一个程序的方式组合：
如何界定组合两个部分到一个程序，一个恰当的准则是基于通信的机制（exec，pipes，rpc，共享地址的函数调用，等等）和通信的语义（交换什么类型的信息）。如果模块是在相同的可执行文件中包含的，它们很明确是组合到一个程序的。如果模块被设计为连接在一起并在共享地址空间运行的，基本上可以肯定他们是组合到一个程序的。
作为对比，管道、socket和命令行参数是两个独立程序通常使用的通信机制。所以当使用它们通信，模块通常都是独立的程序。但如果通信机制足够亲密，交换复杂的内部数据结构，那也可能把这两个部分组合到一个更大的程序。
（四）GPL、LGPL、MPL传染性的区别
概况地说，GPL、LGPL和MPL三者传染性的范围大致可以区分如下：
MPL: 以文件传染，适用于包含MPL代码的文件。（The copyleft applies to any files containing MPLed code.）
LGPL: 适用于基于LGPL代码的库作品。（The copyleft applies to any library based on LGPLed code.）
GPL: 适用于基于GPL代码的软件(无论是否修改）。（The copyleft applies to all software based on GPLed code.）
（五）GPL下传染性的例外：聚合作品
GPLv1：仅将本程序（或基于本程序的程序，即衍生作品）与另一项独立作品聚合到一定数量的存储或分发介质上，并不会导致该独立作品受GPL协议的约束。
GPLv2：仅仅将另一个作品（并非基于开源软件）和开源软件或者开源软件的衍生作品聚合在一起，并不会导致该另一个作品受到GPL协议的约束。
GPLv3：将GPL下的覆盖作品（指适用GPL协议的程序或者基于适用GPL协议的程序所开发出来的作品）和其它独立功能的作品在一个储存库或分发介质上“聚合”在一起，如果这些独立功能作品本质上不是覆盖作品的扩展作品，而且也不是与覆盖作品合并在一起生成一个更大的程序，且对该聚合作品所进行的版权限制性规定不能超过其中独立功能作品的版权限制规定，则这样的联合体可称为“聚合作品”。在聚合作品中的覆盖作品适用GPL协议，而独立功能的作品则可不受GPL协议约束。
（六）LGPL传染性——"基于函数库的作品" Vs "使用函数库的作品"
在涉及LGPL下的函数库时，需要关注"基于函数库的作品" 以及 "使用函数库的作品"之间的差异：前者包含来自函数库修改过的原始码；而后者则必须与函数库结合才能执行。LGPL规定"基于函数库的作品"，必须以LGPL发布。
| 含义 | |
| 基于函数库的作品 | 意指函数库或任何在版权法下的衍生作品：也就是说，一个包含了本函数库或其一部分的作品，可以是原封不动的，或是经过修改的，和/或直接翻译成其他语言的。 |
| 使用函数库的作品 | 一个程序若包含不经任何部分修改的函数库，但却是设计经由编译或连结的方式与本函数库一同工作者，称之为 "使用函数库的作品"。这样的一个作品，严格地说，并非本函数库的衍生作品，因而不在本许可证的范围之内。 将 "使用函数库的作品" 与本函数库连接而产生可执行程序，则是本函数库的衍生品 (因为它包函了本函数库的一部分），而不是 "使用函数库的作品"，因此其可执行程序包含在本许可证的范围内。 |
对遵循 LGPL 的函数库进行任何改动和/或再次开发并予以发布的作品(基于函数库的作品），必须继承 LGPL 协议。如果程序仅对遵循 LGPL 的软件进行任何动态连接、调用而不是包含，则程序可不遵循LGPL，允许在有私有的程序中使用LGPL下的函数库。
（七）动态链接与静态链接的区别
LGPL许可证，适用于特殊设计的函数库。准许非自由的程序可以与这些函数库连接。在以LGPL发布的库的基础上开发新的库的时候，新的库必须以LGPL发布，但是如果仅仅是动态链接，那么则不受任何限制。
静态链接库：程序与库的链接是在编译的时候创建的。代码经过合并形成了一个单一的可执行文件。静态链接后形成的可执行文件被认为是原程序的衍生作品，如果是基于GPL/LGPL代码，则需强制适用GPL/LGPL许可证。
动态链接库：库的代码并没有在编译的时候被拷贝到一个新的可执行文件，仍然以原有库文件的形式存储。当计算机在运行程序时，它将调入库文件中的模块，使程序与库链接。动态链接在GPL许可证下被认为是衍生作品，强制适用GPL许可证，但在LGPL下更自由，可以不适用LGPL许可证。
（八）MPL的被授权人是否可以其它许可证发布自己的软件程序
MPL的被授权人可以为程序的执行形式选择非MPL条款来授权，不过这个非MPL条款的内容必须不违背MPL，并且不可以尝试去限制或改变到MPL所赋与程序原始码接收者的权利。
此外，被授权人可以将MPL程序码与其他程序码结合在一起，成为一个「广义著作（Larger Work）」，即使这个广义著作中的其他程序码并非适用MPL授权也可以，只要被授权人依照MPL规定遵行义务即可。