一、基本概念
全球现有100+种license，根据WS公司的统计，2020年最受欢迎的TOP10的license，参见：
各类许可证及其评论
开源之道 开源之道 - 开源之道
开源许可协议比较及应用实例
截至2019年6月，国际开源组织OSI(Open Source Initiative)批准的许可证超过80种，其中被广泛使用的许可证包括以下8种：
根据使用条件的不同，开源许可证分为两大类，即Permissive许可证和Copyleft许可证。
Permissive许可证
Permissive License（宽松式许可证）允许用户不经许可可以随意复制、修改和发布，但是并不要求分发时必须使用相同的许可证，用户可以在修改代码后选择闭源，常见的Apache、BSD、MIT属于Permissive许可证。
BSD (Berkerley Software Distribution)
BSD许可证给予用户在使用开源代码方面很大的自由，分为2-Clause(两条款)和3-Clause(三条款)两类，需要遵守以下规则：
如果分发的软件包含源代码，则必须在源代码中保留原始的BSD许可证声明。
如果分发的软件仅包含二进制程序，则必须在文档或版权说明中保留原始的BSD许可证声明。
未经许可，不得使用原始作者或机构的名字为软件做市场推广。（仅3-Clause需要遵守）
使用BSD许可证的应用案例包括：Chromium，Django，FreeBSD，Nginx等。
Apache-2.0
Apache Licence是著名的非盈利开源组织Apache采用的协议，需要遵守以下规则：
必须在源代码中保留原始的Apache许可证声明。
如果用户修改了源代码，需要在被修改的文件中说明。
在衍生产品中，必须保留原来代码中的版权、专利、商标及作者规定的其他需要包含的说明等信息。
如果在分发的软件中包含Notice文件，则需要在Notice文件中包含Apache许可证声明。
使用Apache 2.0许可证的应用案例包括：Apache家族系列产品，如Hadoop, OpenOffice, Spark，SVN, 以及Swift、Kubernetes、Android Open Source Project (AOSP)等。
MIT (Massachusetts Institute of Technology)
和BSD-2-Clause类似，即需要遵守以下规则：
如果分发的软件包含源代码，则必须在源代码中保留原始的MIT许可证声明。
如果分发的软件仅包含二进制程序，则必须在文档或版权说明中保留原始的MIT许可证声明。
使用MIT许可证的应用案例包括：Bootstrap, jQuery, Node.js, Rails等。
Copyleft许可证
Copyright（版权） 的意思是未经许可，用户无权复制和使用。Copyleft License（反版权许可证） 作为Copyright的反义词，意为未经许可，用户也可以随意复制、修改和发布，但要求分发者必须使用相同的许可证发布修改后的衍生作品，以保证衍生作品也能被其他人自由使用，常见的AGPL, GPL, LGPL, MPL属于Copyleft许可证。
GPL 2.0
只要软件中引用及修改了GPL代码或者链接了GPL类库，整个软件就就必须遵循GPL，不仅需要公开所有源码，并且允许他人可以自由地复制和分发。
使用GPLv2许可证的应用案例包括：Linux内核、MySQL等。
Linux 内核使用的是 GPLv2 许可证，为什么不使用 GPLv3 许可证？
要回答这个问题，首先要搞清楚以下两个问题：GPLv3 许可证比 GPLv2 许可证增加了什么条款？为什么 Stallman 要发布GPLv3 许可证？
GPLv3 许可证修复了 GPLv2 许可证中一些没有定义的条款，比如其中的：
专利。 假设，代码贡献者就某个软件申请了专利，随后又以 GPLv2 许可证发布了这个软件，大部分人认为以 GPLv2许可证发布的代码是免费的，所以纷纷使用了代码。代码贡献者某一天突然宣布自己拥有了软件专利，使用者都要交费。这种情况就阻碍了 Stallman 所期望的“程序自由”。Stallman 提出自由软件和 GPL 许可证的初衷是为了创建一个自由软件的王国，就是可以自由修改、复制和分发任何软件的“程序自由”。为了避免上述这种情况的发生，GPLv3 许可证就增加了代码贡献者已承诺放弃收取已授权或者未来会授权的专利的许可费这样的条款。
衍生作品的可获取性。 GPLv3 许可证就衍生作品（原有 GPLv3 许可证软件的修改版本）的源代码的可获取性做了更加严格的约定，有效打击了“想要源码上门自取”的这类企业。
实际上，GPLv3 许可证中新增的上述条款，是 Linus 喜闻乐见的：
有关专利的条款可有效避免专利纠纷，显然对 Linux 内核是有利的。
Linus 认为 GPLv2 许可证强制回馈源码是 Linux 获得成功的关键。
由此看，上述新增条款不是 Linus 反对 GPLv3 许可证的真正原因。
Linux 内核不使用 GPLv3 许可证的真正原因到底是什么？其实与 GPLv3 许可证中新增的允许别人修改并替换原有二进制代码的强制性要求有关。
GPLv3 许可证诞生于 2007 年，同一年诞生的还有 iPhone 。2007 年或者更早几年，消费类电子产品开始大行其道。在 PC 上，只要你得到了某个程序的源代码，就可以自行编译生成二进制程序，然后替换掉原有的二进制程序，你的程序自由很容易得到保证。然而 iPod、iPhone 等消费类电子产品，厂家会锁上硬件，不允许消费者破解其中的程序。消费者即使拿到了源码，修改了其中的缺陷，或者增加了新功能，优化了算法，也无法放到你的设备上运行，所以无法保障程序自由。如 Stallman 这样执着于全人类程序自由的人，怎么会容忍这种情况发生？因此，Stallman 试图通过 GPLv3 许可证来弥补这个漏洞：GPLv3 许可证要求衍生作品必须提供源代码，并且允许任何人可以修改源代码并替换掉原有的二进制版本。Linus 追求的是全世界人人都用上 Linux，他不在乎最终用户是否可以破解整个系统，只要消费类电子产品的厂商能回馈代码到 Linux 内核。但明显 GPLv3 许可证的这个条款会阻碍 Linux 在嵌入式或者消费类电子产品，比如智能手机上的推广，这是 Linus不能接受的，也导致 Linux 不使用 GPLv3 许可证。
归根究底，Stallman 是个理想主义者，而 Linus 是个实用主义者。也许，现实世界就是宽容博大，既需要 Stallman 这样的理想主义者，也需要 Linus 这样的现实主义者。
GPL 3.0
GPLv3包含了明确的专利许可以及添加了对数字版权管理和加密签名的限制，不仅要求用户公开源码，还要求公布相关硬件及必要的安装信息。
GPLv3能与更多的许可证兼容，例如Apache 2.0，但这个兼容是单向的，即GPLv3许可证的项目中可以包含Apache 2.0的开源代码，但是Apache许可证的项目不能包含GPLv3的开源代码。值得注意的是，GPLv3与GPLv2却并不兼容，即一个项目中不能同时包含GPLv2和GPLv3的代码，但是，如果软件以GPL “v2或更高版本”许可证发布，则与GPLv3兼容。
使用GPLv3许可证的应用案例包括：GCC，Emacs等。
AGPL
AGPL是对GPL的补充，如果使用了AGPL代码的软件是一个网络应用，那么这个软件的所有源码和修改代码也必须开源，除非购买了该AGPL代码的商业授权。
使用AGPL许可证的应用案例包括：BerkeleyDB，MongoDB (2018年10月前发布的版本)，Wiki.js等。
LGPL
和GPL相比，LGPL限制更少，是一个主要为类库使用设计的开源协议，需要遵守以下规则：
如果软件通过动态链接的方式使用LGPL类库，则该软件不需要开源。
如果软件通过静态链接的方式使用LGPL类库，则软件作者必须提供程序的二进制目标文件（不需要提供源代码），以便用户有机会更新LGPL类库并重新链接到该程序。
如果修改了LGPL的源码或者衍生了新的代码，则所有修改后及衍生的代码也必须遵循LGPL许可证。
使用LGPL许可证的应用案例包括：7-Zip，GLib，uClibc等。
MPL (Mozilla Public License)
MPL License由Mozilla基金会开发并维护，介于BSD（衍生代码可以闭源）和GPL（衍生代码必须以GPL方式开源）之间，最新发布的2.0版以更简洁和更好的兼容其他协议为目标，鼓励企业和开源社区为开发核心软件做更多贡献。使用MPL源码需要遵守以下规则：
如果修改了MPL的源码或者衍生了新的代码，并且以源代码方式发布的文件，则所有修改后及衍生的代码也必须遵循MPL许可证。
如果用户自有的源码通过专用接口访问MPL的源码及类库，则包含专用接口的代码必须遵循MPL许可证，用户自有源码不必遵循MPL许可证。
用户获得MPL代码中的专利许可，但是不能使用其原始商标。
使用MPL许可证的应用案例包括：Mozilla Firefox, Mozilla Thunderbird, Apache Flex, LibreOffice等。
EPL (Eclipse Public License)
EPL License由Eclipse基金会开发并维护，在CPL基础上删除了专利相关诉讼的限制条款。EPL比GPL许可证更为宽松，并且与GPL并不兼容。使用EPL源码需要遵守以下规则：
如果修改了EPL的源码或者衍生了新的代码，并且以源代码方式分发，则所有修改后及衍生的代码也必须遵循EPL许可证。
如果软件以二进制目标文件的形式分发，则需要声明可以根据请求向其他用户提供源代码。
用户获得EPL代码中的专利许可。
使用EPL许可证的应用主要为Eclipse基金会名下的软件，如著名的集成开发工具 - Eclipse。
开放源代码软件
开放源代码软件与自由软件是两个不同的概念，只要符合开源软件定义的软件就能被称为开放源代码软件（开源软件）。自由软件是一个比开源软件更严格的概念，因此所有自由软件都是开放源代码的，但不是所有的开源软件都能被称为“自由”。但在现实上，绝大多数开源软件也都符合自由软件的定义。比如，遵守GPL和BSD许可的软件都是开放的并且是自由的。
虽然开放源代码的堡垒看似严谨，但其实大部分的程序开发员都弄不清各种许可证之间的差别，导致成为了小部分别有用心人士所利用的对象，较著名的例子有DivX，早期DivX雏形是一个LGPL的自由软件，由大部分优秀的软件高手义务地开发，但当软件渐渐成形时，DivX的公司DXN利用LGPL的漏洞对DivX进行了闭源，大部分软件爱好者都感到被出卖，所以着手开发了XviD。虽然XviD在软件方面明显比DivX优秀，但市场占有率却不如DivX。
GNU
GNU是一个自由的操作系统，其内容软件完全以GPL方式发布。这个操作系统是GNU计划的主要目标，名称来自GNU's Not Unix!的递归缩写，因为GNU的设计类似Unix，但它不包含具著作权的Unix代码。GNU的创始人，理查德·马修·斯托曼，将GNU视为“达成社会目的技术方法”。
作为操作系统，GNU的发展仍未完成，其中最大的问题是具有完备功能的内核尚未被开发成功。GNU的内核，称为Hurd，是自由软件基金会发展的重点，但是其发展尚未成熟。在实际使用上，多半使用Linux内核、FreeBSD等替代方案，作为系统核心，其中主要的操作系统是Linux的发行版。Linux操作系统包涵了Linux内核与其他自由软件项目中的GNU组件和软件，可以被称为GNU/Linux
该系统的基本组成包括GNU编译器套装（GCC）、GNU的C库（glibc）、以及GNU核心工具组（coreutils）[14]，另外也是GNU调试器（GDB）、GNU二进制实用程序（binutils）[15]的GNU Cash shell中[10] 和GNOME桌面环境。
开源软件的网络安全问题
开源软件网络安全的法律问题受到境外的进出口监管和境内《网络安全法》的双重考验。境外国家基于主权的出口规则穿透并从软件、源码、人员、平台等角度分别对开源进行监管，本国《网络安全法》的体系规则则对开源的繁荣与安全之间的平衡重新设定了评价机制。在两者多因素作用下， 开源软件的网络安全实践活动需要审慎调整以迎合或规避监管规则变化带来的深刻挑战。
本文分析了开源软件的协议安全问题，以事件导向引入并回答了合同与进出口监管冲突的若干问题，并以此为契机对开源软件的网络安全法律问题进行了梳理，提出了相应建议。
1 背景 2019 年 5 月， 公开信息显示 Linux 基金会就列入美国商务部实体名单实体的开源软件适用性和是否限制出口作出了声明，其主要观点涉及四点：
（1）当前在法律上对名单实体的限制主要围绕出口监管规则（EAR）进行；
（2）对于开源软件中的开源加密软件的源码，已经属于 “可公开获取” 的物项，因此不受 EAR 监管；
（3）单独的开源（软件）项目（按照公开信息显示目前维护数量大致在 123 个）仍然应当向商务部工业与安全局（BIS）和国家安全局（NSA） 履行 EAR 规定通知要求，方能满足 “可公开获取” 的条件；
（4）开源软件、开源代码协作、会议、培训、会员资格或赞助属于不受 EAR 约束的活动。
结合该声明及其前后的各方解读，产生了以下几个主要问题：
一是开源协议是否能够抗辩出口监管；
二是如果开源协议不能或不足以抗辩出口监管，如何在出口监管规则中寻求开源出口的合规，或者说例外适用；
三是如果已知案例认定开源（代码）作为言论自由的表达， 这些既有的经典案例是否足以继续支撑 “表达的出口”，是否可能只需一个案例就可颠覆经典， 还是需要通过修改 EAR 才能限制 “表达的出口”；四是一些技术救济方式，例如同步、镜像、分支等等是否可采、可行；五是是否还有更为有效的激发开源活力和提升安全的机制。
本文尝试对上述问题进行一些粗浅的分析， 以期深入业界对开源的长远思考和布局，繁荣开源发展。为了聚焦本意，本文不再严格区分自由软件等概念。
2 开源软件网络安全的法律问题 2.1 开源协议及其脆弱性
所谓的开源协议，实际上主要指包括开源软件在内的著作权许可协议，例如典型的 GNU General Public License 等。在许可协议中，通过将著作权法下规定的著作权人的发表权、署名权、修改权、复制权、发行权、传播权等权利按照《计算机软件保护条例》第 18 条 “许可他人行使软件著作权的，应当订立许可使用合同。许可使用合同中软件著作权人未明确许可的权利，被许可人不得行使” 等规定，进行部分或全部的让渡，吸纳和鼓励更多的人员参与软件开发与维护，如漏洞脆弱性发掘等。
因此在著作权法与合同法的民事法律中， 开源协议是合同各方当事人对权利义务不违反强制性法律规定的自行安排，其体现的是民事主体的意思自治。
但也正因为合同的意思自治和相对性等法律特性，导致开源协议具有某些可以类比为 “脆弱性” 的限制，这些限制主要体现在三个方面：
（1）协议本身可以通过协商、修订、补充等方式进行修改，乃至在不同的语种翻译过程中都可能导致语义变化，这也是为何在不同语言版本的协议中，需要设定以何种语言为准的原因（因此 GNU General Public License 的许可协议以英文为准，中文翻译仅供参考，这也不同于在国际公法中，多边或双边协议的多种语言等同适用 ）；
（2）违约责任的设置可能导致当事人在权衡各种可能责任之后做出主动或者 “恶意” 的违约，特别是可以终止许可，禁止开源分支等；
（3）从根本上，意思自治和相对性约束了开源协议仅对协议各方发生效力，其与开源软件进出口监管属于不同的法律部门。当发生国家安全、社会公众利益和个人（合同方）利益竞合时，就会产生事实上的法益冲突和优先劣后等问题。
因此，在回答 “开源协议是否抗辩出口监管” 的基本问题上，不应对开源协议施以过高要求或期待，这一诉求已经超过了开源社区所能承受的范围。例如 GNU 声明：有时某些政府的出口管制法规或者贸易制裁会限制您在国际上分发程序副本的自由。软件开发者没有能力消除这种限制或者凌驾于这些限制之上，但开发者可以且必须做的是拒绝将此种限制作为（用户） 使用程序的条件。如此，这些限制将不会影响这类政府管辖权之外的行为或行为人。
因此， 自由软件许可证不得要求用户遵守任何重要的出口法规作为先决条件来行使赋予用户的任何基本自由。然而，它仍然是一个潜在的问题：因为一旦出口法规在未来做出变化，就可能使某个限制变成重要的，从而无法实现我们期望的软件自由。当然对于开源社区而言，其所能作出的反应不仅限于开源协议本身。
2.2 开源的进出口监管 —— 以美国出口监管为例
在进出口监管法律的清单管理模式中，软件、技术、系统、设备、商品、组件和代码可以属于不同的物项（items）并予以不同的监管编码，因此尽管《计算机软件保护条例》规定 “同一计算机程序的源程序和目标程序为同一作品”，但从进出口监管视角，其所体现和承载的物项形式、内容、阶段、功能等均有不同， 进而也适用不同的进出口监管规则。
也正是基于软件和代码的分离，使得开源软件、开源代码能够作为分别的物项出口最终成为可能，使得开源代码本身可以作为 “言论自由” 表达的一种形式进入司法审视的范围（有关言论自由的相关案例及评价，见下文赘述）。
对于判断是否构成开源的 “可公开获取” 而言，还是以 EAR 对 Linux 基金会所关注的 “加密软件” 为例，就包括了可公开获取的大宗市场加密目标代码软件（Mass market encryption object code software）、履行了 EAR《控制策略 —— 基于 CCL 的控制》742.15 (b) 邮件通知义务的可公开获取的加密源码（encryption source code）、履行了 EAR《控制策略 —— 基于 CCL 的控制》742.15 (b) 邮件通知义务的可公开获取的加密目标代码（encryption object code，其相应的源码也符合前述 “可公开获取”）。
但是当代码、软件、系统在形式上统合于某一物项时，例如以开源软件，或者包括了开源软件的应用软件形式出口时，该物项将作为独立的物项进行 EAR 的适用性评估，而不能仅以其包括或宣称为可公开获取的源码（merely because it incorporates or calls to publicly available open source code）而认为其不适用 EAR 监管。
这也是 EAR 明确提出的监管原则，因此不能想当然地认为只要或主要为开源代码，即不适用 EAR 监管，还应当考虑其体现为的物项，以及所承载的介质（典型的如托管平台和离线介质）。
也正因如此，即使在开源协议中对适用法律和争议解决不作约定，都无法完全规避进出口监管中对开源主体（基金、平台等）适用属地的服务器主义（代码托管服务器）管辖权。开源协议难以做到与出口管制无关。
2.3 源码与言论自由表达的确认性问题
在对美国 1990 年代三大经典案例分析的基础上，一种观点认为 “从此之后，美国政府再也不能试图限制软件源码流通了”。
2.3.1PGP 案
PGP（Pretty Good Privacy）案件和对其作者 Philip Zimmermann 长达三年之久的调查为 1990 年代第一次 “密码战争”（crypto wars）时期的巅峰之作。最终司法部撤销了起诉而非败诉，因此也留下对美国第一修正案是否和多大程度上保护软件 / 代码作为一种言论自由表达的持续疑问。
这一诉讼不仅没有针对性的解决源码与言论自由表达的问题，事实上还最终导致了 1998 年之后 PGP 的分化（ 为基于 GNU 的 OpenPGP 和商业版）。2014 年开始，随着美国等国家的网络服务提供商开始监听和在邮件流量中移除 STARTTLS 标记，PGP 及其与它加密协议的关系和脆弱性也进一步得到发掘 —— 可出口的 PGP 反而可能成为监听的有效工具。
2.3.2Snuffle 案
伊利诺斯州立大学 Bernstein 副教授开发的 Snuffle 软件试图通过纸质期刊和网络发布，但政府要求其按照军火出口控制法的规定注册为 “军火商” 并取得出口许可证。
Bernstein 认为政府禁令违反了第一修正案。司法部作为被告认为如果 Bernstein 的软件通过计算机语言（源代码）表达，则不受第一修正案保护。1996 年和 1997 年（重申），法官 Patel 驳回了政府观点， “第一次” 明确计算机源代码属于受第一修正案保护的言论表达。
法院援引了 1971 年五角大楼文件案等判例后认为，Arms Export Control Act 和 EAR 的规定属于预先设定的言论限制，因为法案要求 Bernstein 在发表其言论之前申请并获得许可证属于事先审查机制，“仅以国家安全利益为由不应设定预先限制”，还应当至少考虑第一修正案相关案例所反复提及的威胁的直接性和紧迫性，并强调出口控制所限制自由表达的言论是基于言论的 “内容”，而非政府所认为的 “功能”。
对该案的正确解读应当包括：
（1）该案主要限制了 EAR 出口监管的事先审查机制，即以国家安全为由设定出口限制时，应符合直接性（必要性）、紧迫性（紧急性）的条件，并应给予当事方其他救济，因此属于个案裁决不能作为一般情形。
（2）尽管 1999 年 5 月第九巡回上诉法院维持了一审判决，明确 Bernstein 有权发布源代码，重述了 EAR 的违宪性，但并非一致通过，Nelson 法官发表了反对意见认为， Bernstein 必须事实上使用源代码（文本）进行讨论或教授密码学，只有在此情形下才是其科学方法和想法的表达。因此案例并非一致性无争议地裁决。
（3）尽管一审法院支持了 Bernstein，但该案持续长达 4 年之久，期间很多的密码技术发展受到影响，如服务器软件 Apache。事实上，政府的目的部分得到了实现。
2.3.3 荣格（Junger）案
凯斯西储大学法学（注意，实际上在法学教授的计算机法课程中披露和讨论的加密技术细节相对有限）教授 Junger 在克利夫兰联邦地方法院起诉政府（国务院，区别于第 2 个案子的司法部、NSA），认为对方限制其在计算机法课程教授密码学 —— 争议的焦点在于美国《国际武器贸易条例》（ITAR） 所定义的 “出口” 是否包括与外国人讨论非分级（non-classified） 的加密软件的技术信息，如注册 Junger 课程的外籍学生。该案有别于前两个案例的关注包括：
（1）1996 年 8 月，Junger 通过代理律师多次向法院申请临时禁令，要求禁止政府阻碍其与外国人讨论或发布一般加密信息，但被法院驳回；
（2）法院裁判中认为，加密软件源代码具有固有的功能属性，不能仅解释为表达加密理论或描述软件功能，加密软件主要用于实现加密功能，并与实施加密的计算机硬件紧密结合。
因此，尽管 2000 年中，第六巡回上诉法院维持了 ITAR 的限制规定应接受第一修正案审查的观点，但在 2000 年之后随着密码技术的发展和课程的更新，其效用性已经不能完全适用。
综合上述已经略显久远的案例，实际上不能得出 “从此之后，美国政府再也不能试图限制软件源码流通了” 的结论。
首先，前述案例并非最高法院案例，其论证和援引效力的权威程度并不足够；
其次，在案件分析中，核心焦点在于前置审查程序的有效性与否，这就导致了个案差异会导致不同结果的可能，特别是前述案例均更接近于美国 “内部矛盾”，而一旦涉及与别国争议，就进一步加大了裁决结果的不确定性；
再次，源码本身的 “双重属性”， 不同个案将会在软件的功能性与表达性之间摇摆，在未来可能只需一个相反案例就会导致对出口监管态度的 “重置”。
3 提升开源软件的网络安全价值建议 3.1 开源的市场和版权法价值
事实上，我们关注开源软件的协议安全， 正是开源软件对整体安全市场的价值体现。这就从根本上决定了开源可以通过协议适当规避商业软件市场和传统版权法的某些限制，从而给出了维护国家安全、社会公众利益和公民个人信息和隐私的多一重审视维度，也就决定了进出口监管职能也需要以例外的方式给予其适度的自由。
美 国 2018 年 国 防 预 算 法 案（National Defense Authorization Act for Fiscal Year 2018）明确规定，国防部长应启动 2016 年 8 月 OMB 备忘录（M-16-21）制订的为期三年的开源软件试点计划（open source software pilot program），其目标要求政府机构将至少 20% 的新定制开发的代码作为开源软件发布。①在该法案的语境下， 以减少重复的技术开发合同为理由显然只是其字面意思。
从版权法角度，即使抛开版权法保护软件的早期争议，目前以版权保护计算机软件也略显疲态和 “腐朽”。开源协议正是撕开了版权法保护计算机软件的一道裂口，以软件许可的约定形式转移了著作权人的部分财产，乃至人身权利（按照著作权法，发表权、署名权、修改权、保护作品完整权属于有人身依附性的人身权利），直接挑战了商业软件的垄断性利益。
也正是在这层意思下，开源软件的作者并不如开源管理者自由，后者才是真正的自由，可以规定开源协议的自由，可以引入审查和设定分支的自由，直至决定是否与商业软件竞争或是并购的自由。
从开源软件的发展看，确实经历着从早期的作为商业软件的补充与竞争，到更趋于 “开闭” 灵活和相互融合的艰难蜕变。特别是在云计算产业下，开源软件和开源社区的定位和发展面临重大挑战。
3.2 提升开源软件安全应避免的误区
在 2018 年 12 月的第九届中国信息安全法律大会上，我们提出开源的安全不仅是从物理层到应用层的协议安全，还包括法律协议的安全。开源代码和开源协议都需要通过某种形式的审核或审查，并在所受限的软件市场、版权法和进出口监管下 “辗转腾挪”，通过特定的制度建设与安排，方能逐步、渐进地提升安全。
3.2.1 为何有的开源项目关停而有的繁荣
以 GitHub 为例，其上也存有大量停止开发维护的项目，除了项目本身的技术和需求之外， 代码审查和闭源被认为是部分项目消亡的原因。例如早期的据称 2013 年约翰霍普金斯大学的 Matthew Green 教授组织了对 TrueCrypt 的安全审计，得出的不安全结论部分导致了开发者退出。毫无疑问，尽管有别于中国《网络安全法》（或美国类似等同的审查机制）等下的国家安全审查，第三方的额外（从开源初衷而言，开源软件的社区模式自带审视）审查机制限制了开源的某些自由，抑制了（或加速了）市场自身的优胜劣汰。另外，云计算厂商与开源社区的合作模式也极具争议。
基于上述分析，实际上得出了一个提升开源软件安全的适度性结论，即对于开源软件而言，应审慎引入代码审查机制，并应严格限制国家安全审查的适用性。
但如此一来，则与《网络安全法》第 35 条规定的 “关键信息基础设施的运营者采购网络产品和服务，可能影响国家安全的，应当通过国家网信部门会同国务院有关部门组织的国家安全审查” 发生冲突，从而可能导致要么将开源软件限制在关键信息基础设施领域之外，要么因国家安全审查而抑制了开源软件的研发。
3.2.2 同步备份和设立分支为何不能解决发展和安全问题
对于托管在境外服务器（如 GitHub）上的开源代码，是否作为分发（对应于版权法的发行权）平台还是只作为备份镜像（对应于版权法的传播权），进一步而言是否考虑在现有的开源软件之上设立分支，本质上应作为技术问题处理而不应作为应对进出口监管的终极解决思路。
以强行引入的外部机制将可能导致开源项目的萧条直至关停，因为其违背了开源社区发展的弱中心化而非去中心化的规律，而承认分支的存在即意味着可以向上回溯。更何况， 分支实际在很大程度上是作为开源协议冲突的安排，并不直接与发展和安全有关。例如 2018 年 11 月，自由软件基金会（FSF）更新软件许可证评论认为，如果既有项目增加了禁止商业性使用的商业条款（Commons Clause），应当重新设立分支。
3.3 提升开源软件安全与繁荣的着力点
3.3.1 从维护现有开源项目开始
无论是本文引述的 Linux 基金会的开源项目，还是境内企业已经广泛参与和贡献的开源社区，在提供代码输出的同时，也应当对其所适用的开源协议给予适当的关注。
正如本文认为的开源安全不仅是从物理层到应用层的协议安全，还包括法律协议安全所言，开源协议的安全不仅涉及各类许可证条款的差异，也包括不同许可证混用的冲突，还包括在商业化应用中对传统版权法著作权人权利的 “逆转” 和 “强化”， 即对开源协议的关注和争议不应停留在 divx 和 xvid 的协议转换，而需从微软收购 GitHub 的市场和产业高度重新审视。
应当借鉴 FSF “评论” 的软件许可证的做法，给予开源软件多一重维度关注，不仅聚焦在源码本身，也注重代码的 “外围” 和 “周边”。
3.3.2 与《网络安全法》若干问题的协调
目前开源软件与《网络安全法》体系的协调可能包括以下问题：
（1）按照《网络安全法》第 22 条，网络产品、服务的提供者应当为其产品、服务持续提供安全维护；在规定或者当事人约定的期限内， 不得终止提供安全维护。对于开源软件产品或服务而言（按照著作权法和计算机软件保护条例，对开源软件产品或服务的认定应基于产品或服务的 “完成”），如果直接关停或设立分支，可能构成对该条的违反，但如果按照该条规定也不符合开源软件的发展规律，同时也可能导致对开源社区追责的 “落空”。
因此应考虑在开源协议中设计与该条有关的内容，特别是完善开源协议的权利义务转让、第三方承受维护机制等，以促成开源软件的完成与发行，减少不必要的分支和碎片化。
（2）在开源软件的全球参与下，开源社区的协同必然产生数据出境的问题，按照《网络安全法》和热议中的数据安全管理办法、重要数据出境安全评估办法所规定的以网络运营者为主要责任方，以合同审查（数据出境安全评估审核）为制度设计的安全模式下，源码的出入境应当作为协议安全的特殊情形予以充分的论证和除外规定，否则可能无法满足开源软件的宽松研发模式。
（3）至于《网络安全法》第 22 条规定的 “网络产品、服务应当符合相关国家标准的强制性要求。网络产品、服务的提供者不得设置恶意程序；发现其网络产品、服务存在安全缺陷、漏洞等风险时，应当立即采取补救措施， 按照规定及时告知用户并向有关主管部门报告”，第 35 条规定的 “关键信息基础设施的运营者采购网络产品和服务， 可能影响国家安全的，应当通过国家网信部门会同国务院有关部门组织的国家安全审查” 和目前热议的网络安全漏洞管理规定，必要和适度的代码审查是网络安全等级保护和关键信息基础设施保护的必要组成，其实现的重要路径即是代码审查。
对于代码审查，可以认为其一方面受到了开源的启发和影响，另一方面审查也会抑制和终止某些开源项目的持续。同时《网络安全法》的规定会增加开源社区审核、审计开源安全的义务和成本， 因此也需要在脆弱性与漏洞管理中，对开源软件作为一种特殊类型进行制度和协议设计，并特别限定国家安全审查的适用范围，充分评估审查对开源软件的影响。
4 结论 开源软件作为传统版权法规定下的代码分离与等同的必然产物，其制度设计在于解决类似 “多场耦合” 问题从而直接在软件开发者（作者）与著作权之间建立关联，与传统版权法的规定相比，具有某些天然的外部性和自适应优势，特别是第五代移动通信技术的发展可能再次提升开源软件的应用，各国均对开源软件予以高度重视和密切关注。
整体而言，从开源软件的协议安全（并促进繁荣）角度，至少应当从以下几个方面进行综合考虑：
（1）在版权法下设计软件权益机制，体现开源属性权利的独立性；
（2）从服务协议、许可协议等视角规范开源软件的合同法下规范；
（3）协调进出口监管法与版权法，规范审查和评估对开源的影响；
（4）从网络安全法的基本法出发，将其作为一类特殊的安全审查和出境评估类型。
最后，开源的核心在于软件开发者的著作权利义务设计与分配，应从宏观与微观上给予开源软件开发以充分支援。这些支援不在于简单的资金投入或文件指引，而在于通过降低人员流动的成本，并特别注重未被定义为高端人才的人员价值和促进开源繁荣的作用，以开源代码和开源协议的参与度作为评价开源安全与繁荣的主要机制。
二、实务指导
1、如何选择开源许可证？
如何为代码选择开源许可证，这是一个问题。
乌克兰程序员Paul Bagwell，画了一张分析图，说明应该怎么选择。这是我见过的最简单的讲解，只用两分钟，你就能搞清楚这六种许可证之间的最大区别。
下面是我制作的中文版，请点击看大图。
2、《开源软件知识产权风险防控研究报告》
中国信息通信研究院知识产权中心副主任 毕春丽：开源软件知识产权风险防控
非常高兴有这个机会跟大家一起分享关于知识产权风险内容。
这次分享的时间点对于今年来说也是意义非常重大，因为今年出现了一些非常有影响力的事件，在事件出现以后，大家都在想开源到底是否风险很大，它的风险会给使用开源软件的企业带来什么样的影响？在很多群里大家都在讨论，而且这些问题到底是什么样的，我今天从知识产权角度，从一些简单的案例来逐渐进行剖析它的一些知识产权的问题，还有我们作为开源应用的企业如何关注它的风险，从哪些角度进行关注。
今天演讲的内容是围绕三方面：
一、开源软件知识产权相关案例分析
二、开源软件知识产权风险
三、企业开源知识产权风险防控建议
我们在进行开源发生一些纠纷、发生一些问题时，一旦上升到法院角度时，有时候大家不知道到底用合同法还是用著作权法。如没有遵守开源协议，是否可以用合同法？侵权代码和源代码之间关系是否可以用著作权法呢？现在在很多法院、业界当中也是关注的一个问题，即应该用什么样的法律进行规制，因为不同的法律制约原告、被告进行侵权举证或进行自己本身防御举证时的路径和思路完全不一样，这是需要特别关注的一个问题。
案例，ARTIFEX诉HANCOM
这个软件本身是用于PDF可描述的编译软件，很多操作系统里都可以适用。这个软件是双许可证，既可以用开源的许可证，AGPLv3.0版本进行开源，还可以用商业许可证，也就是可以直接购买它的商业服务的许可证。这个软件本身是由ARTIFEX公司所拥有，在这个事件当中，HANCOM是一个韩国公司，在出售office软件当中同时搭载了ARTIFEX所研发的工具。在进行下载使用这个工具时，因为有两个许可证，一是没有要求购买商业软件的服务或没有花这个钱购买这个软件，二是没有按照开源许可协议要求进行修改的代码回馈给社区，ARTIFEX就控告HANCOM，希望把以前损害赔偿进行上诉。这个案件就是非常简单的不遵守开源许可协议。
我讲的重点是中间适用法律问题。在ARTIFEX提出两项指控：1.侵犯版权，因为没有购买我的商业许可证，也就是说这个版权是在我这里，你侵犯了我的版权；2.没有购买我的商业许可证，默认是使用开源许可证的软件，这个软件需要按照开源许可证GPL要求来做，但没有按照它的要求来做，所以构成违约或构成违反合同。这里指出控告既有版权内容，又有合同内容。
如何进行反驳？这个反驳非常有意思，1.认为在进行下载软件时没有切除任何东西，按照合同法约定，进行下载时没有人让我签署这个内容，没有承诺任何相关条款，不构成一个合同。2.在美国联邦版权法是优先于合同索赔，这里主要涉及到2008年的一个案例，在那个案例里，法官第一审按照合同法进行判，原告一直希望通过版权进行诉讼，二审最后结果是按照版权赔偿来结案的，所以得出结论：联邦版权法优先于合同法。
3.通过这两条，第二条不成立。被告发生侵权所在地不在美国，知识产权法是有地域性的，不管是版权、专利、商标都有地域性，正是因为在美国控告，但美国管不着我，版权法只能管在美国发生的侵权行为，所以版权也无法进行规制我，所以用这三条进行反驳原告一些指控。
最后法官认为如果用户没有得到商业许可证的同时，默认构成合同法的约束。所以最后这个案子结论是开源许可协议可以作为有约束力的合同，这也是开辟了我们后面对开源许可协议的看法。
这个案件对我们的启示：开源软件不是公有软件，不等同于免费软件，不意味着可以任意使用。网站上可以随意下载的软件，明确说是开源的话，一定要注意不是一个公有软件，这个案子里认为是公有软件，也有可能是一个故意行为。公有软件明确放弃一些版权或放弃对于这些版权经济上的回馈，但开源软件这些东西没有完全放弃，要遵循开源许可协议的一些要求。同时不等于免费软件，是需要有一些前提条件遵守开源协议。我们在使用开源软件时，一定要遵循开源协议，这个协议已经达成一个自动的合同，就要遵守合同里一些约定。
案例：MangoDB变更开源许可协议
MangoDB在很多云计算、云服务中用到很多数据库的内容，在整个查询功能里非常强大，很多互联网厂商也使用MangoDB来做数据库的服务功能。
MangoDB也是使用两个版本：1.开源版本。2.企业版本。这个事件是2018年10月16号之前使用的是AGPL条款，之后使用SSPL，翻译成中文就是属于服务器端公共许可证，也就是说明确说了许可证修改主要内容或方向将来要约束服务器端公共许可的内容。这个事件缘由和中国厂商也有一些关系。
有一个问题，开源许可协议是否能够随意更改？大家讲开源治理时，首先选择开源软件时要考察开源许可协议，考察完之后，忽然某一天又变了，这种风险如何进行考虑？
首先要清楚哪些类型的开源许可协议可以进行更改，就像MangoDB一样是一个企业主导，而且所有软件权利都归自己一家所有，是有权利进行更改许可协议的，还有可以进行闭源。还有一些是要根据开源许可协议社区的规定或基金会规定，首先看权利都在谁手里，再进行更改协议时也需要权利人或相关人一起同意后才能更改协议。大家要观察企业开源许可协议控制权都在谁手里。
现有这些更换许可协议的事件还是在整个开源发展过程中比较频繁的，所以大家在考虑开源风险、开源治理过程中也是需要关注的一个问题。
MangoDB开源许可协议到底更改了哪些内容？
AGPL就是一个传染性非常强的许可协议，更改的主要是第13条，更改内容具体是细化的里面一些具体对象和服务内容。如果将本程序或修改版本的功能作为服务提供给第三方，根据本许可协议规定，必须通过网络下载方式免费向所有人提供服务源代码。首先服务给第三方内容是什么，什么样的第三方包括在这个服务里，对原来AGPL网络交互内容进行细化；对服务源代码进行更具体详细的定义，对源代码所涉及的程序，如涉及一些管理软件、用户界面等，这些服务也都是需要遵守开源需要的。
接下来详细介绍为什么要从AGPL修改成SSPL的许可协议内容。这里最重要的内容就是因为我们在进行整个开源许可协议选择和大家在使用过程中还是要有一个遵守规则的意识。更改协议时，当时CEO发布的新闻，第一，是为了对竞争对手进行打击；第二，为了维护自己软件盈利的可能性。
这个事件出来以后，对开源社区一般使用者到底有没有风险，我们对整个开源社区来说，整个使用MangoDB的用户来说，仍然可以自由地使用、审查、修改、再发布源代码等等。这里影响最大的是云服务商，云服务商在进行使用过程中只有这两种选择，要么公开源代码，要么购买MangoDB的商业版本。
这个事件就是更改开源许可协议的事件，但这个协议给予我们的启示很重要，首先大家要理解开源的游戏规则，就是一个软件代码或一个稍微成熟的大家都能接受的软件背后会付出很多劳动，不仅是开发员、程序员的劳动，还有涉及到开源社区的管理等等。这么多劳动很多不是纯粹的义务劳动，大家要有逐利的可能性，在这里要进行斟酌，不可能完全免费得到自己的利益，我们理解了它，就会选择开源软件应用自己产品过程中谨慎选择哪些可以用，哪些不可以用。
开源软件知识产权风险。
包括版权、专利、商标、商业秘密，从涉及到的开源许可协议里，讲的比较多的是版权的内容，这里还会涉及到第三方版权瑕疵，不经意间会流入到开源软件过程当中的风险。
这个专利有时候是防不胜防的东西，根据你所选择的开源协议、所选择的开源社区也有很大的关系，有可能会进行规避。其风险来自于内部的，根据开源社区做的过程中申请一些专利，外部是不受约束的第三方申请专利可能会受到将来索取权利的收费等风险。尤其大家在自己进行开源过程中也需要特别注意，把自己代码开放之前还是要注意先把代码相关内容如果能转化成专利，先转化成专利，然后再去开源，这些也是大家在开源过程中需要特别注意的。
商标也存在一些风险，使用未授权商标，如开源许可协议没有经OSI认证，不按开源许可规定，不该进行公开或披露的一些商标、商号在开源代码里体现进行宣传等等。
开源知识产权风险分析无外乎就三个维度，这三个维度来源于最基础的开源生态里的三个方面：
开源协议。在构建开源整个过程中的基本规则。商业运营模式，商业运营模式不同带来资产风险也不同，比如就做科研研究，就做内部研究，不进行对外商业，可能风险就很小或没有。但如果一旦进行商业化使用时，这里风险性可能就比较大。
开源社区管理。有些开源许可协议本身规定没那么多，有些开源社区希望把开源内容进行扩大化或进行更广泛的使用，它自己会做一些更详细的规定。
影响因素之一：开源许可协议
举例，开源许可协议版权专利商标和其他规避内容，从强传染性到弱传染性开源许可协议的内容中，强传染性GPL风险就很大呢？这和商业规模有一定关系，MangoDB等这些软件代码在一家公司或几家比较大的权利人所拥有时，可能为了保证整个软件一致性，选择GPL更多一些，一般选择双证的软件使用GPL也比较多一些，是为了更多卖商业的软件。给了强传染性，也给了其他知识产权的保证。BSD，用商业化软件是比较多的，但是专利、版权、商标都没有规定，相当于风险性非常大，因为不知道哪一天就会有人告你，所以大家使用时是一个辩证角度来看待这个问题。
影响因素之二：开源软件使用方式
是否访问源代码，如果不访问源代码，仅仅观看的话，风险很小。如果访问源代码，是否要进行修改？如果进行修改，还要考虑是否要进行传播，进行传播的话，将其原封不动或仅仅是将部分或修改一部分内容进行发布的话，这里也有很大风险的。进行商业化使用过程中，其风险性是我们需要着重进行考虑的。
这里还加上一条：是否对外提供服务。就牵涉到MangoDB的问题，要对它提供一些服务，这些也是需要考虑他的许可协议的规定。
影响因素之三：开源社区知识产权规定
除了开源许可协议知识产权规定以外，也会进行额外知识产权的规定，比如在Apache里，额外要求贡献者必须提交贡献者协议，贡献者协议目的是要保障提供进来的代码是纯洁的，不受侵权困扰的代码。在商标规定里也进行细化的内容，哪些可以使用，哪些不可以使用。这些开源社区的规定我们也在开源进行治理过程中需要着重看的一些内容。
开源知识产权风险大的框架从三个维度来看，一些比较细的内容还是需要我们根据自己商业用途和使用情况来进行选择。
建议。
要增强风险防范意识。
我们在调研过程中发现一些比较小的软件公司认为既然已经开源了，就没有任何风险或风险性很小。当然现在发生的这些纠纷，尤其在中国发生的纠纷还比较少，但并不排除这里就没有相关风险。当然我们也不要进行无谓扩大，现在80%以上的纠纷案例都会进行私底下的和解，所以我们要正确看待开源的知识产权风险。还要加强风险意识，不仅是知识产权的管理人员，更重要的是技术开发人员、管理者的风险意识。
进行风险防控体系里需要战略协同，我们要和产品、策略、成本控制等策略进行协同。还有部门之间进行协同，需要法务、技术、采购等多个部门一起协作，共同配合来工作。
在建立开源软件风险防控全流程管理体系里，从开源软件引入、开源软件开发、开源产品发布，都要按照流程来做，这些内容都需要大家在进行开源管理中注意的一些点。
企业开源进行风险防控内容中离不开法务工作者的工作，首先在准确解读开源许可协议规则里，因为很多开源许可协议都是英文版非常晦涩的法律术语，往往一个开源许可协议规定以后，后面有时候弄不清楚到底讲的是什么内容，就要看它的问答内容，而且有些内容需要结合技术术语、法律术语一起来理解，所以需要专门人员来做。
跟踪一些开源相关司法案例，了解现有法官或不同国家对开源的理解，如我们国家能否用合同法，在版权法里如何进行使用的。对于这些案件大家都要及时跟踪、及时了解。
风险防控建议，从意识体系到开源防控全流程管理到最后研究工作，我们也在做很多工作，已经和一些企业做相关服务，大家如果有相关问题的话，也可以和我们联系，大家一起进行解决。
勘误《开源软件知识产权风险防控研究报告》
中国信息通信研究院（以下简称信通院）是工业和信息化部直属科研事业单位，定位于“国家高端专业智库”，对信息科技行业的发展起到了重要的作用。在开源方面，信通院不定期地发布相关白皮书，较好地引领了相关产业对于开源的认识和实践。 对比中美两国开源产业的现状，可以发现美国有较多的律所和律师参与到该产业当中。但是在中国，较多的研究和法律建议是由非律师做出的，由此也能看出我国开源产业的发展较为滞后。背后的一大原因可能在于美国的律师与客户之间对涉及法律事项的讨论是受到特权（privilege）保护的，在诉讼、仲裁等的开示（discovery）程序中可以免于向审判庭披露。律师的这种特权较为特殊，也有一些群体（例如注册会计师、医师）试图获得此项特权，但是从未成功过。而中国的审判中没有开示程序，也就不需要相关的特权保护。由此导致中国的律师作用受限，非律师也可以给出法律意见。 信通院2019年版的《开源软件知识产权风险防控研究报告》（以下简称报告）对于开源软件的知识产权法律风险进行了较为全面的梳理和提示，具有较高的参考价值。但是百密一疏，由于其中法律方面的错误近来经常被问到，因此在本文中总结如下。 1. open source并非注册商标 在2019版的报告中，有多处（例如第3页、第26页）指出open source是注册商标，但实际上并非如此。open source在软件相关的类别中，无论在中国还是美国都不是注册商标，因此并不存在文中所述的商标侵权风险。同样，在中国，汉字的“开源”在软件相关的类别中也不是注册商标，因此在软件领域使用汉字的“开源”也是安全的。虽然汉字的“开源”在其他类别中可能是注册商标，但在软件产业中使用“开源”的风险较小。 在软件领域将“open source”或者“开源”注册为商标的最大障碍在于“open source”或者“开源”是一个描述性词汇，不具有显著性，也不可能因为使用而获得第二含义。至于为何“开源”可以在其他类别注册为商标，就好比不能在水果类的产品注册“苹果”商标，但是可以计算机类的产品注册“苹果”商标。 2019版的报告将open source视作是OSI的注册商标，但是在OSI的商标策略（https://opensource.org/trademark-guidelines）中，只提到了OSI（在美国）拥有的3件商标：OSI、Open Source Initiative以及OSI标识。 2.关于著作人身权与财产权 在2019版的报告中对于著作人身权的表述有些混乱，例如在第8页的（三）1.第1段记载了“人身权包括署名权、发表权、保护作品完整权和修改权”；而在第9页第1行又记载了“复制权、修改权等财产性权利”。 实际上，之所以开源许可证不包括人身权是因为：几乎所有的许可证都是美国人基于美国版权法撰写的，而美国版权法又不承认著作权人身权。英美法系的版权法追求的只是对经济权利的保护，而非作者的人身权利——虽然作者可以寻求反不正当竞争法进行保护。不同于大陆法系认同著作人身权的观点，英美法系的传统观点为：著作人身权不独立于财产权，是财产归属的标记。只不过是美国在加入《伯尔尼公约》后，为了执行《伯尔尼公约》才在1990年制定了《视觉艺术家权利法》，对于部分作品规定了一些有限的人身权（表明身份权、保护完整权）。 3.许可证的法律效力 在大陆法系下（我国、德国），许可证构成双方的许可合同几乎没有争议。但是在美国法系下，许可证是构成双方的合同还是单方的许可仍然存在争议。在Artifex v. Hancom案中，法院认为根据加州法律GPL v3许可证构成许可合同，不宜推而广之认为许可证在美国法下就是当然的合同。
3、人工智能开源生态和知识产权研究（2021）报告解读
“开源创新与人工智能”专题论坛上，中国信通院知识产权中心高级工程师李国红对《人工智能开源生态和知识产权报告》进行了解读。
李国红从人工智能开源生态的现状出发，引申出推动人工智能开源的重要意义及巨大价值，并对如何构建开放创新的人工智能开源生态体系进行了讲解。然后从人工智能开源所要面临的知识产权和法律风险出发，结合知识产权对开源平台支撑的深度分析，就如何推动知识产权合规保障开源生态健康发展提出了一系列建议，特别是要建设和完善开源知识产权和法律体系。
更多精彩，敬请阅读解读PPT。
知识产权“托底”，开源生态更安全
目前人工智能开源生态可能面临的知识产权风险涉及专利、著作权、商标等多个领域。其中，专利风险主要表现为开源软件的贡献者向开源使用者发起专利诉讼和第三方向开源软件使用者发起专利诉讼等方面；著作权风险主要涉及版权瑕疵，即相关代码使用者将自己不具有版权的代码贡献到开源社区，而绝大多数的开源许可协议有“不担保”条款，因此，由上述情形引发的版权侵权责任需要贡献者自行承担。此外，绝大部分开源许可协议都不包括商标授权，有些许可协议则明确规定不得任意使用商标，若冒然使用他人在先注册商标则将有可能构成商标侵权。
中国信息通信研究院知识产权中心发布的《人工智能开源生态和知识产权报告（2021）》（下称《报告》）指出，开源参与者可通过知识产权合规化解上述风险。具体而言，可加强国内开源企业和贡献者对开源许可证的规范认知，同时加强产业链参与者对于各类型许可证的理解，正确使用许可证，遵守许可证义务。此外，《报告》建议，相关企业应加强开源合规管理组织建设，建立健全完备的开源软件规章制度并加强开源软件管理流程建设，设置开源软件管理部门，如成立开源管理办公室，设立开源项目管理委员会等，最大程度化解知识产权侵权风险。
在近日举办的“开源创新与人工智能”专题论坛上，百度公司分享了其以知识产权激励开源创新的经验。其于2009年首次大规模部署开源软件“Hadoop”，2016年其深度学习平台“飞桨”正式对外开源，2017年“Apollo自动驾驶”对外开源，2021年百度公司加入开源创新联合体……“百度公司开源快速、顺利推进的背后，离不开积极构建科学合理的企业开源合规体系，成立开源办公室，下设开源法律及安全组进行开源项目管理，定期更新知识产权合规案例等措施的助力。”百度公司专利事务部总经理崔玲玲介绍。
在开源软件专利布局方面，百度公司积极强化基础、核心关键技术层面专利布局，以专利提升企业竞争力。在开源软件专利的运用方面，百度公司优先选择具有明确专利授权条款的开源协议，并按照开源协议进行专利许可，以专利保护开源生态，为应对第三方专利主张增加“砝码”……“百度公司实践证明，重视知识产权，有利于促进开源生态良性发展。”崔玲玲表示。
社区推动融合创新
“开源并不意味着完全免费、无偿使用，参与各方必须重视在使用过程中的法律风险，以及国家间围绕开源社区的竞争行为。同时，开源社区虽在部分理念上与传统知识产权观念有一定冲突，但在行动上寻求包括著作权法、商标法、专利法、商业秘密在内的综合保护，是知识产权螺旋式升级保护的高级应用。”在北京大学法学院教授张平看来，开源知识产权政策经历了从批判到兼容再到利用的过程。
南京理工大学知识产权创新研究院院长戚湧指出，我国存在缺乏具有影响力的开源代码贡献者、开源参与者及使用者缺乏知识产权意识、行业知识产权托管较难等问题。对此，他从开源贡献者、开源项目、开源基金会、开源主体结构以及政府等角度给出完善开源数字创新社区知识产权治理的一系列举措。在他看来，开源生态领域应开展开源层级服务，形成开源需求与能力的匹配与适应机制；完善开源软件许可证制度，规范开源参与者操作行为；探索建立开源领域非传统著作权制度，净化虚拟网络交流平台；建立共享专利数据库，进行严格的专利审核；推进区块链技术与知识产权融合，促进开源数字创新社区全链条高质量发展；增设开源基金会，形成中国开源知识产权自治方案以及加大政府扶持力度，培育更多开源创新主体。
针对开源社区的良性发展，中国人民大学未来法治研究院执行院长张吉豫呼吁，人工智能开源社区发展需对相关专利加强关注。对于自身发起或参与组织的开源社区，应在认真考虑发展模式和需要的基础上，选择恰当的专利政策，设计许可协议。此外，为鼓励更广大创新群体参与，人工智能开源社区可考虑采取更加商业友好型的专利政策，也可通过社区导向及专利激励，推进符合伦理的开源技术创新。
随着开源生态的不断发展，除人工智能产业，开源中的知识产权元素还将影响和赋能更多信息技术产业发展，值得业内持续关注。
4、开源网安谈“软件供应链安全的现状与对策”
编辑
演讲摘要
1、开源组件的使用现状：开源组件在现代应用中的占比达到90%，2020年全球开发者累计请求下载开源组件和容器的数量超过1.5万亿个，企业平均每年下载开源组件超过37万次。开源组件已经成为当今软件应用程序中不可或缺的一部分。
2、开源组件的安全现状：在开源组件数十亿次的下载中，有10.4%存在至少1个已知漏洞，平均每个应用程序存在38个已知开源组件漏洞，近40%的npm包依赖于具有已知漏洞的代码。开源软件面临的最大威胁，是针对开源软件供应链的攻击，据了解，这一类型的攻击数量在2020年增长了430%，而且还在持续升高。
3、我国软件产业蓬勃发展：工信部公开数据显示，我国软件业务收入保持了较快增长。2020年，全国软件和信息技术服务业规模以上企业超过4万家，累计完成软件业务收入81616亿元，同比增长13.3%，全国软件和信息技术服务业从业人数超过704万。
4、软件安全态势令人担忧：截止到2021年6月，CNVD（国家信息安全漏洞共享平台）已收录的各类安全漏洞信息超过15万条，超过91%的安全漏洞发生在各类应用软件本身。企业使用开源软件面临的主要风险包括：安全漏洞、许可合规、政治环境因素等。
安全漏洞引发的风险案例
2017年美国征信巨头Equifax公司，因Apache Struts组件存在安全漏洞（CVE-2017-5638）未及时修复，被黑客攻击导致1.4亿人个人信息泄露，时任CEO Richard Smith辞职，赔偿4.25亿美元。
许可不合规引发的风险案例1
Oracle索赔Google 88亿美元事件，此案例的背景是，在Google供职的一个程序员，直接从OpenJDK复制了9行代码到Google的Android项目中，但是Android项目没有按GPL兼容的方式授权，而OpenJDK项目的著作权属于Oracle，因此触犯了Oracle的著作权。
许可不合规引发的风险案例2
中国GPL专利诉讼第一案——2019年11月6日，数字天堂诉柚子科技侵犯计算机软件著作权纠纷一案，由北京市高级人民法院做出二审终审判决，认定APICloud软件复制并修改HBuilder软件中的三个插件的行为，构成对数字天堂公司复制权、改编权及信息网络传播权的侵犯，判令柚子公司停止侵权并赔偿71万元人民币。
政治环境因素引发的风险案例1
2020年12月，全球最著名的网络安全管理软件供应商SolarWinds，遭遇国家级APT团队高度复杂的供应链攻击并植入木马后门，导致美国9家联邦机构和多家企业客户全部受到影响，成为年度最严重的软件供应链安全事件。2021年5月，美国总统拜登签署“加强国家网络安全的行政命令”，明确提出要增强美国联邦政府的软件供应链安全。
政治环境因素引发的风险案例2
2020年8月13日起，DockerEE和DockerHub禁止被美国政府列入贸易管制“实体清单”的企业使用；2020年12月，红帽公司宣布将于2021年底停止维护CentOS 8等。
5、我国国家层面网络安全战略：国家十四五规划提出，要打造数字经济新优势，加快推动数字产业化；营造良好数字生态，加强网络安全保护；加强国家安全体系和能力建设，健全国家安全审查和监督制度，全面加强网络安全保障体系和能力建设。
6、等保2.0（信息安全技术网络安全等级保护基本要求，2019年5月10日发布），对自行软件开发、外包软件开发的软件开发安全均提出了具体要求。
对自行软件开发的要求：
二级
a)应将开发环境与实际运行环境物理分开，测试数据和测试结果受到控制；
b)应在软件开发过程中对安全性进行测试，在软件安装前可能存在的恶意代码进行检测。
三级、四级
a)应将开发环境与实际运行环境物理分开，测试数据和测试结果受到控制；
b)应制定软件开发管理制度，明确说明开发过程的控制方法和人员行为准则；
c)应制定代码编写安全规范，要求开发人员参照规范编写代码；
d)应具备软件设计的相关文档和使用指南，并对文档使用进行控制；
e)应保证在软件开发过程中对安全性进行测试，在软件安装前可能存在的恶意代码进行检测；
f)应对程序资源库的修改、更新、发布进行授权和批准，并严格进行版本控制；
g)应保证开发人员为专职人员，开发人员的开发活动受到控制、监视和审查。
对外包软件开发的要求：
二级
应在软件交付前检测其中可能存在的恶意代码；
应保证开发单位提供软件设计文档和使用指南。
三级、四级
应在软件交付前检测其中可能存在的恶意代码；
应保证开发单位提供软件设计文档和使用指南；
应保证开发单位提供软件源代码，并审查软件中可能存在的后门和隐藏信道。
7、企业如何应对：企业可以采取“管理先行+技术并重”的双轮驱动模式，建立软件供应链安全管理制度，引入S-SDLC安全开发生命周期管理流程，采用专业工具和服务实现对软件产品的代码审查和缺陷检测。
建立软件供应链安全管理制度
1、制定差异化的软件分类引入和处置标准
2、落实软件管理职责分工
3、建立从“准入→上线→版本管理→运维→质量评估→下线”全生命周期的管理流程
4、加强软件供应链的安全审查力度
引入S-SDLC安全开发生命周期管理流程
S-SDLC（Secure Software Development Lifecycle），是安全软件开发生命周期，是一套完整的，面向Web和APP开发厂商的安全工程方法。S-SDLC定义了安全软件开发的流程，以及软件开发各个阶段需要进行的安全活动，包括活动指南，工具、模板等。目的是帮助软件企业降低安全风险，提升软件安全质量。
5、浅谈开源软件
案例一
天津市网城天创科技有限责任公司、天津市网城科技股份有限公司研发了ShopNC电商门户系统软件、【B2B2C】模式电商平台系统v1.0并办理了计算机软件登记证书。2016年，两公司发现浙江阿凡提电子商务有限公司在其运营的http://www.aft.sc网站上非法使用了其依法享有著作权的ShopNC电商系统系列计算机软件，遂以侵害计算机软件著作权为由将阿凡提公司诉至浙江省宁波市鄞州区人民法院。
被告阿凡提公司认为：
一、被告使用的电商软件平台没有复制使用ShopNC软件。
1、被告使用的电商软件平台是由被告的股东浙江商帮科技有限公司组织技术人员为其编写的软件。计算机软件保护条例保护的是计算机程序代码，而不是程序代码运行后产生的结果，虽然被告电商平台软件在编写的时候参考了包括ShopNC软件在内的其他电商平台页面的栏目、样式、外观要素等，但是此种页面近似不会构成计算机软件著作权侵权。
2、在参考学习ShopNC软件设计思想和原理时，有少量被告电商平台软件并没有使用的ShopNC软件功能（例如圈子功能）模块代码和一些标题素材等存储在了被告的服务器中。依照计算机软件保护条例第十七条的规定，存储这些并未使用的软件代码可以不经著作权人同意也无需支付报酬。
3、原告主张ShopNC电商平台软件著作权的，应当提供原告向国家版权局进行计算机软件著作权登记时交存的鉴别材料，并以该鉴别材料所载明的程序代码或文档作为著作权登记证书所记载的计算机软件著作权权利的范围。
二、原告的ShopNC软件系使用开源代码编写，原告不能禁止他人使用也不能要求他人向原告支付报酬：原告的ShopNC软件系采用PHP+MYSQL软件编写，PHP和MYSQL软件均属于开源软件，使用开源软件编写的ShopNC软件作者具有署名权，但不能禁止其他方改编、使用、复制、发表该软件，也不得向其他方收取软件使用费用。
案例二
不乱买电子商务（北京）有限公司自主开发旗下网站“不乱买”（http://www.buluanmai.com）。该网站是全中文海淘搜索引擎，2014年8月上线。2016年，不乱买公司发现北京闪亮时尚信息技术有限公司旗下网站“闪亮时刻 （http://www.blinghour.com）同为海淘搜索引擎，其网站设计、布局源代码均与自己的网站实质性相同，同样以侵害计算机软件著作权为由将闪亮公司起诉至北京知识产权法院。
被告闪亮时尚公司答辩称：
一、原告在证据中所提供的代码并非其原创或率先使用，原告对其所举证的代码无权主张权利。
1、原告未能证明其著作权登记的软件内容与其提交的软件是否一致，且其在网站停止运营后的近2个月，被告网站上线后1个月相继申请软件著作权登记及公证代码。
2、原告提供给法院用来比对软件代码，未提供开发过程文件及代码来源。
3、原告提供的代码中存在大量开源文件、第三方版权文件及大量在原告2014年成立之前的版权信息。
二、原告使用了适用于GPLv2软件许可协议下的开源代码，根据协议相关内容，原告无权对其网站整个软件著作权等相关版权主张权利，GPLv2软件许可协议明确规定，只要软件在整体上或某个部分使用了来源于遵循GPL代码的文件，整个软件源码就必须无偿向所有第三方提供公开整套软件的源代码，无论前端代码还是后端代码等。
从上述两个案例中可以看到一个共同的特征就是涉案软件的侵权纠纷中都涉及到了开源软件问题。
那么，什么是开源软件呢？早在上世纪90年代初的时候，在大学课本或书店里可以看到下图所示的软件源代码，也许可以算作那个时期的开源软件，但这类软件多用于教学，而不具有商业使用的价值，与今天所谈到的开源软件相去甚远。
编辑
编辑
本文谈到的开源软件是相对于闭源软件而言的，所谓闭源软件（Closed Source Software），也就是封闭源代码软件，是指源代码在获取、使用、修改上受到特定限制的软件。
开源软件（Open Source Software）是在1998年由克里斯汀·彼得森首次提出的概念。在此之前是反对将软件私有化的自由软件Free Software，其版权声明是“任何人都能拥有运行、复制、发布和修改自由软件的权利，并且任何人都能够得到自由软件的源代码。”其代表人物是Linus Torvalds，1994年，代表软件Linux正式版本发布。自由软件的倡导者为了体现信仰自由和极客精神，创造了Copyleft一词以对峙软件版权Copyright。但自由软件反对版权化和商业化过于理想主义，同时也为了避免对Free Software一词中的Free误读成免费，开源软件也就应运而生了。开源软件在开放软件源代码和商业化之间做了折衷，在发行时附上软件源代码，并授予用户使用、更改和再发布的权利，同时，通过授权协议，允许版权和专利的存在，不反对将软件私有化和商业化。
根据开源许可证的严格程度可以分为四类：开放型开源许可证，以MIT、BSD、Apache许可证为代表；弱传染型开源许可证，以LGPL、MPL、EPL为代表；传染型开源许可证，以GPL（GUN General Public License 2.0、3.0）为代表；强传染型开源许可证，以AGPL为代表。
在上述两起案件中均涉及的GPL开源许可协议属于传染型开源许可证。GPL开源许可协议最初由自由软件基金会为GNU项目所撰写，给与任何人自由复制、修改和发布源代码的权利，GPL 3.0还明确了专利许可。以2007年6月29日发布的GPL 3.0为例，其中部分条款规定如下：
“4．发布完整副本
您可以通过任何媒介发布本程序源代码的未被修改过的完整副本，只要您显著而适当地在每个副本上发布一个合适的版权通告；保持完整所有叙述本授权和任何按照第7节加入的非许可的条款；保持完整所有的免责申明；并随程序给所有的接受者一份本授权。
您可以为您的副本收取任何价格的费用或者免费，您也可以提供技术支持或者责任担保来收取费用。
5．发布修改过的源码版本
您可以在第4节的条款下以源码形式发布一个基于本程序的软件，或者从本程序中制作该软件需要进行的修改，只要您同时满足所有以下条件：
* a）制作的软件必须包含明确的通告说明您修改了它，并给出相应的修改日期。
* b）制作的软件必须包含明确的通告，陈述它在本授权下发布并指出任何按照第7节加入的条件。这条要求修改了第4节的“保持所有通知完整”的要求。
* c）您必须把整个软件作为一个整体向任何获取副本的人按照本授权协议授权。本授权因此会和任何按照第7节加入的条款一起，对整个软件及其所有部分，无论是以什么形式打包的，起法律效力。本授权不允许以其他任何形式授权该软件，但如果您个别地收到这样的许可，本授权并不否定该许可。
* d）如果您制作的软件包含交互的用户接口，每个用户接口都必须显示适当的法律通告；但是，如果本程序包含没有显示适当的法律通告的交互接口，您的软件没有必要修改他们让他们显示。
如果一个覆盖程序和其他本身不是该程序的扩展的程序的联合体，这样的联合的目的不是为了在某个存储或发布媒体上生成更大的程序，且联合体程序和相应产生的版权没有用来限制程序的使用或限制单个程序赋予的联合程序的用户的合法权利的时候，这样的联合体就被称为“聚集体”。在聚集体中包含覆盖程序并不会使本授权应用于该聚集体的其他部分。”
在案例一中，被告认为，原告主张的软件是使用PHP和MYSQL两种开源软件开发的，PHP软件使用基于GPL开源协议的PHPCCPL开源协议，MYSQL使用标准GPL开源协议。无论是根据CCPL还是GPL开源协议的规定，原告不能禁止其他方改编、使用、复制、发表该软件，也不得向其他方收取软件使用费用，这一说法是不符合开源协议本意的。本案一审法院也认为，虽然涉案ShopNC软件系使用PHP语言编写，但并非所有使用PHP语言编写的软件均为开源软件。
在案例二中，被告提交的公证书显示，原告网站的前端代码中使用了GPL许可协议下的开源代码，原告对此亦予以认可并明确其在本案主张权利的代码为后端代码。法院认为，前端代码开发主要是指前端用户可见的操作界面如页面布局、交互效果等页面设计的一种实现方式，后端代码开发则主要是指后端用户不可见的服务端相关逻辑功能等模块的实现，二者展示方式不同、所用技术不同、分工亦有明显区别，属于可独立的程序根据GPL协议的相关规定，GPL协议的许可客体是在GPL协议许可下批准的受版权保护的程序及基于该程序的衍生产品或修订版本。就本案而言，原告主张的权利的后端代码中已排除开源代码，原告虽在其前端代码中使用了开源代码，但其后端代码程序并非其前端程序的衍生品或修订版本，故根据GPL协议的相关规定，该协议对涉案权利代码并无拘束力。据此，被告的相关抗辩理由不能成立。
开源软件曾一度被微软CEO史蒂夫·鲍尔默称为知识产权的癌症。但是，随着互联网行业的兴起，云计算、大数据、人工智能等领域的快速发展，开源软件已经逐步从非主流变成主流，包括操作系统、编译工具链、数据库、web服务器、移动操作系统等领域都涉及到了开源。2014年6月12日，特斯拉宣布将其持有的所有专利开源，将开源精神带入汽车行业。如今，开源已不局限于软件行业，更是将自由选择的权利和对知识的开放共享的精神传播到社会各个领域。
开源软件虽然拥有很多优点，但事物的发展必然有其两面性，开源软件也不例外，特别是知识产权风险方面，如著作权、专利权、专利许可和专利报复、商标权、商业秘密等也是值得众多开发者和用户在享受开源带来的红利的时候，仍应保持一份警觉。
人工智能技术与开源软件
开源软件对人工智能技术发展的影响
人工智能技术的发展离不开基础研究的深入，这一技术的发展非常迅速，科技巨头们都在着眼于构建具有活力的开源社区，以便拓展自身的开源生态圈。2015年，谷歌推出了其开源框架解决方案TensorFlow，它是一个用于机器智能的开源软件库，吸引了不同的企业到这个平台训练他们的模型，这个系统的通用性使其也可广泛用于其他计算领域。Facebook也推出了Caffe2框架，旨在让微软和亚马逊等主要市场参与者和社交网络的PyTorch框架一起使用这个平台。[2]开源平台的发展确实让企业获得了更多创新力量，他们推出的深度学习开源平台在全球人工智能领域占有很大的份额。截至目前，知名开源社区GitHub上已经汇集了6500多万的开发者、300多万家公司和机构，拥有超过2亿的代码库，其中人工智能项目的占比很高，人工智能代码开源已经成为了发展的主要趋势之一。[3]2021年7月8日，中国科学院院士梅宏在世界人工智能大会上提出，人工智能的快速发展离不开代码开源和数据开放，高质量的开放数据促进了深度学习算法突飞猛进，深度学习框架极大提升了算法开发的效率，两者相辅相成。[4]
在大数据产品领域中，基本上所有的数据库产品都绕不过使用 MariaDB 、PostgreSQL 和 MongoDB等开源数据库的核心代码。著名手机系统安卓系统也采用了Linux内核项目，而该项目本身也是开源软件。开源软件的运用使得其他使用者不用从头开始开发一个全新的系统，只需要在已有的开源项目的基础上进行修改和定制即可，最重要的是，开源软件通常是免费的，这在很大程度上刺激了行业创新的积极性。
我国的人工智能开源项目正处于起步阶段，2018年中国人工智能开源软件发展联盟发布的《中国人工智能开源软件发展白皮书（2018）》中指出，人工智能开源软件是驱动人工智能技术创新和应用的重要支撑力量。2021年两会期间发布的《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》中也指出，“支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务。”目前，我国已经打造了OpenI启智平台、之江天枢人工智能开源平台等项目，为人工智能行业的发展提供新动力。
开源软件的特点
1.什么是开源软件？
开源软件对人工智能技术的发展至关重要，那么了解开源软件的法律性质就成为使用开源软件的前提。开源软件通常被认为是指开放源代码的软件，任何人可以查看、修改或者增加其源代码。开源软件与专有软件不同，专有软件的使用需要经过作者的同意或者获得授权，一般情况下还需要支付费用。而开源软件是由其作者将源代码公开在网络上，任何人可依据开源协议的要求使用相应的源代码。开源软件仍然属于作品，受到著作权的保护，开源软件的作者仍然对其公开的源代码享有著作权。需要明确的是，在没有任何前提地公开源代码并不意味着任何人可以随意使用，相反，根据各国著作权法一般的规定，著作权人对源代码享有权利，任何人不得未经同意复制、使用、传播其作品。因此，如果作者希望更多的人能够来使用、修改、完善自己发布的代码，其可以通过选择相应的开源协议，通过建立作者与使用者之间的授权许可关系，免除使用者的侵权责任。
2.与开源软件有关的机构
既然开源协议对使用者的行为提出了相应的要求，那么又由谁来保证使用者实际遵循了这些要求呢？1985年，理查德·斯托曼发起成立了自由软件基金会（Free Software Foundation，FSF），它是一个致力于促进计算机用户自由的非营利组织。最初成立该组织的目的是为了促进自由软件的开发，目前该协会自身就拥有GNU操作系统的版权。除此之外，通过协议签署，FSF已经拥有大多数GNU软件和其他一些自由软件的版权，以便FSF可以通过诉讼要求使用者履行开源协议项下的义务。
早在2008年，思科公司曾因为其销售的无线路由器Linksys WRT54G的固件中使用了GNU/Linux系统但未向用户发布所有的源代码而遭到FSF的起诉。在此之前的几年中，FSF一直尝试与思科公司沟通希望说服其主动发布产品源代码，但是并没有得到有效的回复。在诉讼过程中，双方最终达成和解，思科公司将任命一名免费软件总监，负责使Linksys品牌产品符合GPL授权方式，并向FSF汇报相关情况。思科公司还将告知现有Linksys客户他们的权利，并在网站上发布产品源代码，将源代码反馈给FSF。
除了拥有开源软件版权的机构，开源软件的作者自身也可以依据开源协议的内容进行维权。社区维权[5]被认为是更理想的维权方式，不过在开源社区中，大多数人认为更主要的努力方向是促使使用人合规，而不是惩罚。[6]
3.开源协议主要类型
（1）开源协议的主要内容
开源协议是软件开源时使用了许可证，其主要作用是规定了许可内容，以便使用人能够自由地使用作者发布的源代码，而不必担心侵权他人版权的问题。一般的软件许可协议中会规定许可使用的期间、地域范围，权利类型，许可的具体权利，如复制、修改、传播、收费等权利。某些开源协议中还会对代码有关的专利许可进行约定。
（2）常见的开源协议
目前比较常用的开源协议有GNU General Public License (GPL)、Apache License 2.0、BSD licenses、 “Lesser” General Public License (LGPL)、MIT license、Mozilla Public License 1.1 (MPL)和Common Public License 1.0等，已有的开源协议已经多达八十几种。
类型
简介
GPL：由自由软件基金会发行的用于计算机软件的许可证。
目前大多数的GNU程序和超过半数的自由软件使用此许可证，知名的Linux就是采用了GPL。GPL允许代码的免费使用和引用、修改、免费使用，并且要求修改后和衍生的代码做为闭源的商业软件发布和销售。这就导致任何基于GPL许可证项下代码修改的衍生产品在向公众提供时的同时需要公开其源代码。支持者认为GPL保证了代码自由的延续，任何基于前人智力成果创作的新产物也必须向公众免费公开；而反对者则认为，GPL的强制开源要求会导致企业不再愿意选择为GPL的开源代码的创新做贡献，因为他们不愿意将自己的衍生产品开源。
LGPL：直译是更少限制的GPL。
它允许衍生产品作为闭源产品，这也是考虑到私有软件闭源的需求，促进开源软件的应用和推广。这也是使用GPL发布的开源软件风险度较高的原因所在，绝大多数诉讼都是由于企业未能发布应用GPL开源软件衍生品的源代码而引发的。
Apache License 2.0
其允许代码修改，再发布，且不需要强制衍生产品的开源。但是如果修改了代码，需要在被修改的文件中说明。在衍生产品中需要包括原来代码中的协议、商标、专利声明和其他原来作者规定需要包含的说明。Apache License对于商业应用来说是较为友好的许可类型，使用者可以修改代码并作为自己的商业产品进行销售。
MIT许可证
MIT许可证是更为宽松的许可证类型，使用者可以使用、复制、修改软件，并且将其作为商业软件发布，MIT唯一的限制就是在软件和软件的所有副本中必须包含版权声明和MIT许可声明。
使用开源软件的主要风险
1.开源协议的法律风险
在开源协议的背景下，选择适合企业情况的许可证至关重要，这决定了软件使用者的自由程度。如果选择得当，企业可以享受开源社区便利的同时提高自身产品的适应性。但是选择不当，则有可能为衍生产品的使用埋下隐患。
（1）GPL许可中的强制开源
GPL协议具有高度的“传染性”，其允许第三方对开源的代码进行免费使用、修改，但是不允许将修改后的代码作为闭源的商业软件发布和销售。著名的Linux内核开源项目就是使用的GPL协议，由于使用Linux内核开源项目的上层服务不可避免地会涉及到调用Linux内核的文件，如果将该行为视为创作了衍生产品，那么将导致上层服务的源代码将会被受GPL协议控制的Linux内核开源项目所“传染”，从而需要接受GPL协议。这就形成了一个以Linux内核开源项目为核心的传染源，任何基于Linux开发的内核到驱动到中间服务到上层应用都受到GPL协议的控制，在符合发布软件的条件下需要向大众开放源码。不过Linux内核的作者Linus Torvalds以及内核开发人员多次澄清普通系统调用为非GPL的作用范围，也就是允许 Linux 用户空间的程序使用其他许可证。
2018年，软件自由保护协会（Software Freedom Conservancy）罕见地在其博客对某知名车企的GPL合规问题的细节进行了披露。SFC指出，其从2013年6月以来就收到多起有关S车型的GPL违规报告，该车型搭载的车载系统中含有BusyBox和Linux项目，但是该公司却迟迟没有向用户公开该系统的源码。SFC就此问题一直在督促其尽快提供完整的，但是在漫长的沟通过程中，该公司至今仍然没有向SFC或者公众提供符合GPL协议要求的源码。
另一个值得注意的点是，GPL协议要求使用者在分发软件时提供源代码，这意味着如果使用者在修改代码后不以分发的方式向用户提供程序，那么就没有必要向用户提供代码。例如目前Saas模式下，供应商将应用软件部署在自己的服务器上，用户通过互联网获得供应商提供的服务，而不需要供应商发布任何的源码或者目标代码。在这种情况下，供应商不存在代码发布行为，因此不需要将修改后的代码予以开源。
（2）双重许可
双重许可是指版权方既把产品作为商业软件销售，又适用开源协议供公众使用。一方面，版权方可以通过商业销售获得利润，另一方面，又可以利用开源社区的优势为软件更新增添活力。例如许可人可以选择同时使用专有许可和GPL协议，GPL协议保证了被许可人如果要发布修改后的产品，其必须一并提供产品的源代码。当然许可人也可以选择更为宽松的许可证，这样可以利用开源社区强大的研发力量更新自己的产品，将衍生代码合并到自己的产品中。MySQL数据库管理系统使用的就是双重许可的模式，一边以专有许可的模式满足用户的使用需求，一边以GPL许可证的优势来获得更新的软件。[7]
（3）违反开源协议后的法律风险
欧洲自由软件基金会的FTF部门与GPL维护组织（GPL-Violations.org）在2008年发布了一份《举报和修复违反许可证行为指南》，该指南主要是对常见的开源软件合规性问题进行解释。例如任何人都可以向基金会或者GPL维护组织举报企业的违规行为，当收到举报通知之后，欧洲自由软件基金会与GPL-Violations.org会通过邮件或信件方式与违规者协商，协商不成可能会采取诉讼方式达成庭外和解或者申请法院禁令。根据GPL-Violations.org的经验，其已在德国和美国获得了成功的案件判决。
2.专利侵权的法律风险
开源软件仅是就软件授予著作权方面的许可，在某些开源协议项下并不包含专利许可，因此如果软件包含已申请的专利，使用该开源软件就有可能存在专利侵权的风险。例如，BSD、MIT许可证就不包括专利许可，而Apache-2.0和GPL协议则包含了专利的普通授权许可，使用人在获得著作权许可的同时也不必担心存在专利侵权的风险。对于没有明示有专利授权的开源软件，在使用前应当进行相关的专利检索，如存在有效的专利，使用该开源软件则存在专利侵权的风险。
3.软件漏洞的法律风险
在使用开源软件时，一旦开源软件的代码存在安全缺陷，人工智能企业将面临着严重的安全问题。据调查，针对人工智能行业在开源软件代码安全缺陷分析中，项目主要的安全缺陷就来自于API误用和代码质量问题，其比例占所有安全问题的94%。[8]而使用开源软件因其缺陷问题受到网络攻击的后果只能由使用者自行承担，无法向开源软件的提供者进行追偿。例如RealAI发布的RealSafe人工智能安全平台通过测试得出微软、亚马逊云服务的人脸比对演示平台存在巨大安全漏洞。目前，人脸识别技术广泛应用于金融远程开户、手机解锁、支付验证等场景，如果这一漏洞被不法分子所利用，将会对用户的人身财产安全造成巨大影响，届时可能会产生用户向产品供应商进行索赔的情况。
4.出口管制的法律风险
随着中美关系的日益紧张，美国对中国实行的技术进出口管制政策趋于严厉，美国联邦政府发布的《出口管理条例》（Export Administration Regulations，以下简称“EAR”）不但可以管制从美国境内向境外输送实物产品，还包括向美国境外人员提供用于电子传输的软件。在全球最大的代码托管平台Github的用户协议上明确表示，其网站上的信息都可能受美国出口管制法律的约束，包括美国出口管理条例（EAR）。Apache基金会开发的产品是通过公开论坛在线协作完成的，通过美国的中心服务器进行分发，因此Apache开源协议也同样需要受到美国出口法律法规的管辖。
不过，根据EAR的规定，大部分已发布的开源代码并不会受到进出口的限制。例如，已公开发布的开源软件、已公开发布的开源规范、已公开发布的，说明硬件设计的开源文档和已公开发布的开源软件二进制均不受EAR的限制。但是，EAR规制了特定加密软件和技术的出口，包括仅激活或启用其他软硬件产品的加密功能的软件。[9]因此，在使用开源软件时还应当结合当地的技术进出口管制措施，如相关技术落入管制范围，则需要按照当地的法律法规进行申报获得许可后才能引入，否则可能引发不必要的法律风险。
四人工智能企业合规建议
1.开源软件管理审核
为避免在使用开源软件过程中发生的风险，建议企业在内部管理机制上增设开源项目管理流程或者部门，以便对开源软件的使用安全性、合法性进行评估。随着国际化程度的不断加深，中国产品越来越多出口到国外，开源软件风险问题也日益突出。企业可能会遇到用户个人或者软件自由保护协会的通知，要求其履行开源协议的义务。虽然目前在国内环境下，开源协议的履行尚未得到司法确认，但是已经有了承认开源协议效力的判例。企业应当尽早了解风险，做好风险预防，在面临相关风险前培养自身抵抗风险的能力。
2.技术进出口合规审核
除了开源软件的进出口限制，企业还应当依据购买软件时技术出口方国家的技术进出口措施进行合规审核。在目前复杂多变的国际政治经济形势下，大国之间的博弈也常常体现在对技术进出口的限制上。美国曾发布相关措施限制人工智能软件的出口，限制出口的软件包括应用于智能化传感器、无人机、卫星和其他自动化设备的目标识别软件（无论民用或军用）等。企业一旦落入或者违反相关规范，可能导致被制裁的后果，对未来在该国从事商业活动造成严重影响。
3.专利前置审核
由于开源软件的许可证不一定明示了专利许可，因此，在使用他人的开源代码前，应当根据使用地域对当地的专利注册情况进行检索。如果权利人已经在先注册专利，那么该开源代码使用方式就受到了限制，企业应当根据自身需求，判断是否能够继续利用该开源代码以及如何利用。
4.开源方式审核
选择合适的许可方式是保证可持续性发展的前提，企业可以以专有许可、开源许可证或者双重许可的方式选择是否对公众发布产品的源代码，以及后续以何种方式更新。如果一项成果是基于已有作品修改完成的，那么它最好符合原作品许可协议的要求，因为协议中有可能要求它遵从相同的许可证发布。对于不值得更新的小程序来说，使用GPL是不适宜的，因为它无法发挥自身传递性的优势，刺激后人对开源的软件进行补充、修改或者更新。
5.软件尽职调查中的开源风险审核
如前所述，人工智能技术离不开开源软件的支持，在并购交易中，如涉及人工智能企业或者其他软件研发企业，对其软件进行开源风险核查是十分必要的。通过对软件使用的开源软件、开源协议的调查可以识别相应的商业软件本身是否存在开源风险、安全漏洞或者质量问题，使用方是否已经履行了许可协议相关的义务，为交易双方的安全交易提供法律保障。
[注]
[1] 早期的人工智能还只是一个设想，英国数学家、逻辑学家图灵在提出一项关于检测机器是否具备人类智能的猜想，即让被测试者（人）向人与机器询问问题，如30%以上的被测试人无法分辨做出回答的是人还是机器，即说明该机器具备了像人一样的思考能力。这是最早对人工智能概念进行解释的观点之一，同时也为后来的人工智能技术的研发奠定了基础。
[2] 参考链接：https://cloud.tencent.com/developer/article/1051255，《格局可能会改变？科技巨头们正在使用开源框架来主导人工智能社区》
[3] 参考链接：http://www.xinhuanet.com/tech/2019-10/17/c_1125114032.htm，《开源开放是人工智能发展主要趋势之一》
[4] 参考链接：https://finance.sina.com.cn/tech/2021-07-08/doc-ikqciyzk4243170.shtml
[5] 德国的Netfilter内核子系统贡献者 Patrick McHardy就曾以不遵守 GPL 为由，自行担负起GPL执法角色，联络了德国的许多企业索要小额金钱，在18个月内他利用这种方法“索取”了200万欧元的收入。然而据报道，相关行业的专家在评估了Patrick McHardy对Netfilter内核子系统的贡献之后，认为其对整个系统的贡献有限，只能就其所创作的作品享有权利，而不能就整个项目主张版权。
[6] 参考链接：https://www.sohu.com/a/201032826_261288
[7] 在Artifex Software, Inc.（“Artifex”）和 Hancom, Inc.（“Hancom”）之间的诉讼中，Artifex发布了Ghostscript，并同时以专有许可和GPL许可的方式授权第三方使用，其诉称Hancom未能遵守GPL许可下的义务，在免费使用Ghostscript的情况下，将其修改的版本整合到自己名为Hangul的商业软件中对外销售产品，但是没有分发产品的源代码。
[8] 参考链接：https://www.freebuf.com/articles/paper/186281.html
[9] 参考链接：https://www.sohu.com/a/407098658_675634
三、法理分析
1、开源协议适用范围及其对软件著作权侵权判定的影响
开源软件并不排斥著作权保护，开源协议实质是权利人将其复制权、发行权、修改权等附条件地许可给不特定公众的著作权许可使用合同。因此以权利软件使用了开源协议或包含开源代码而无权禁止复制、发行、修改为由进行的抗辩并非针对权属的抗辩，而是获得许可的合法使用抗辩。在此基础上，开源协议的适用范围就成为了审查重点。同时，开源协议具有明显的双务性，被许可人违反适用条件可能导致授权终止而构成侵权。准确认识开源软件和开源协议的性质，能有效避免法律风险，使得我国能够更好适应开源软件所带来的开放环境。
一、基本案情 不乱买电子商务（北京）有限公司（以下简称不乱买公司）主张其享有自主开发的“不乱买”网站的著作权，北京闪亮时尚信息技术有限公司（以下简称闪亮时尚公司）旗下“闪亮时刻”网站未经许可使用了与其网站源代码实质性相同的源代码，构成著作权侵权，诉请法院判令闪亮时尚公司承担停止侵权、赔偿损失等责任。北京知识产权法院一审判决，闪亮时尚公司构成侵权，应停止侵权并赔偿损失等。闪亮时尚公司提起上诉，认为不乱买公司软件代码因使用了大量开源软件代码导致权属存在争议，并且不乱买公司适用GPL协议的前端代码文件未与后端代码文件有效隔离，且二者存在数据交互调用配合，前端代码和后端代码共同构成权利软件，该权利软件是前端代码的修改版本，根据GPL协议及GPL协议具有极强“传染性”的特性，权利软件整体均应遵循GPL协议向所有第三方无偿开源，因此闪亮时尚公司不构成侵权。 二、裁判理由 最高人民法院审理认为，前端代码一般是关于用户可见部分的编码，用以实现操作界面如页面布局、交互效果等页面设计；而后端代码一般是涉及用户不可见部分的编码，用以实现服务端的相关逻辑功能。因此，前端代码与后端代码在展示方式、所用技术、功能分工等方面均存在明显不同，不能因前端代码与后端代码之间存在交互配合就认定二者属于一体，前端代码与后端代码其实是相互独立的。因此，当权利人明确放弃以前端代码主张权利仅以后端代码主张权利时，权利软件仅为后端代码而非前端文件和后端文件共同构成权利软件，并无证据证明其中存在开源代码。根据涉案GPL协议内容，可以看出GPL协议的“传染性”应当是指GPL协议的许可客体不仅限于受保护程序本身，还包括受保护程序的衍生程序或修改版本，但不包括与其联合的其他独立程序。由此可见，GPL协议要求开源的是本身接受其协议的软件代码及针对这些软件代码的修订或者根据这些软件代码开发的延伸程序，而不包括与这些代码有数据交换等联合的其他独立程序。虽然不乱买公司认可其前端代码中使用了GPL协议下的开源代码，但其主张权利的是后端代码，其后端代码是独立于前端代码的其他程序，并不受GPL协议的约束，无需开源，闪亮时尚公司的相关抗辩不能成立。 三、法理分析 开源软件因其自由、共享的精神，为软件技术的创新发展注入了活力，使得软件行业的知识创新和产品创新保持高速发展，为我国软件技术发展提供了一个开放的环境，也带来一定的法律风险。由于我国目前尚未形成较具规模的开源社区和较权威的开源软件行业自律组织，我国司法实践中尚未出现直接以违反开源协议为由起诉的案件，但出现了部分以权利软件使用了开源协议或包含开源代码而无权禁止被诉侵权人复制、发行、修改为由进行抗辩的案件。此种抗辩与传统软件著作权侵权抗辩事由存在着明显区别，需要对开源软件和开源协议的性质、开源协议的适用范围、该抗辩的审查要点进行了解和分析，才能在准确适用法律以适应并推进软件行业的发展。 （一）开源软件和开源协议的性质 与专有软件强调独占性保护不同，开源软件是以用户为中心的。著名开源软件组织Free Software Foundation指出软件不应限制其用户，每个用户都应该有按自己的意愿使用软件的自由、把软件分享给友邻的自由、按自己的需要修改软件的自由、分享自己对软件的修改的自由四项基本自由。当一个程序为其用户提供所有这些自由就是开源软件。软件自由是目标，开源则是手段。同时，为使得开源软件始终保持“自由”，避免有人利用开源代码后将代码封闭，保证修改或衍生的软件仍能如原始作者所期待的那样给予用户“自由”而不会返回专有软件，开源软件并未选择放弃著作权直接使软件进入共有领域，而是选择采用copyleft的方式。Copyleft是一种让软件成为开源软件并要求其所有修改版本和衍生软件也成为开源软件的通用方式。Copyleft从其本质上看并非排斥著作权（copyright），而是在著作权制度框架内通过许可方式对后续使用者持续开源，并通过附条件许可的方式使得使用者及修改者也持续开源,这是开源软件能够存在并发展的重要保证。开源软件强调的自由并不否认知识产权的存在，而是依赖于现有著作权法律体系的，因此，开源软件及其衍生软件或修改版本的著作权仍然存在，且权利类型也没有缺少。开源软件的著作权人仍享有复制权、发表权、修改权、署名权、保护作品完整权、获得报酬权等权利，不过其通过许可的方式将其中的某些权利如复制权、修改权等授权给不特定公众。 使用开源协议是软件开发者将其软件开源最常见的方式，而在众多开源协议中，GNU General Public License（以下简称GPL协议）是最受欢迎且应用范围最广的，本案中所涉及的也是该开源协议，因此以其作为典型进行论述。开源协议的性质决定了开源协议的适用范围及相关抗辩的定性。我国尚未出现直接以违反开源协议为由起诉的案件，司法实践中缺乏对开源协议性质及其法律适用的认定。但近年来，美国、德国等开源软件规模庞大的国家，相关案件却并不鲜见。因美国合同法与版权法分属州法和联邦法的法律体系，与我国差距较大，其关于GPL协议的争议对我们认定GPL协议的性质意义不大。而德国法院的认定则集中体现在Welte诉D-Link一案中。该案中，法院认为GPL协议条款的法律性质是特定的一般交易条款，即预先拟定，由著作权人向使用人提出的合同条款。同时，开源软件著作权人无需接受使用人的承诺声明，双方即可构成法律关系。GPL协议中的许可条件是合同的组成部分，其中关于软件程序使用人必须附上协议的正文、发布原作者著作权标示和无担保声明、附上完整的源代码等规定未不适当地损害使用人的利益，是有效的。如果被许可人违反上述许可条件，根据GPL协议规定则不得对开源软件进行复制、修改、再授权或发布。任何试图以其他方式进行复制、修改、再授权或者散布本程序的行为均为无效，并且将自动终止基于本授权所享有的权利。在此情况下，被许可人所获得的授权意味着自动终止，其将为自身未经授权发布或复制软件的行为承担侵权责任。从该案的审理中可以看出，德国司法实践倾向于将GPL协议认定为附解除条件的合同，其中许可使用条件为解除条件，当被许可人未按许可使用条件使用时，合同解除、终止授权，被许可人继续使用则构成侵权。 我国《计算机软件保护条例》第八条规定，软件著作权人可以许可他人行使其软件著作权，并有权获得报酬；第十八条规定，许可他人行使软件著作权的，应当订立许可使用合同。GPL等开源协议属于公开可自由取得的文件，著作权人在公开源代码时明确声明并附加GPL等开源协议的行为可被视为要约，不特定主体复制、运行、修改、传播附有开源协议的源代码的行为应为承诺，承诺做出即产生法律效力，合同成立。因此，开源协议是著作权人将其复制、发行、修权利授权给使用者的著作权许可使用合同。与一般著作权许可使用合同不同，其面向的是不特定的主体。开源协议在内容上具有明显的双务性，在对权利人许可的范围、方式等进行详细规定的同时，也对被许可人接受许可的行为等进行了规定，并对终止授权的情形和后果进行了规定。综上，开源协议是软件著作权人将其复制权、发行权、修改权等附条件地许可给不特定公众的著作权许可使用合同。 （二）开源协议的适用范围 鉴于开源协议的本质是软件著作权人将其复制、发行、修改等权利授权给不特定公众的许可合同，相应开源协议仅适用于同意受到协议约束发布的程序,即如果原始版权人在声明中说明其软件置于开源协议下发布,则适用开源协议。同时，从许可行为来看，开源协议有着严格限制，如GPL协议就不适用于复制、发行和修改以外的行为,因为超越了许可范围。 同时，保持源代码持续的公开性是开源软件的要求之一，因此，开源协议在保障被许可人自由的分享、使用、修改并分享其修改的版本时，对其分享、使用自身修改版本或衍生软件往往也会做出约束，以避免修改后和衍生的软件在之后的发布程序中封闭源代码进行发布和销售。以GPL协议为例，其第5条发布修订过的源码版本规定，被许可人可以源码形式发布一个基于开源软件的软件或修改版本，但是须满足的条件中包括按照GPL协议将整个软件许可给想要获得许可的人，GPL协议及符合第7条的附加条款适用于整个软件及其所有部分，无论该等程序以什么形式打包；一个受保护作品和其他分离的单体作品的联合作品，在既不是该受保护作品的自然扩展，也不以构筑更大的程序为目的，并且自身及其产生的版权并非用于限制单体作品给予联合作品用户的访问及其他合法权利时，称为“聚合版”。在聚合作品中包含受保护作品并不会使GPL协议影响聚合作品的其他部分。上述内容即GPL协议的传染性及例外情形的规定，该规定保证了开源软件修改版本和衍生版本的持续开源，并将部分与开源软件结合为一体的软件代码纳入到开源软件范围内，扩张了开源协议的适用范围，在拓展增加开源软件的数量的同时为开源软件与专有软件的共存划定了界限。这一界限的划分看似清晰，但聚合体与修改版或衍生版的区别到底如何判断，确实是一个司法实践难点。目前我国出现的以权利软件使用了开源协议或包含开源代码而无权禁止被诉侵权人复制、发行、修改为由进行抗辩的案件中，几乎均涉及到了权利软件是否被GPL等开源协议感染的问题。对此，Free Software Foundation在GUN许可协议常见问题“‘聚合版’和其他‘修改版’有什么不同？”中回应：“聚合版”包含有多个独立的程序。如何区分是两个独立的程序还是一个程序的两个部分，是一个法律命题，最终会由法官来决定，但其认为合理的标准既依赖于通信的机制（exec、pipes、rpc、共享地址空间的函数调用等），也依赖于通信的语义（交换了什么样的信息）。关于“何时一个程序和其插件会被认为是一个结合在一起的单一程序”，Free Software Foundation也有类似的回应：如果主程序与插件之间通过共享或交换复杂数据结构而建立了密切的通信，他们就是一个结合在一起的程序；如果并没有建立起密切的通信，插件就是一个单独的程序。由此可见，GPL协议所能传染的衍生软件或修订版本，应当是与原开源软件形成密切通信使得二者高度牵连融合成一体的程序，而非只要有数据交换就会构成传染。结合本案，前端代码开发主要是指前端用户可见的操作界面如页面布局、交互效果等页面设计的一种实现方式，后端代码开发则主要是指后端用户不可见的服务端相关逻辑功能等模块的实现，二者展示方式不同、所用技术不同、分工亦有明显区别，显然属于独立的程序。前端代码中存在的部分开源代码可能传染部分前端代码，但在权利人整体放弃前端代码仅主张后端代码的情况下，其权利代码并未被纳入GPL协议的适用范围内，并不受GPL协议的约束，也未被许可给公众进行复制、发行、修改。 （三）开源协议对软件著作权侵权判定的影响 开源软件和开源软件的修改版本或衍生软件跟专有软件一样，都享有著作权。而开源协议的本质是软件著作权人将其复制权、发行权、修改权等附条件地许可给不特定公众的著作权许可使用合同。因此，以权利软件使用了开源协议或包含开源代码而无权禁止被诉侵权人复制、发布、修改为由提出的不侵权抗辩，其本质是被诉侵权人获得著作权人许可的抗辩而非针对权属的抗辩。本案中，因权利人主张的权利软件与开源代码之间的隔离使得GPL协议对涉案权利代码并无拘束力，即权利代码并未根据GPL协议被许可给第三方，许可的获得也就无从谈起。 同时，在分析我国相关案件中被诉侵权人的抗辩时，还可以看到一个现象，被诉侵权人往往仅强调GPL等开源协议中权利人的开源义务（许可他人修改、复制等）而忽视被许可人的义务（保留声明、注明修改信息等），这其实是对开源软件和开源协议的一种误解。开源协议具有明显的双务性，被许可人在行使复制、发布、修改开源软件的权利时，也需要按照开源协议要求承担相应义务，否则可能导致其权利被终止。以GPL协议为例，第4条规定被许可人在发布完整副本时须每份复制件上均附有明显且恰当的版权声明，完整保留GPL协议及附加条款，完整保留不含担保声明，将GPL协议与程序一同移交接受者；第5条规定被许可人发布的修改版本须带有醒目的修改声明及相应的日期；第8条规定被许可人未获得GPL协议明确授权时，不得传播和修改受保护作品。任何试图以其他方式进行复制、发布、修改受保护作品的行为都是无效，且将自动终止被许可人通过GPL协议获得的权利。被许可方复制、发布、修改相关开源软件的唯一权利来源是开源协议的许可，一旦被许可方违反GPL协议其权利即告终止，但其复制、发布、修改软件的行为通常会处于持续状态，在此期间，被许可方复制、发布、修改软件而无合法权利来源可能构成侵犯他人著作权。因此，违反GPL等开源协议可能存在违约责任和侵权责任竞合的问题，二者在法律依据、侵害对象、产生前提、举证责任范围、责任内容等方面不同，从德国、美国司法实践看，多数法院将被许可方未履行开源协议约定的义务的行为认定为著作权侵权。因此，以权利软件使用了开源协议或包含开源代码而无权禁止复制、发布、修改为由提出的不侵权抗辩，除需证明权利软件受将其复制权、发行权、修改权许可他人使用的开源协议的约束外，被诉侵权人还需证明其行为符合相应开源协议的要求而非随意使用，否则仍有可能因其行为不符合开源协议约定导致许可终止而构成侵权。 四、法官建议 随着信息通信技术的发展，开源越来越成为一种主流的开发模式。认清开源的本质、了解开源的游戏规则，对于我国企业发展开源软件、规避开源软件风险至关重要。我国虽尚未出现直接以违反开源协议为由起诉的案件，但出现的以权利软件使用了开源协议或包含开源代码而无权禁止复制、发行、修改为由进行抗辩的案件，暴露出我国部分企业对开源软件和开源协议认识上存在的不足和误区。开源不是免费的午餐，开源软件不是公共领域软件，其享有著作权并受著作权法保护，不可以任意使用。开源软件的著作权人通过开源协议将开源软件的复制权、修改权、发行权等部分权利许可给了使用人，但这种许可是附条件的，被许可人只有在遵从开源许可协议规定的前提下，才可以行使这些权利。如果企业没有按照开源许可协议的规定使用开源软件，则存在很大的著作权侵权风险。现代社会中机遇与挑战并存，在享有开源带来的福利时，必须对其法律风险予以高度关注，这样才能更好适应开源软件所带来的开放环境。
2、《开源项目风险分析与对策建议》 报告解读
1.《开源项目风险分析与对策建议》 报告解读 CRVA联盟秘书处 中科院计算所 2019.6
2. 开源项目总览 项目声明 开源项目 贡献者 用户 开源基金会 开源许可证 托管平台 开源信息流动 依赖关系
3. 内容 • 法律约束 • 国际开源组织 • 国内开源现状
4. 三种约束 1. 出口管制（Export Control） • 商品出口 2. 司法管辖权（Jurisdiction） • 商业纠纷 3. 开源许可证（License） • 知识产权
5. 约束1：出口管制 • 国家出于政治、经济、军事和对外政策的需要，制定的商品 出口的法律和规章，以对出口国别和出口商品实行控制 • 美国出口管制条例（EAR，Export Administration Regulations） • 主要规定是否能从美国出口货物到外国，以及是否可以从外国“再 出口（re-export）”到另一个外国 • 按照EAR 的规定（734.7b 和742.15b）：所有“公开可获得 （publicly available）”的源代码（不含加密软件以及带加 密功能的其他开源软件），都不被出口管制 • “公开可获得”的带加密功能的源代码，被出口管制，但不 会被限制出口，需提前登记备案（5D002）
6. 默认情况 vs. 潜在风险 • 默认情况：开源项目（除含加密功能的开源项目需 备案外），都属于“公开可获得”的代码，可以正 常使用 • 极端情况下的潜在风险：如果一个开源项目或开源 组织声明遵从美国的出口管制条例，一旦美国修改 EAR，将高性能软件、EDA软件等一些核心基础软 件加入到管制中并且将目前“备案即不被管制”修 改为“备案且需要被管制”，那就意味着大量核心 开源项目将受到出口管制 • 2018年11月，美国BIS曾就AI和机器学习等新兴技术是否 加入管制名单征求公众意见（后未果）
7. 美国出口管制条例修改频繁 • 根据美国政府的需要，EAR可随时被修改 • 事实上，美国也一直频频修改EAR https://www.bis.doc.gov/index.php/regulations/export-administration-regulations-ear
8.软件源码 vs. 美国出口管制条例 经典案例 • 案例1：1995年Junger vs. US Department of State[1] • 大学教授Junger要在课上为学生讲述技术相关的法 律，其中有关于软件加密的技术，但听课的学生中有 外国留学生，因此也落入了出口管制限制的范围，并 且面临百万美金巨额罚款和最高10年刑期的诉讼 • 案例2：1996年Bernstein vs. US Department of Justice[2] • 学生Bernstein是为了公开发表自己发明的加密算法 论文，并且希望可以公开的、不受限制的参加学术会 议讨论他的算法 [1] https://www.eff.org/cases/junger-v-dept-state [2] https://www.eff.org/cases/bernstein-v-us-dept-justice
9.诉讼观点 vs. 美国法院最终判决 • 诉讼人观点：软件源代码应该是一种言论自由， 并且应该受宪法第一修正案保护 • 美国法院最终判决：软件源代码是言论自由，受 宪法第一修正案的保护；美国政府不能试图限制 软件源码流通 • 对开源软件代码的影响：美国政府没有能力对软 件源代码实施禁运 • 思考：诉讼人如果不是美国公民，美国法院会如 何判决？
10. 案例总结 • 美国宪法：开源 = 言论自由，受宪法保护 • PGP开源加密算法案例中，美国教授胜诉 • 但美国宪法保护的是美国公民 • 中美关系冲突时，国家利益高于一切 • 美国宪法并不会保护中国公民和企业的利益
11. 约束2：司法管辖权 • 司法管辖权又称为审判权，是指法院或司法机构 对诉讼进行裁决和判决的权力 • 使用网站或注册会员时，如果其使用条款 （Terms of Use）或会员条款（Membership Agreement）中指定了司法管辖权的归属，则 代表合同双方同意只承认指定的司法机关做出的 判决为赔偿的依据
12. 默认情况 vs. 潜在风险 • 默认情况：在无侵犯知识产权等商业纠纷时，不 触发司法行动 • 极端情况下的潜在风险：如果一个开源项目或开 源组织指定了司法管辖权归属于美国某法院，那 么所有围绕使用条款展开的纠纷，都将以该美国 法院的判决为准。
13. 约束3：开源许可证 • 开源许可证属于软件许可证 • 软件许可证是一种具有法律性质的合同或指导，目的在于 规范受著作权保护的软件的使用或散布行为 • 当下常用开源许可证（如BSD、MIT、GPL）都是 围绕代码的版权声明，以及修改后是否可以闭源等 问题展开的 • 早期的开源许可证如MPL 1.1等，在协议中指定了其司法 管辖权在美国加州，但现在皆已弃用 • 当下常用的开源许可证保护的是知识产权，其自身 与出口管制和司法管辖权并无关联
14. 默认情况 vs. 潜在风险 • 默认情况：开源许可证的作用为保护知识产权， 不涉及国家法律层面的其他条款（如出口管制、 司法管辖权等） • 极端情况下的潜在风险： 如果美国NSF、NASA 以国防安全为由，制定一个新的开源许可证，限 制其资助的所有开源项目只能在美国使用和发布， 则美国以外的其他国家将失去这部分开源项目的 使用权。国内公司一旦使用，就会侵犯知识产权
15. 开源许可证受法律保护—— 著作权侵权 • 案例1：2006年美国Jacobsen vs. Katzer[1] • 被告方使用原告方基于Artistic License 1.0开源协议开发的代码，但并未 注明原作者信息，因此诉讼被告方侵害了原告方的著作权 • 案例2：2006年德国Welte vs. D-Link[2] • D-Link软件产品使用了基于GPL2协议的软件，但其产品不开源 • 案例3：2010年Oracle起诉Google Android侵犯著作权 • 开源代码的原作者可以依照版权法提起侵权诉讼 • 对于开源软件用户来说，使用免费得到的开源代码，如果违反了原 始许可证协议，会被法律判定为侵犯开源软件作者著作权 [1] http://www.lexisnexis.com/ap/academic [2] 张汉华.违反开源软件许可证的法律救济——以德国法为视角. 法学评论，2015年03期
16. 开源许可证受法律保护—— 违反特定约束 • 开源软件用户被开源许可证赋予了特定权力，同时也被 规定必须遵守特定的约束 • 典型案例： • 2002年，MySQL AB控告Progress NuSphere违反GPL发布衍生作品， 最终和解 • 2008年，自由软件基金会对Cisco公司提起诉讼，Linksys品牌的多个 产品违规使用GPL开源软件，Cisco被迫和解，贡献代码并向自由软件 基金会提供实际资金支持 • 2007年始，BusyBox公司和软件自由法律中心控告了Monsoon Multimedia、Xterasys、High-Gain Antennas等公司违反GPL许可 证，大多公司被迫修改自己软件的许可证并做赔偿 • 2009年，Microsoft 承认在其Windows 7下载工具软件中违规使用了 GPL开源软件，并在Windows Store中撤下该工具，并承诺做出修改。 该工具为微软请第三方开发的，并未对相关代码进行评估
17. 开源许可证受法律保护—— 专利侵权 • 对于开源软件的贡献者而言，所创作的软件作品中可能已经使用了 一个或多个专利技术，从而可能侵犯专利权 • 用户所获取的开源软件是依照专利技术获得的软件产品，使用该软 件产品也是可能侵犯专利权的 • 利用开源许可证协议，可避免一部分专利侵权风险 • 例如，在Apache-2.0许可证下，贡献者将其贡献的开源软件中的专利权许可给 用户，并约束用户不能就自己对该开源软件中的贡献向任何实体主张专利侵权 • 典型案例： • 2003年Unix系统开发商SCO公司（拥有Unix专利）起诉IBM公司贡献给Linux 开源操作系统的代码中涉嫌专利侵权 • 2004年OSRM（开源软件风险管理）发布研究报告指出，Linux潜在地侵犯了 283项专利。其中包括微软27项，IBM60项，惠普20项以及英特尔11项 • 2007年微软声称Linux侵犯了其235个专利
18. 小结 出口管制 司法管辖权 开源许可证 效力范围 商品出口 商业纠纷 知识产权 默认情况对开源 无（含加密功能 无 无 项目出口管制 需备案） 极端 潜在风险 可管制开源项目 由指定美国法院裁决 侵犯知识产权 情况 发生条件 需修改出口管制 出现纠纷 制定新开源许可证 条例 • 美国出口管制针对的主要是“商业行为”，目前尚未发现对教育 和学术有明确影响 • 所在基金会声明、开源项目声明和开源许可证，任意一个出现了 出口管制和司法管辖权的相关条款，都将约束该开源项目
19. 内容 • 法律约束 • 国际开源组织 • 国内开源现状
20. 开源项目的四个依赖 项目声明 开源项目 贡献者 用户 开源基金会 开源许可证 托管平台 开源信息流动 依赖关系
21. 依赖1：开源基金会 • 开源基金会管理开源项目 • 调研12个基金会 • 自由软件基金会，软件自由保护组织，Linux基金会、Apache软件 基金会、Eclipse基金会，OpenStack基金会，Python软件基金会、 Mozilla基金会、Open Networking 基金会、RISC-V基金会、 HAS基金会、Free and Open Source Silicon基金会 • 管理办法差异较大 • Linux基金会自身的管理办法不受美国出口管制 • Apache基金会管理办法明确说明遵循美国出口管制 • Mozilla基金会明确声明司法管辖权归属加州 • RISC-V基金会隶属于Linux基金会，没有特别声明受美国出口管制； 但指明其司法管辖权在美国特拉华州
22. 依赖2：开源项目自身声明 • 开源项目隶属于开源基金会，默认遵从基金会的 声明，但开源项目可独立声明 • 虚拟化项目Xen隶属于Linux基金会，但明确说 明出口方遵循美国出口管制，是Linux基金会中 的特例 • It is your obligation as the exporter to comply with the current applicable requirements of United States export rules and regulations. https://xenproject.org/about-us/
23. 依赖3：开源许可证 • 调研6个开源许可证： • GPL • LGPL • BSD • MIT • Mozilla • Apache • 均未涉及与政府出口管制相关的声明 • 说明：但并不代表其不受出口管制和美国法律约束，该项 目还要同时取决于所在基金会声明和项目自身的声明
24. 依赖4：代码托管平台 • 调研3个代码托管平台： • GitHub • SourceForge • Google Code • 三个平台均明确声明遵守美国出口管制条例，并 且司法管辖权均在加州
25. 案例分析：GitHub • GitHub.com明确声明GitHub.com、 GitHub Enterprise Server，以及两者上的信息都是被 出口管制
26. 针对国家的条款 • GitHub Enterprise Server是商品，被出口 管制，不能出口到被制 裁国家（如伊朗等） • 学术界仍可访问GitHub 免费服务，公司和其他 结构目前尚不确定
27. 争议：GitHub上的代码是否 受到出口管制？ • GitHub上的代码存在两重身份 • 开源代码 - 不被出口管制 • GitHub上的信息 - 受到出口管制 • 表面上看会得出相互矛盾的结论 • 但GitHub的司法管辖权在美国 加州 • 最终解释权归美国加州法院 • 即受到出口管制
28.规避GitHub出口管制风险 情景1：已有开源项目同时托管多个平台 已有开源项目 美国以外其它 托管平台 开发者 开源信息流动 已托管平台 未托管平台 不受美国出口管制 受到美国出口管制
29.规避GitHub出口管制风险 情景2：已有开源项目只在GitHub托管 已有开源项目 发起者 发起人使用本地 副本创建托管项目 美国以外其它 托管平台 开发者 开源信息流动 已托管平台 未托管平台 不受美国出口管制 受到美国出口管制
我们应该怎样使用开源软件
开源是近年来大火的词汇。自2017年7月Facebook的React开源软件被Apache基金会宣布禁止使用、百度也宣布全面停止使用以来，开源软件的合规性使用引发了大家的关注。
我们以React为例，看看开源软件的坑在哪里。
编辑
React的开源许可证
React最初的开源许可证为Facebook 在BSD许可证基础上附加了专利防御保护条款，即BSD+Patents license。
解读
原许可证在著作权授权使用（BSD）的基础上添加了防御性专利侵权条款(Patents)，写明在以下三种情况下Facebook授予被许可人的专利权将被撤回：
如果被许可人对Facebook及其子公司、关联公司提出直接或间接的专利诉讼；
对其他方提起专利诉讼，且该专利诉讼全部或部分起因于Facebook、其子公司或者关联公司的任何软件、技术、产品或服务；
就React软件相关发起专利诉讼，起诉其他方。
通俗的可以理解为：只要因为你提起专利诉讼，让Facebook成为被告或者第三人，Facebook都可以撤回React的专利授权。
许可证及后续Facebook的答疑中明确专利权在以下情形下不会被撤回：
被许可人使用React创造了竞争产品；
被许可人就专利侵权之外的事项起诉Facebook；
Facebook作为专利诉讼（非因BSD+Patents license授权下的软件相关）的原告，被许可人反诉的情形。
另外，Facebook也明确了专利授权的终止并不会导致著作权许可的终止。
质疑漩涡
Apache基金会在2017年7月禁止Apache 产品中使用遵循BSD+Patents License的JAR包。质疑漩涡进一步发酵，社区激烈地质疑Facebook违背了开源的精神。
虽然并没有现成的案例可以支持。然而，引起大家担忧的是从许可证文本约定来看，如果某公司强依赖性使用React，则Facebook可以自由使用该公司的所有专利。因为只要该公司发起对Facebook的专利诉讼，该公司的React的专利授权就会被撤回。
在持续发酵的情况下，Facebook承诺更换许可证，并于9月26日遵守承诺在发布React16时更换为MIT许可证。然而，对Facebook还坚持使用原许可证的开源项目，仍然应该引起关注。总体而言，React许可证的更换不仅是开源社区的一次胜利，更是提高了企业、开发者对许可证重要性的认识、起到了警示作用。
如何正确使用开源软件
1. 关注开源软件使用的合规性
同开源软件的广泛使用相对应，开源许可证的遵守情况却不容乐观。从法律的角度来讲，使用者自引入某开源软件的时刻起，其开源许可证将自动适用。使用者如未履行许可证规定的义务（如加入版权说明），即构成侵权，或者违反契约（合同）的行为，并因此可能造成许可证的撤回并承担相应的赔偿责任。
例如Netfilter核心开发者团队的 Patrick McHardy，以违反GPL许可证为理由，在德国威胁超过80家公司，并谋利约200万欧元。事后Patrick McHardy被定义为“GPL谋利-版权谋利者”。2016年12月16日美国的软件自由法律中心（Software Freedom Law Center）起诉包含三星在内的14家厂商违反GNU许可证。在中国国内，小米公司也因屡次违反开源协议而被社区指责。从以上案例中也可以看出国内外企业对开源许可证的义务、法律责任均认识不足。
综上，未按照开源许可证约定使用开源软件会引发潜在的法律纠纷，或者给企业带来名誉损失。因此，企业在使用开源软件时应建立审查制度。依据开发软件的用途、目的、市场等情况判断是否引入某开源软件。
就软件开发服务提供者而言，应首先关注同客户的合同约定，在合同约定可以使用的前提和范围下，尽到对客户的通知义务或取得客户的书面同意。以避免因为使用开源软件导致的合同违约或者被追偿。
2. 关注开源软件使用的安全性
开源软件由于贡献者的能力不同导致可能存在安全漏洞。因此，开发者在享受开源软件的便利时，应注意漏洞的识别，并采取相应的代码安全审计，并将已披露漏洞及修复方案及时告知客户。
3. 制定开源软件使用政策。
如果公司在业务中大量采用开源软件，则制定并执行开源使用政策就变得尤为重要。根据公司业务的不同，政策可以涵盖公司对开源的态度（是否支持，创建社区还是加入某社区）、哪些应用可以开源，哪些应用可以使用开源软件；哪些许可证类型的开源软件可以使用、审查流程等。从而最大限度的避免公司的知识产权侵权风险。
开源软件商标许可政策
一、开源软件与商标
开放源代码运动(Open Source Movement)源自于美国，由于其具有公开源代码、必须遵守开源许可证等特性，使其获得了“数字时代的文艺复兴”、软件领域的“具有共产主义色彩的战略”等美誉。而开源软件则是这项运动带来的最主要的产物。可以说，开源软件的诞生是对传统软件模式的一次反叛，引起了计算机产业、经济学界和法学界的普遍关注。
由于开源软件兴起之初曾专门针对copyright(版权)兴起过copyleft、copywrong等理念，因而近年来人们关注最多的是开源软件的版权及许可协议问题。然而，随着开源软件向商业领域的回归，其与商标权相关的法律问题不仅更多，而且带有更大的紧迫性。
在开源软件界，最早的商标诉讼案例应当是发生在美国的LINUX商标抢注案。像许多电脑黑客一样，Linux Torvalds在1991年发布的程序内核之后，并没有将LINUX或Linux注册为商标。数年之后，另外一个美国人William R. Della Croce在美国抢注了Linux商标，使用商品类别为计算机类产品。之后，他向《Linux杂志》和其他一些以Linux产品为主的商业软件公司致函，要求他们支付商标许可使用费。这一诉讼震惊了整个开源软件业，直到1997年，诉讼双方才正式达成庭外和解，并将注册商标所有权转移给公认的程序内核开发者Linux Torvalds。[1]
或许是吸取了在美国遭抢注的教训，Linux Torvalds随即在其他国家着手进行商标注册申请。但在2005年，澳大利亚知识产权局却以四条理由驳回了其就LINUX要求注册商标的申请[2]，这个案例再一次给开源软件业的商标使用政策敲响了警钟：要想开源软件产业能够健康地发展，仅仅“获得”了某个商标是不够的，还需要商标的所有权人合理地、正确地“使用”商标。
对于一个企业来说，商标的使用和申请固然重要，但其最终目的还是要为“营利”服务，即通过商标许可来收费。在越来越多的开源软件企业投身商业化之后，开源软件业对商标权的许可问题投入了更多的重视，特别是以开源软件为主要产品的商业公司，更是相继提出了商标许可政策或商标使用政策。
继MySQL AB诉Progress Software Corp.，NUSPHERE Corp.一案中，原告试图通过商标保护获得利益之后，最近，著名的开源软件BitTorrent的创始人Bram Cohen也成立了一间以BitTorrent命名的公司，并就BitTorrent进行了商标注册，声称要加强对这个商标的法律保护措施，以保证所有使用BitTorrent名字的下载软件都是合法和安全的。这意味着，今后任何人想在自己的软件产品中使用BitTorrent这个窗体底端商标，都要向该公司交纳一笔使用费，而BitTorrent公司会对使用该商标的软件进行安全性能的审查[3]。可见，在今后一段时间里，就商标收费或谋取其他的利益将是众多开源软件企业的商业选择。
二、开源软件企业商标许可政策及合理使用
日前，关于开源软件的商标权问题诉讼已经出现了若干起，其中最著名的就是MySQL AB公司与Progress公司的诉讼中就商标权提出的诉求。同时，从MySQL AB公司、RDEHAT公司等著名开源软件企业纷纷推出商标许可政策的行为看，我们有理由相信，今后一段时间开源软件企业将大量利用商标策略进行盈利，OSI组织或许也会加入到通过证明商标(OS、OSI)等进行收费的行列。这要求我们对开源软件的商标许可政策的合法性和合理性进行审慎的分析与判断。
OSCAR开源产业大会 | 开源许可证的认识路径
编辑
开源软件是软件的一种类型，如何保护，则取决于软件作者的声明，即使用何种授权方式给用户使用和分发，这就是开源许可证的缘由。
《大教堂与集市》的译者卫剑钒在其公众号创作了一系列的人话版开源许可协议，为开源许可的普及做了很大的贡献。
因为许可证类似一个法律上的东西，类似于一个合同。你发布一个源码的时候，你得说清楚你这个东西大家可以怎么用，不能怎么用，有什么义务，能做什么不能做什么，这是要写的，如果不写这个的话，别人给滥用了，你说你怎么办？挺麻烦的。举个例子，去年有位程序员，他写了新蜂商城这么一个开源软件，后来别人在那卖，他就很气愤，事实上他自己没搞明白他的作品是以 MIT 许可发布的，是可以卖的。再有，比如你是公司的程序员，你用了GitHub上其他项目的源码，你把版权行给注释掉了，或者写许可证那段话你觉得挺烦的看着不顺眼弄干净了，这个都是有问题的，别人到时候告你也很麻烦。如果大家有关注的话，上个月在深圳就发生了一起上门索要源码的事件，因为他用了GPL许可证的软件，给他要源码他又不好好回答，语气上有点不太礼貌，说上门才给，结果别人真就上门来要源码，搞的事情还挺大。总之，不懂许可证也可以干得很好，但要小心引来麻烦。
开源许可证里面讲的很清楚，如果是个人使用者，你自己把代码 download 下来玩玩、学习，你根本不用管，你拿下来随便玩。如果企业使用开源开发项目自己用，项目不分发也没问题，但是你如果要将项目变成产品进行商业分发和销售的话，那这个时候就不行了，所以在我们公司里面实际上我们并不是简单的一味的卡住说许可证风险多么的大，实际上是在用这个东西的时候想清楚：这个项目是什么项目，最后是什么样的分发场景，再来做决定。
（中兴通讯）已经制定了一整套这方面的指导规范。刚才问到，说开发人员是不是可以不懂开源许可证就可以把这个代码开发的很好，实际上这是我们追求的终极目标，因为大家知道有关许可证现在 OSI 承认的许可证有100个左右，但是还有两千多个是非OSI认证的许可证，这些许可证实际上假设你在不了解它的情况下，你要去使用它的话，这有可能对企业来说，可能就是埋了一个雷，但是你要让我们的开发人员每使用一个许可证，都要把许可证解读的很清楚这也不现实，因为许可证它是很多灰色的法律条文，就是让我们专业的律师去解读，也是很繁琐，所以一般的情况下律师碰到这些许可证会和开发一起来沟通，一起了解这个场景，开发人员才能真正的理解。所以我们试图会输出一些许可证的解读指导和培训材料，告诉我们的开发人员，在什么样的场景下你怎么做是没问题的。
很简单的说Open Source是专有名词，我这里有一个license你看看是不是符合OSD，他们经过讨论觉得这个符合就加入到他们的列表里面去，如果不符合就拒绝，每年都会为这件事情争论很多很多。然后Open Source这个名词就是他们维护的，也是他们注册的，所以你说我这个东西是一个Open Source的，但是我用的license不是经过 OSI 认证的，抱歉你不应该自称为开源软件。
最终他的解释权在法院，经过打官司决定你某某license是否生效，是法院决定的，不是 OSI 决定的，这个没问题。
项曙明：这个条款如果他写的通俗易懂大家都能看的懂，我觉得不管是中文的还是英文的都应该比较容易理解，但是有些法律条款在有些场景下的理解或适用性有时是不一定一下子就能想清楚的。所以对于我们公司使用的很多许可证，我们把使用频率TOP20高的许可证先让律师都做了解读，同时结合不同的研发场景，输出合规使用的指导书，这些指导书经律师和开发一起评审，确认可切实有效降低合规风险，这些许可证解读和场景合规开发指导才是真正给开发人员的开发指引。
卫Sir：这种东西看多了就好了，其实差不多。尤其是后面的免责条款，基本上是免除他自己的责任，你用出问题自己负责，一般会有这么一条，都差不多。一般都会有一条说我允许你用，你可以随便改，可以分发。再有就是传染性和非传染性的，传染性就是说你改了你得把你的代码贡献出来继续用我的许可证，当然，传染这个词不太好，略显负面，但大家都喜欢这么叫，也不太好改口了。有人把它叫“互惠”，意思是你用了我的代码，你如果做了改进也贡献出来，这个说法也很好。再有就是一些许可证会做一些限制条件，会说明使用者的义务，比如你改了什么地方要明示出来，要在比较明显的地方写出来。为什么要这样呢？程序员拿到你改后的代码和原先人家的代码对比的话，他当然有技术手段可以对比，但是如果你写的很清楚你改了什么，大家去找这个区别就比较容易，另外一个比较重要的考虑是：人家代码原先写的很好，你改了以后带来很多新的bug，这时候可以把这个错误“归功”于你，不要把这个错误“归功”于人家原始作者。
对程序员的建议你要有license这个概念，几大主流的license是什么意思，你要有个底。这些都是程序员所需要理解的基础，因为你现在已经不是从头写自己的代码，你是基于绝大多数的开源软件，再写自己的代码，你对开源的license一无所知这肯定是不对的，你如果不是操作系统的开发者，你确实不需要对操作系统的所有的了解那么多，具体的许可证解读你就找振华咨询就可以了。
项曙明：程序员送给程序员的礼物，如果你不遵守license，版权信息和license信息都去掉之后，就等于收到了别人的礼物说这是我自己的东西，不是别人送的，这是非常不礼貌的行为。如果我们放的更宽一点，把这个当成我发表论文或者文章的时候，如果你把引用文章的出处删掉之后，你等于说这些东西都是你自己写的。但是具体到软件开发过程中，可能你的项目是依赖于别人的代码，或者开源社区代码而写出来的，如果你把这些依赖和引用说明都删掉，可能你的领导或者别人以为这都是你自己写的原生代码，全是你自己的研发实力和成果。其实不是这样的，你如果自己好好去研究，就能比较好的认识到自己在开源代码上面衍生创造的竞争优势或者差异化优势在什么地方，哪些地方其实是你依赖了别人，这样有利于你更好的认识自己以及自己的代码。
孙振华：我记得有个本土的案例，拿着开源社区的代码去登记著作权，登记成功后被扒出来造成了恶劣影响。我觉得还是要懂许可证，开发人员需要理解这些许可证，企业也可以多做功夫。
庄表伟：说起本土的协议，除了大家熟知的木兰许可证，其实还有一个中文协议：ZPL协议。山东青岛的一个朋友叫王春生，他们搞了一个禅道，以自己撰写的ZPL发布，其实他也把ZPL发到OSI的邮件列表想申请通过，最后没有批，认为他们的协议不是一个开源的协议，另外一个就是木兰协议，发到邮件列表，讨论审批，很快就通过了，人家觉得你这个很规范，符合OSI。回过头来聊聊ZPL的意义在哪？为什么他们要改写出自己的ZPL？改完了以后OSI认为不对。ZPL的要求是说你得把我的LOGO留着，你改了任何界面都无所谓，但是在这个界面让依然要有禅道的LOGO，以及禅道的LOGO要指向禅道的公司，这个到底算不算不对的东西呢？OSI的看法你分发的源码当中有一段HTML里面写了一个引用了这张LOGO的图片，然后有一个link指向你们的公司，这都是源码，这些源码为什么不能改了呢，其他源码允许别人改，这段包含LOGO和指向你们公司的源码为什么不能改，如果你限定了什么东西不能改，这就违反了开源当中允许任何人改任何源代码的那个规定，而禅道的意思是说这不是源码，这是我们的标志，这些标志对我们的商业利用很重要，所以它应该始终指向我们公司。这个争论说实话我甚至都不是完全站在OSI的那边，我认为一家公司为了维护自己的商业利益来做这样的规定是合理的，只是这样的合理诉求，最终没有通过OSI的认证，所以他现在不能或者不应该被简单的称之为开源软件，而是一个以ZPL license分发的开放源代码的软件，可以这样说，但是简单的叫开源软件我觉得还有问题。相反的木兰协议就很清楚，所有的用到木兰协议的软件都是开源软件，这个没有疑问。本土确实有一些不一样，我甚至没有简单的是非来说，禅道的ZPL的动机以及他的合理性我是认的，不是说他不对，他要保留LOGO露出权的商业利益我认为还是很合理的。
孙振华：目前国内法院几起关于开源许可证的案例都认可主流的英文版的开源许可协议。鉴于各国都已经签订了著作权条约，所以各个法域都认为在著作权范围内，保护的权益以及保护的方式是差不太多的。当然会有一些略微的区别，但是这个区别并不会成为违反license的理由，或者在用license维权时产生一些重大的问题，综上，你提到本土的license有没有必要去做特别多，我个人认为是没有必要的：首先在现在整体的开源许可证的选择上，有一种反分裂的趋势，最明显的就是虽然OSI认证的大概有一百多种，再加上自由软件那边也有认可很多，但是目前主流的只能用到大致是十几种。原因就是因为这些主流的目前更受大家欢迎，公司使用的时候一般不太愿意选择比较陌生的许可证。在这个前提下，如果再分裂出来一些，可能很难流行起来。比如说目前本土已经有OSI认可的许可证出现在比较少的项目中，比较流行的项目中还是更多会采用类似Apache一类的协议。我认为本土license的最大益处就是可以推动开源的文化，也可以考虑把国外的许可证翻译成中文，比如说卫Sir的翻译也是很好的推动开源文化的方式，并不是说非要搞出来更多分裂的许可证或者许可协议。
卫Sir：本土许可证有一个好处：它至少会有一个中文版，有时候会弄双语版。但是国际上比较流行的许可证，基本上都是英文版的，GPL就明确说了，说如果你要上法庭的话，只能以英文版为准，因为翻译会有偏差，可能会偏离原意，这样的话你在中国打GPL协议相关的官司，大家都得以它的英文文本来分析、来判决。而如果有本土许可证，大家都比较熟悉中文，歧异会相对小一点，我觉得这个可能是本土协议的一个优势。
现场观众C提问：我觉得从企业的角度来说做的比较好，有一个很现实的问题，怎么样说服老板去认可这个事，你是怎么样说服你的老板在企业里面推广的，怎么样让我的工程师去知道这些流程的，有没有可度量的东西。
项曙明：从我现在的考虑，实际上自身的改变我觉得都比较难，其实很多情况下实际上是外部的环境在拉着企业往前跑。有两种场景，一种场景是要进入某个细分市场要做这个认证那个认证，这是一个方面。另一个方面就是刚才说的外部的一些风险，有时候官司来了，有时候人家的法律函来了。这些都会对老板有一个触动，比你自己去说很多遍要强很多，这是我的感受。
孙振华：我来讲一下我的认识以及经验。法务早期参与开源的作用是为了防止风险的发生，所以我们第一步会先看相关风险案例或者诉讼案例，我们会把这个作为风险的提示。目前开源合规的文化普及，我们也和国外的一些律师及一些公司进行接触，逐渐的认识到做好开源合规将让自己的产品变得更加可信。如果你把一些没有license，或者说一些license违规的产品或者服务交付给客户，可能到某一天就会爆雷，会丧失用户和客户的信任。从长远来看，我认为可信这点是非常重要的。
项曙明：我觉得就是认识的问题，以前我们企业在推广的时候，我们很多的员工有可能还不理解，就说这个事情为什么要做？其实从我的感受，参加信通院这几年来的活动，我觉得金融行业社区的发展就比较典型，三年前讨论关心的问题是开源我们能不能用？开源用了以后如果一出问题我们行长就肯定乌纱帽要掉了，这两年大家已经认为使用开源要必须的，大家关心的问题变成了怎么能合规使用。实际上在企业里也是一样，开始很多开发人员他假设没有理解必须要做的情况下，他肯定是说这个事情我不做，为什么要做？但是他如果认识到这个事情肯定要做的情况下，他就会告诉你，你告诉我怎么做？但实际上开源合规使用在企业里面推广的时候，往往你很难一下子说出来我告诉你怎么做，因为它是一个新的东西，而且不同的场景也非常复杂，我们想告诉他在某种场景下你应该怎么做？这是企业开源合规治理能力建设的问题，是一个长期建设和积累的过程。能力建起来后你就可以告诉员工应该按照什么样的游戏规则来合规做事，开发人员肯定很高兴。但实际上在推广过程中，特别是在企业里面推进的这些人，感觉很费力，领导觉得你推进太慢，这个怎么不行，这个赶快推。从为什么要做，到告诉我怎么做，是一个不小的进步，但是怎么做它是一个慢慢生长的过程，输出各种场景下的合规指引，需要有人先去研究，但由于牵涉年太广，在企业内很难有一个专职的团队先研究好后再来给研发用，而只能通过共享共创的方式，有意识的来引导和提炼这些指引。因为大家知道开源贯穿于产品开发经营的全过程，使用到的开发语言特别多，要输出不同场景的指引其实非常难，要推行起来很难！从为什么做到怎么做的转变过程，我们大概花了有一两年的时间，当时我们专门写了一个PPT，叫开源风险洗脑PPT，这个洗脑不光是洗员工的脑，实际上有时候也洗了领导的脑，因为开始领导们的意识跟开源理念也不完全一致，我觉得这个理念大家转变过来了以后，下面就是推动怎么做的问题了，推动也确实比较艰难的。
蔡总：项博会出一些规范，我们会执行。作为开发者的角度来讲，我觉得大部分开发者是不需要太多的关心开源社区的问题，因为一个项目你要做的时候一定是有一个项目组，项目组会决策你用哪些开源项目，他会考虑这些事，在项目里面是会分工的。我这儿讲一个不是license的事，和license相关的。我非常认可卫Sir说的大家可以放心使用各种各样的开源社区，因为从社区里面会汲取很多很多营养，但是你作为商业应用的时候一定会选主流的社区，因为主流社区的协议一般用的比较多，也经过千锤百炼大家用的比较放心的，这是两个维度。你自己的探索学习放心大胆的用，商业用法一定是主流的社区，分裂社区的事情我也不太赞成，会分散大家的精力。在互联网软件行业大家有个思维，我是自由的，我是免费的，大基层的人他们认为这样可以促进整个软件行业的发展，我们也看到所有几十年下来，软件行业互联网行业蓬勃发展就是有免费资源，他认为免费资源可以推动创新，并且我们所有的开发软件是离不开开源的，你用的编译器，你用的语言，你用的所有东西都是开源的，我是希望所有的开发人员都拥抱开源，从开源里面会学到很多东西。
项曙明：我补充一下，我觉得从个人开发者来说的话，因为企业里面如果确定了一套切实有效的流程，他如果按照这个流程来做，实际上一样可以做的很轻松。就说这个许可证，开源社区实际上很多的许可证不是简简单单单一的许可证，一个开源项目不同的版本它有可能遵循的许可证就不一样，甚至还有一个开源软件它会遵循多许可证，一个项目遵循的多许可证有时会多达30多个，甚至有些多许可证中还包含了商业许可证。我们是做商业的，商业涉及到盈利、成本，使用了遵循包含商业许可证的多许可证的开源软件该怎么办？商业分发的时候你就得去购买授权，这也就变成了产品的成本了，你跟人家竞争的时候会平白的多出几万块钱或者几十万块钱的这么一个成本来，对你产品的商业运作或者商业销售都会产生影响，所以实际上开发人员在商业的企业里面，他一定是在一定约束的环境下使用开源，也不能太自由。当然如果是为了学习为了自己内部使用是可以自由的使用。
五、参考资料
1、开源模式的知识产权风险分析http%3A%2F%2Fbos.itdks.com%2F481b885cdbfb4b95be9cad87c1486a88.pdf
2、开源社
3、什么是开源软件？什么是开源软件？ | IBM
4、开源时代的风险是什么？开源时代的风险是什么？ – 新思科技, 引领万物智能
5、代码质量和维护：开源使用的新风险代码质量和维护：开源使用的新风险 – 新思科技, 引领万物智能
6、开源软件漏洞安全风险分析开源软件漏洞安全风险分析--国家保密局互联网门户网站
7、开源违规案例开源违规案例 - 百度文库
8、关注企业开源供应链：开源有风险，使用需谨慎！https://posts.careerengine.us/p/60ceb742cc36c019d32093b3
9、美国权威开源安全机构 WhiteSource 完成对 Mintegral SDK 的安全审计
11、如何获得开源项目的资金如何获得开源项目的资金从Linux
19、我国开源软件许可证法律风险及其应对制度完善https://wap.cnki.net/lunwen-1011089934.html
23、App Store 审核说我的 App 山寨抄袭我开源代码的 App 并拒绝了版本更新https://v2ex.com/t/811123
Comments