开源风险专题研究
作者：互联网
一、基本概念
开放源代码软件
https://zh.wikipedia.org/wiki/%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6
开放源代码软件与自由软件是两个不同的概念，只要符合开源软件定义的软件就能被称为开放源代码软件（开源软件）。自由软件是一个比开源软件更严格的概念，因此所有自由软件都是开放源代码的，但不是所有的开源软件都能被称为“自由”。但在现实上，绝大多数开源软件也都符合自由软件的定义。比如，遵守GPL和BSD许可的软件都是开放的并且是自由的。
虽然开放源代码的堡垒看似严谨，但其实大部分的程序开发员都弄不清各种许可证之间的差别，导致成为了小部分别有用心人士所利用的对象，较著名的例子有DivX，早期DivX雏形是一个LGPL的自由软件，由大部分优秀的软件高手义务地开发，但当软件渐渐成形时，DivX的公司DXN利用LGPL的漏洞对DivX进行了闭源，大部分软件爱好者都感到被出卖，所以着手开发了XviD。虽然XviD在软件方面明显比DivX优秀，但市场占有率却不如DivX。
GNU
https://zh.wikipedia.org/wiki/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、如何选择开源许可证？
如何为代码选择开源许可证，这是一个问题。
世界上的开源许可证，大概有上百种。很少有人搞得清楚它们的区别。即使在最流行的六种----GPL、BSD、MIT、Mozilla、Apache和LGPL----之中做选择，也很复杂。
乌克兰程序员Paul Bagwell，画了一张分析图，说明应该怎么选择。这是我见过的最简单的讲解，只用两分钟，你就能搞清楚这六种许可证之间的最大区别。
下面是我制作的中文版，请点击看大图。
2、《开源软件知识产权风险防控研究报告》
http://www.caict.ac.cn/kxyj/qwfb/bps/201907/P020190710343670915282.pdf
勘误《开源软件知识产权风险防控研究报告》
中国信息通信研究院（以下简称信通院）是工业和信息化部直属科研事业单位，定位于“国家高端专业智库”，对信息科技行业的发展起到了重要的作用。在开源方面，信通院不定期地发布相关白皮书，较好地引领了相关产业对于开源的认识和实践。
对比中美两国开源产业的现状，可以发现美国有较多的律所和律师参与到该产业当中。但是在中国，较多的研究和法律建议是由非律师做出的，由此也能看出我国开源产业的发展较为滞后。背后的一大原因可能在于美国的律师与客户之间对涉及法律事项的讨论是受到特权（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许可证构成许可合同，不宜推而广之认为许可证在美国法下就是当然的合同。
三、法理分析
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、《开源项目风险分析与对策建议》 报告解读
http://crva.ict.ac.cn/documents/Comments-on-Risks-of-Open-Source-Projects.pdf
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托管 已有开源项目 发起者 发起人使用本地 副本创建托管项目 美国以外其它 托管平台 开发者 开源信息流动 已托管平台 未托管平台 不受美国出口管制 受到美国出口管制
四、典型案例
1、“拿来”有道--从利益平衡视角看中国开源软件著作权保护
“拿来”有道--从利益平衡视角看中国开源软件著作权保护 －挑战杯
工信部采购并强制电脑零售商安装的“绿坝”软件就被检测出擅自使用了基于BSD协议发布的开源软件源代码而未按授权许可协议要求注明使用代码的出处和原作者，在国内外引起较大反响，也损害了我国在知识产权保护方面的形象。
2、腾讯代码安全指南开源，涉及C/C++、Go等六门编程语言
3、新思科技发布《2021年开源安全和风险分析》报告
新思科技发布《2021年开源安全和风险分析》报告 - 国内 - CTI论坛-中国领先的ICT行业网站
通过对超过1,500个商业代码库进行分析，发现开源安全、许可证合规性和维护问题依然很普遍
相比闭源的软件，开源的优势显而易见，但是对开源风险的关注却远远不够。无论是政府机构还是相关企业都在积极推动开源治理。比如，为了让中国用户更好地理解和拥抱开源，中国信息通信研究院于2020年正式发布了业内首个《开源生态白皮书（2020）》。新思科技为该白皮书的发布做出了积极的贡献，集合Black Duck的深厚的行业经验和深度的积累，为开源项目提供深度的探测组件能力，推动行业和用户意识到开源组件依赖的合规和安全风险远比想象的要高。
- 所有经过审计的营销科技类公司的代码库都包含开源，包括CRM客户关系管理系统及社交媒体。其中95%的营销科技代码库存在开源漏洞。
- 98%的医疗保健行业代码库包含开源，其中有67%的代码库存在漏洞。
- 97％的金融服务/金融科技行业代码库包含开源，其中超过60％的代码库存在漏洞。
- 92％的零售和电子商务行业代码库包含开源，其中71％的代码库存在漏洞。
- 商业软件中过时的开源组件已成常态。85% 的代码库含有至少四年未曾更新的开源依赖项。与废弃项目不同，这些过时的开源组件拥有活跃的开发人员，但是他们发布的更新及安全补丁却没有被下游商业消费者所采用。除了忽略应用补丁会带来的明显安全隐患之外，使用过时的开源组件还可能带来技术上的麻烦，包括与将来更新相关的功能问题和兼容性问题。
- 开源漏洞趋势朝着错误的方向发展。2020年，包含存在漏洞的开源组件的代码库百分比为84%，较2019年上涨了9%。同样，包含高风险漏洞的代码库的百分比从49%上升至60%。2020年的审计中再次发现了2019年在代码库中发现的几个十大开源漏洞，并且所有这些漏洞的百分比均有显着增加。
- 超过90％经审计的代码库含有许可证冲突、自定义许可证或根本没有许可证的开源组件。2020年审计的代码库中，65%包含存在许可证冲突的开源组件，通常涉及“GNU通用公共许可证”。26%的代码库采用没有许可证或定制许可证的开源代码。这三种问题有潜在的侵权和其它法律风险，通常需要进行评估，尤其涉及到合并和收购交易的时候。
五、参考资料
标签：GPL,协议,许可,风险,代码,开源,专题研究,软件 来源： https://blog.csdn.net/zhuxuanlv/article/details/121062157