《开源项目风险分析与对策建议》 报告解读

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托管 已有开源项目 发起者 发起人使用本地 副本创建托管项目 美国以外其它 托管平台 开发者 开源信息流动 已托管平台 未托管平台 不受美国出口管制 受到美国出口管制