中国开源软件：出口管制对其影响及未来展望
作者：邱梦赟 2023-03-02著名Linux基金会在其出版物中提到，“开源发展的最大优势之一是它实现了跨边界的协作；开源协作透明、公开且能跨越组织边界，促使世界各地的开发人员、学者和工作人员一同成就比个人力量所能造就的更为伟大的开源技术。”
软件开发者在研发软件过程中，都毫无例外地会涉及引用多个开源项目的软件（下称“开源软件”）。从一项开源软件的诞生，到运营和治理、到被软件开发者二次开发和使用过程中，比较常见的有如下实体：开源代码的源作者、开源基金会、代码托管平台、开源社区。该等实体的关系如下：
从开源社区与开源基金会成立历史来看，尽管成立伊始，国际上较有影响力的开源社区、开源基金会均认为自身是独立的、不受政府影响，但如今形势下，国际主流的开源基金会、开源项目、开源许可证均诞生于美国或由美国公司掌控[1]，越来越多的国际主流开源基金会公开声明其遵守美国的出口管制规定。 因此，本文分如下四个部分展开： 1. 总结了常见的国际主流开源基金会、代码托管平台、开源许可证对于美国出口管制的态度与声明。 2. 从法律角度，分析了开源软件、加密技术是否受到《美国出口管制条例》（EAR）的管制。 3. 提示软件开发者须注意的出口管制合规与风险控制。 4. 就有关我国开源生态健康有序发展，从律师角度，提出建议。
一、常见的国外主流开源基金会对于美国出口管制的态度
开源基金会是专门为支持开源软件项目而办的非营利性组织，它通过为软件项目社区提供服务与支持实现价值，为IT 开发者提供了一个发现、使用、交流开源技术的平台[2]。 以下是常见的国外主流开源基金会对于美国出口管制的态度：
二、常见的国外主流代码托管平台对于美国出口管制的态度
常见的代码托管平台，比如 GitHub、GitLab、Bitbucket 、Gitee ，是基于 Git 的代码托管平台，通过网络为用户提供 Git 仓库托管服务。得益于 Git 分布式的特性，Git 代码托管平台上的仓库通常充当远程仓库的角色，便于多个开发者之间的同步。在此基础之上，代码托管平台还提供了许多协作功能，将版本管理、Bug 跟踪、代码审查、邮件列表、IRC 等众多功能组合在一起，以实现更高效的协同开发。简单来说，代码托管平台不仅仅提供代码托管服务，还有项目管理，甚至社交等功能。[17]
三、常见的开源许可证对于美国出口管制的声明
软件开发者在使用开源项目前，都需同意遵守开源项目所适用的开源许可证的约束，根据开源许可证的要求，在自身软件研发中使用开源项目。经查目前常见的开源协议，例如Apache 2.0 License[20]、MIT License[21]、BSD License[22]、SSPL[23]、LGPL 2.1[24]、GPL License[25]，该等开源协议中均暂未含有对出口管制合规的条款要求。
四、美国出口管制对于开源软件的管制规定
(一) 美国出口管制介绍及其与技术、软件的关系 《美国出口管制条例》（Export Administration Regulations，又称“EAR”）是美国出口管制领域的主要法规，由美国商务部工业与安全局（BIS）负责管理与实施。[26]EAR包含24个章节，内容涵盖出口管制的限制性措施、限制清单、许可证政策、程序等不同方面。[27] 从管制的对象角度，需要知道的是，EAR管制的不仅是有形商品，还包括无形的软件与技术。[28] 从管制的行为角度，《美国出口管制条例》（EAR）管制了五种行为，包括出口、再出口、发布、在国内转让、加密源代码和对象代码软件的出口。其中四种管制的行为均涉及到了技术与软件：
(二) 开源软件是否受到EAR的管制？
EAR规定了满足以下条件之一的信息与软件不受到其管制[35]： 1. “已发布”的信息与软件（如EAR第734.7条规定）； 2. 在基础研究期间产生的或由基础研究产生的信息与软件（如EAR第734.8条规定）； 3. 通过学术机构的目录课程或相关教学实验室以教学形式发布的信息与软件； 4. 专利中显示的或公开的专利申请且可以在任何专利办公室取得的（除保密命令覆盖的不得公开的内容除外），或EAR第734.10规定的其他专利信息与软件； 5. 为非专有系统（non-proprietary system）的描述；或 6. 列于贸易管制清单（Commerce Control List，又称“CCL”）中大类9（航天航空与推进）产品组E（技术）注释2的遥测数据（telemetry data）（见EAR第774部分附录1）。 那么，什么是“已发布”？在EAR第734.7(a)章节（章节名称为：“已发布”）[36]规定了如下：除EAR第734.7(b)（即：下文第（三）段第1节提到的要求）和(c)段（即：有关对ECCN0A501相关软件或技术的管制）中规定的情况外，当未加密的“技术”或“软件”被进一步传播时通过下述5种之一的任何方式已不受限制地公开，那么该“技术”或“软件”是“已发布”的，继而不受到EAR管制： 1. 任何希望获取或购买已发布信息的个人均可无限制地订阅。 2. 向公众开放和提供的图书馆或其他公共馆藏，公众可以从中获取有形或无形文件。 3. 在大会、会议、研讨会、贸易展或展览会上无限制分发，通常对感兴趣的公众开放。 4. 以任何形式（例如，不一定以出版形式）公开传播（即，无限制发布），包括在互联网上向公众开放的网站上发布。 5. 提交书面作文、手稿、演讲、计算机可读数据集、公式、图像、算法或其他一些知识的陈述，其目的是如果被接受用于出版或演讲，这些信息将被公开提供。 由此可见，EAR豁免了大多数以开源形式呈现的软件和技术，即明确该等开源软件不受到EAR管制，其使用不受制于EAR。 (三) 用来加密的软件，即加密软件（常见类别ECCN 5D002）是否受EAR管制？ 1. 加密软件不受EAR管制的2个条件 加密软件如果符合如下2个条件，则不受EAR管制[37]： 1. 是“公开可得”的加密的对象代码软件且ECCN 5D002；并且 2. 其相应的源代码符合EAR第742.15(b)章节规定的规格，即： 根据EAR的定义，“非标准加密”是指“结合或使用专有或未公布的加密功能实施‘加密’，包括尚未被正式认可的国际标准机构（如IEEE、IETF、ISO、ITU、ETSI、3GPP、TIA和GSMA）采用或批准的，以及尚未公布的加密算法或协议。”[38] 符合上述2项标准，即使是对象代码也同样不受EAR管制。 2. 美国商务部工业与安全局（BIS）进一步举例 对于上述，BIS进一步举例如下[39]： 此外，虽然开源代码本身因其公开可得的，而不受EAR管制，虽然软件开发中会引用开源代码，但一个软件不能仅仅因为它包含或引用公开可用的开源代码而被视为公开可用。相反，一个具有加密功能的软件则需根据EAR将其作为一个整体进行评估。
五、软件开发者须注意的出口管制合规与风险控制
如上所述，从合规与风控角度，我们建议软件开发者需要关注如下： 1. 关注所使用的开源软件所在的开源基金会、代码托管平台对于该开源软件的ECCN分类以及是否受EAR管制的声明。 2. 关注开源许可证中是否存在有关出口管制相关约定与声明。 3. 关注所使用的开源软件是否符合EAR规定的“已公开”。 4 是否使用加密软件？判断加密软件是否是已公开，且是否是实施标准的且公开可得的加密技术，或是，是否实施“非标准加密技术”。 5. 若以对象代码形式公开加密软件，则确保该软件的源代码也是公开可得。 6. 虽然软件开发中包含或引用了不受EAR管制的开源代码，但软件作为整体仍需进行是否受EAR管控的评估。
六、有关我国开源生态健康有序发展的建议
如业务共识，软件的研发离不开引用开源软件，即便是在国际主流的开源社区公开的开源代码上进行修改并进一步开源，其衍生的开源代码亦须得遵从该开源社区的约定。但又不得不承认，“我国开源社区主要还以利用国外开源代码、依托国外开源社区为主，总体上仍是国际开源社区的次生社区，呈现依附性强、自主性弱的特点，存在较大的开源产业链断供风险”[40]。加之，国际主流的开源基金会、开源项目、开源许可证均诞生于美国或由美国公司掌控[41]，越来越多的国际主流开源基金会也公开声明其遵守美国的出口管制规定。因此，在目前国际局势下，很难预测未来开源软件是否会一并受到波及。 因此，从长远来看，一方面，我国急需加强在国际主流开源社区中增加话语权，增加开源社区的贡献、交互与使用，以加强在开源社区中的影响力，另一方面，需要完善中国法律体系，尽快不光在开源内容上而且在法律实践中与国际接轨，促成我国自身开源生态事业的健康有序发展。 （锦天城律所倪好对本文亦有贡献）
注释 [1]https://www.ndrc.gov.cn/wsdwhfz/202112/t20211228_1310313.html [2]https://oschina.gitee.io/opensource-guide/guide/ [3]https://www.apache.org/licenses/exports/ [4]https://www.linuxfoundation.org/resources/publications/understanding-us-export-controls-with-open-source-projects [5]https://www.eclipse.org/ [6]https://www.eclipse.org/legal/legalfaq.php#cryptography [7]https://www.cncf.io/ [8]https://www.cncf.io/blog/2019/06/11/cncf-openness-guidelines/ [9]https://www.cloudfoundry.org/ [10]https://www.cloudfoundry.org/terms-of-service/ [11]https://www.openstack.org/ [12]https://docs.openstack.org/security-guide/compliance/certification-and-compliance-statements.html [13]https://www.fsf.org/ [14]https://www.gnu.org/licenses/gpl-faq.html#ExportWarranties [15]https://opensource.org/ [16]https://blog.opensource.org/exporting-open-source-from-the-us/ [17]https://oschina.gitee.io/opensource-guide/guide/ [18]https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls [19]https://about.gitlab.com/handbook/legal/trade-compliance/ [20]https://github.com/apache/hadoop/blob/trunk/LICENSE.txt [21]https://www.mit.edu/~amini/LICENSE.md [22]https://www.techtarget.com/whatis/definition/BSD-licenses [23]https://www.mongodb.com/licensing/server-side-public-license [24]https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html [25]https://www.gnu.org/licenses/gpl-3.0.html [26] 见https://www.bis.doc.gov/index.php/regulations/export-administration-regulations-ear [27]https://www.bis.doc.gov/index.php/regulations/export-administration-regulations-ear [28] https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html [29] 见EAR第734.13条（2023年2月24日更新） [30] 见EAR第734.14条（2023年2月24日更新） [31] 见Guidance on Reexports/Transfers (in-country) of U.S.-Origin Items or Non-U.S.-made Items Subject to the Export Administration Regulations (EAR)： https://www.bis.doc.gov/index.php/licensing/reexports-and-offshore-transactions [32] 见EAR第734.15条（2023年2月24日更新） [33] 见EAR第734.16条（2023年2月24日更新） [34] 见EAR第734.17条（2023年2月24日更新） [35] 见EAR第734.3(b)(3)条（2023年2月24日更新） [36] 见EAR第734.7(a)条（2023年2月24日更新） [37] 见EAR第734.7(b)条（2023年2月24日更新） [38]https://www.bis.doc.gov/index.php/documents/regulations-docs/2344-part-772-definitions-of-terms-2/file [39] 见https://www.bis.doc.gov/index.php/policy-guidance/encryption/1-encryption-items-not-subject-to-the-ear [40] 见https://www.ndrc.gov.cn/wsdwhfz/202112/t20211228_1310313.html [41]https://www.ndrc.gov.cn/wsdwhfz/202112/t20211228_1310313.html
