随着俄乌局势升级，美国科技巨头相继宣布制裁俄罗斯。在全球最大的开源及私有软件项目托管平台Github宣布遵守美国政府制裁规定之后，全球最大的独立开源软件公司SUSE、美国开源软件巨头红帽、主流开源容器引擎Docker等纷纷宣布停止与俄罗斯的业务，这三家加入封禁阵营的消息，再次震动了一向推崇“自由、平等、相互尊重”的开源界。

　　走出去智库（CGGT）观察到，此次俄乌冲突下的科技制裁，给国内开源界再次敲响了警钟。由于开源的高度开放性，可以不断复制、修改、再开源社区的源代码，使得开放源代码涉及到知识产权的归属、许可、授权等法律问题，而按照国际通行做法，知识产权会受到各国出口管制的限制。对此，我国已高度重视开源的推动，“十四五”规划和2035年远景目标纲要提出，要“支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务”。

　　如何做好开源软件的跨境合规管理？今天，走出去智库(CGGT)刊发相关分析文章，供关注开源软件出口管制应对的读者参阅。

　　1、从对四大经济体的出口管制法规分析看，只有美国《出口管制条例》（ERA）提及了开源软件的概念，并提出了对开源软件进行管控的细则。在日本的管控清单中，甚至没有提及软件；中国和欧盟的法规虽然提及了软件，但是却没有提及开源软件的概念，也就没有专门针对开源软件的管控制度。

　　2、正确识别研发活动中使用的所有开源软件是识别受EAR管辖开源软件的基础，但目前业界尚无一个100%正确识别的成熟可靠的方案，实践证明采用工具识别与人工确认相结合的方式，既提高了开源软件识别效率和准确性，避免了纯人工识别差错问题，同时也解决了因扫描工具数据库更新不及时而可能产生的识别不全的问题。

　　3、虽然开源软件的使用已完全遵循了美国的出口管制，但并不代表没有风险。一旦美国修改 EAR，将高性能软件、EDA 软件等一些核心基础软件加入到管制中，并且将目前“备案即不被管制”修改为“备案且需要被管制”，那就意味着大量核心开源项目将受到出口管制。

　　开源软件是源代码可以任意获取的计算机软件。在获取开源软件源代码的基础上，任何人都能查看、修改和分发他们认为合适的代码。开源是信息社会的生产方式之一，特点是大维度的协作与网络服务化，全球范围的源代码开放，是开源软件的一个特征。我国的开源软件技术已经全面进军操作系统、云原生、人工智能、大数据等主要领域，例如在容器技术、微服务技术、DevOps技术上，均有中国的开源贡献。开源软件已在各行各业得到广泛应用。作为托管于开源社区的开源软件，必须受到相关开源社区的管理约束。由于各国的法律法规存在差异，基于社区由不同国家发起、托管平台存在于不同国家、以及这些开源软件的版本归属差异，这些开源项目还会受制于不同的“其它外部的法律法规”，比如“出口管制要求”。美国曾将中国某公司及其附属公司列入出口管制“实体名单”，随后美国谷歌公司宣布将停止为其提供安卓（Andriod）系统的技术支持与服务，而安卓系统一直是世界知名的开源项目。

　　软件产品是作为当今大部分高科技企业最为重要的产品形态之一，已大量涉及开源软件，进行开源软件相关合规政策和合规遵循的研究显得尤为重要。本文主要从出口管制的角度，研究开源软件相关的法规政策和及其影响，通过对企业当前的合规管控实践，分析开源软件的管控现状和差距，提出改进措施，并说明开源软件在未来的使用过程中可能面临的风险。

　　国家出于政治、经济、军事和对外政策的需要，制定限制产品出口的法律和规章，以对出动实行控制。在开源软件的研究过程中，我们针对世界主要的四个经济体进行了扫描，汇总其对开源软件进行管控的要求。这四个主要经济体分别是美国、日本、欧盟和中国。这四个经济体的主要出口管制法规如下：

　　在美国，开源软件是否受出口管制的限制？一个广为流传的观点是，软件的源代码因受到的保护而不被管制。根据1995年伯恩斯坦诉美国司法部（Bernstein v. Department of Justice）案，软件源代码属于的范畴，不能被政府部门管制。但很少有人提到，该案的裁决未生效。因此，伯恩斯坦案并非有法律效力的判例，不能简单地得出结论认为软件的源代码因受到的保护而不能被管制。实际上恰恰相反，软件的源代码只要没有实现“公开可获得”（Publicly available），仍然要受到美国出口管理条例（Export Administration Regulations，以下简称“EAR”）的管辖。

　　美国对于开源软件的管辖基于“已公开”（Published）或者“公开可获得”（Publicly available）的概念。已公开的信息可以任意复制、传播，对于已公开的信息再进行管控是不可能做到的，因此立法者将已公开的信息排除出了EAR的管辖范围，即根据EAR 734.3(b)(3)，“已公开”的信息和软件不受EAR管辖。开源软件由于其源代码已经在互联网上的网站或者网络社区进行了公开，可以任意下载和传播，因此开源软件在原则上由于其公开的特性不受EAR管辖。

　　但同时美国出口管制法对于加密技术非常重视，美国立法者认为加密技术有可能会被利用来危害美国的国家安全，因此他们将包含加密功能的开源软件进行特别对待。含有加密功能的软件，如果属于美国开发的代码或者来源于美国管辖的开源社区，且按照功能性能被分类为5D002,那么即使该软件的源代码即使已经在网络上进行公开，这个软件仍然是受EAR管辖的。如果美国以外的人员想要下载和使用这个软件，则必须要获取出口授权。但是美国商务部工业与安全局（Bureau of Industry and Security，以下简称“BIS”）提供了一个途径，来使这样的开源软件不受EAR管辖。软件作者或者使用者可以将这个软件的源代码发往BIS和美国国家安全局（National Security Agency，以下简称“NSA”）的特定邮箱进行备案，这样这个软件就不再受EAR管辖。如果软件的源代码变动频繁，软件作者或者使用者也可以将下载该软件源代码的网址以及软件名称发送给BIS和NSA的特定邮箱进行备案，就无须重复性的将不断变更的软件源代码发送给BIS和NSA的特定邮箱。此外，对于含有加密功能的目标代码（即源代码经过编译后形成机器码），如果来源于美国，必须要在将其对应的已公开源代码进行备案后，此目标代码才能不受EAR管辖。

　　从对四大经济体的出口管制法规分析看，只有美国的EAR提及了开源软件的概念，并提出了对开源软件进行管控的细则。在日本的管控清单中，甚至没有提及软件；中国和欧盟的法规虽然提及了软件，但是却没有提及开源软件的概念，也就没有专门针对开源软件的管控制度。下面说明中国出口管制法对软件的管控将如何影响开源软件：

　　中国出口管制法对软件的管控仍集中在软件的功能、性能上，开源软件的本身公开的性质，并不能使其免于中国出口管制法的管辖。只要软件本身在中国出口管制法下辖的清单中，如两用物项清单，那么该软件即使是开源软件，出口也可能需要出口授权。特别的，根据《中华人民共和国出口管制法》第二条的规定，从中华人民共和国境内向境外转移管制物项，属于“出口”；中华人民共和国公民、法人和非法人组织向外国组织和个人提供管制物项也属于“出口”（也称之为“视同出口”（Deemed export））。

　　因此中国出口管制法定义下的开源软件“出口”或者“视同出口”涵盖的范围将非常之广，运营于中国境内的不管是企业还是个人都需要对此特别注意。下面对于涉及开源软件出口或者非出口的场景进行举例说明。

　　（1）国内某企业决定开源其研发的一个软件，在选定开源许可证后，将GitHub作为代码托管和后续协作的平台。我们知道在2018年6月，微软宣布75亿美元收购GitHub，微软是一家美国公司，而GitHub的具体运营公司也是位于旧金山的美国公司，均属于外国组织，而GitHub的代码存储空间主要也在美国。实际上，提及了GitHub网站、企业服务器以及用户上传的产品、信息可能受贸易管制法规包括EAR的约束，并详细规定了用户只能根据适用法律（包括美国出口管制和制裁法律）访问、使用。因此，这种形式的源代码开源，如果涉及禁止或者限制出口的软件技术，有很大可能被主管部门认定属于“出口”。

　　（2）国内某企业决定将其研发的机器学习程序捐赠给Linux基金会。假设这项机器学习程序有着先进的算法，属于禁止出口的技术，而Linux基金会是根据美国联邦税法501(c)(3)成立的非盈利机构，属于外国组织，则该企业向Linux基金会捐赠源代码及相关材料的行为，也有很大的可能被主管部门认定属于“出口”。

　　（3）国内某企业对通用性公开（General Public License，以下简称“GPL”）许可证项下的Linux内核作出了重大技术贡献，该项创新属于禁止出口的技术。根据GPL开源许可证，该企业应当在相应的国外社区公开源代码，那么这种情况下，也有很大的可能被主管部门认定属于“出口”。这里涉及到的国内法与开源许可证的冲突及解决，不是本文的研究范围，本文不展开论述。

　　国内某企业决定将其软件开源到gitee上，但该软件属于限制出口技术。gitee运营公司是位于深圳的中国注册公司，而源代码的存储空间也应在我国境内，虽然网络具有全球可访问性，但不应认定为“出口”。需要指出的是，如果该软件涉及国家保密规定的，应遵守相关的要求。

　　由于在立法时没有提及开源软件的概念，欧盟同样存在类似问题，有可能对于开源软件存在过度管辖。而日本由于其管控清单中没有将软件单独列出，因此日本在开源软件的出口和转移方面要宽松的多，不存在法律上的障碍。

　　一个完整的开源生态包含开源基金会（组织）、开源项目、开源许可证和代码托管平台等多方面要素，它们各自的条款声明和受到的法律制约都不尽相同。

　　开源基金会管理开源项目，但基金会的管理办法差异较大，而基金会旗下的开源项目也可以选择不同管理办法。举例：

　　·Linux 基金会自身的管理办法不受美国出口管制，其旗下的项目包括Linux Kernel等默认遵循该管理办法，但其分布式存储项目Ceph明确指定司法管辖权归属美国加州，并要求使用并出口者遵循美国出口管制，就属于Linux基金会中的特例；

　　·Apache基金会的管理办法明确说明遵循美国出口管制，旗下绝大多数项目如 Hadoop、Spark等，在备案（5D002）后即不受EAR出口管制；

　　·Mozilla基金会明确声明司法管辖权归属加州。根据前述司法管辖区与出口管制的关系，Mozallia基金会声明司法管辖权，只是表示出现各类纠纷都将以加州Santa Clara的法庭裁决为准。如前所述，这并不表示其管理的开源项目默认受到出口管制；

　　·RISC-V基金会隶属于Linux基金会，没有特别声明受美国出口管制，因此RISC-V基金会拥有的RISC-V开放指令集标准并不会受美国出口管制。值得注意的是，RISC-V 基金会的会员条款中也指明了其司法管辖权在美国特拉华州。根据前述司法管辖权与出口管制的关系，RISC-V基金会声明司法管辖权，表示所有围绕会员条款产生的纠纷都将交由指定法庭裁决，但并不表示其管理的开源项目默认受到出口管制。

　　常用开源许可证如GPL、LGPL、BSD、MIT、Mozilla、Apache，均未涉及与政府出口管制无关的声明。而且开源项目对于许可证条款的遵循与变更比较容易，所以开源许可证方面的出口管制风险比较小。

　　从对GitHub、SourceForge和Google Code三个代码托管平台的研究来看，该三个平台均明确声明遵守美国出口管制条例，并且司法管辖权均在加州（即需按加州法律解决纠纷）。

　　以 GitHub为例，GitHub明确声明其GitHub Enterprise Server被出口管制，不能出口到被制裁国家。至于GitHub网站的普通功能，由于架设在美国的GitHub服务器的上传和下载的行为都需要遵从出口管制和美国法律，所以其正常使用是可能会被管制的。亦即，GitHub上的开源项目代码在遵守项目自身的开源许可证的同时, 也可能作为GitHub上的信息（Information）遵从出口管制和美国法律。概述中提到的事件，也很可能因为GitHub因素使其访问开源项目受到影响。

　　开源项目如何规避出口管制风险？存在四种情况，但都需要开源项目发起人或开发者支持与配合：

　　·对于已存放于GitHub的开源项目，若同时存放于美国以外其他托管平台，且开发者分别独立提交更新到GitHub与其他托管平台，且开发过程中不从GitHub下载任何信息，那么从美国以外的托管平台获取开源项目不受美国出口管制；

　　·对于已存放于GitHub的开源项目，若发起人本地拥有副本，且未从GitHub上下载更新，那么发起人可在美国以外其他托管平台创建开源项目，并将副本上传到该托管平台。此后开发者分别独立提交更新到GitHub与美国以外的托管平台，且开发过程中不从GitHub下载任何信息,那么从美国以外的托管平台获取开源项目不受美国出口管制；

　　·对于新启动的开源项目，发起者可在美国以外的托管平台和GitHub上同时创建项目，且开发者分别独立提交更新到美国以外的托管平台与GitHub，且开发过程中不从 GitHub 下载任何信息，那么从美国以外的托管平台获取开源项目不受美国出口管制；

　　·对于新启动的开源项目，发起者可直接在美国以外的托管平台创建项目，其后开发者向该托管平台更新，那么从该托管平台获取开源项目不受美国出口管制。

　　从以上分析可以看出，虽然并非所有的开源基金会、开源社区管理的源代码都受到美国出口管制的管辖，但几乎所有位于美国的国际开源组织或项目，无一例外地遵守美国的出口管制政策。

　　在实际使用开源软件时，为了增强我们对该开源软件具备足够的驾驭能力，选择开源软件项目时，需要考虑能够随时不受限制地引用其全生命周期过程中的版本、技术，以满足引用开源软件产品全生命周期经营管理需要：

　　·选择开源软件时，需要仔细阅读所属开源社区/开源基金会的声明、项目本身的声明、所用的开源许可证声明等三个声明，以了解受各国出口管制管辖及约束的情况。对所用开源软件相关的上述声明需要进行全生命周期的跟踪，若其条款有所变更需要进行快速响应，分析其出口管制影响；

　　·开源托管平台同时受EAR出口管制和美国司法管辖权的限制，是开源最大的风险。在同样条件下，优先选择国内开源社区下的开源软件；

　　·同时做好受出口管制后，是否有其它应对手段，如开源软件替代、具备开源软件守护能力等；

　　对所选开源软件的许可证进行全生命周期管控，预防遵循许可证变更，甚至引入新的受出口管制影响的许可证等情况。

　　在当前的高科技研发研发公司中，开源软件几乎涉入了每一个软件研究项目。近年来，业界各企业纷纷开始进行开源合规治理，通过不断完善，部分企业目前已形成一套开源软件的管理体系，管理系统主要包括开源的安全、许可证和出口管制三部分。这里主要讨论在出口管制方面的合规管控实践。尽管如上面所述，四大主要经济体中的日本、欧盟和中国的出口管制或没有提及软件，或是没有开源软件的概念，比如中国的出口管制政策主要通过对最终产品的功能性能来确认是否进行关注，但实质上都有对使用开源软件的“隐形”出口管控。这里笔者以国内某企业对开源软件的合规管控实践，讨论对开源软件管控有更明确和严格要求的美国EAR法条的遵从。

　　按照 EAR 的规定（734.3(b)(3)、734.7(b) 和 742.15(b)），即ECCN为5D002的加密开源软件仍受EAR管辖，除非其目标代码和源代码按要求向BIS和ENC Encryption Request Coordinator进行了备案（notification）。尽管进行备案不是EAR的强制要求，但企业为减少出口管制合规风险而选择了对ECCN为5D002的加密开源软件进行备案管理要求，对研发过程中使用的受EAR管辖开源软件采取了管控措施。

　　正确识别研发活动中使用的所有开源软件是识别受EAR管辖开源软件的基础，但目前业界尚无一个100%正确识别的成熟可靠的方案，实践证明采用工具识别与人工确认相结合的方式，既提高了开源软件识别效率和准确性，避免了纯人工识别差错问题，同时也解决了因扫描工具数据库更新不及时而可能产生的识别不全的问题。

　　识别出开源软件后，就需要对这些开源软件进行分析，判断其是否受EAR管辖。为此，总结了一个科学可行的判别的方法，我们称之为受EAR管辖开源软件识别四要素法，如下图所示：

　　简单地说如果一个开源软件同时满足以上4个条件，我们就认为这个开源软件是受EAR管辖的开源软件。

　　该实践中要求对识别为受EAR管辖的开源软件在软件版本对外发布前必须完成向BIS备案，通过备案将受EAR管辖的开源软件变为不受管辖开源软件，从而减少出口管制合规风险。具体做法是通过email通知BIS和ENC Encryption Request Coordinator，告之加密源代码所在的URL或网络地址，每次URL发生变化，均需再通知BIS和ENC Encryption Request Coordinator，但源代码更新或修改不需再次通知。

　　企业从公司维度对开源软件的备案工作进行集中管理，一方面能够确保来源的可靠性和可信性；另一方面，实现了资源共享，避免了不同研发单位对同一个受EAR管辖开源软件的重复备案，减少了资源消耗，提高了效率。

　　作为开源软件应用者，同时也是开源软件的贡献者。常见的开源对外贡献有两种方式，一种是直接向开源社区贡献自研代码，还有一种在在开源社区主导建设项目。

　　为了实现开源社区的共建，实现技术和代码的共享，某些情况下，研发项目在从开源社区获取开源项目的同时，也需要向开源社区共享源代码。为了遵循出口管制的政策，对于涉及受EAR管控的技术或软件的软件不能作为开源软件公开到开源社区中。该实践中对开源代码对外贡献管控要求是：项目组在向开源社区提交源代码前，需要识别是否包含受控软件，受控软件不能作为开源软件发布；涉及受控技术的受控项目的软件源代码也不能对外贡献代码。

　　我国目前有很多企业都有其主导的开源软件建设项目，代码托管在Linux基金会，同时，在开源中国社区上建设了镜像。开源中国是目前最大的开源技术社区。虽然，开源项目在托管平台的选择上有自主权，但是绝大部分中国项目组在国际大平台托管代码时，都会选择同时在国内建立镜像，不仅中国项目，开源中国也同国际上很多大的平台签署了相关协议，一方面能不断发展开源社区，同时也是对国内开源代码使用的安全性的一个长远保障措施。

　　在上文的开源软件管控实践中，企业对开源软件已制定比较全面的管控措施，出口管控合规的风险已完全被管控。但就执行与现有政策要求还存在一定差异，体现在目前EAR法条中仅管控涉及非标准加密算法的开源软件，也就是说，只有涉及非标准加密算法的开源软件才是美国出口管制关注的对象，其他都不在其管辖范围内，无需向其备案，这个政策在2021年3月份变更。但是目前如果依然按照原有的要求进行备案，对所有加密的开源软件都进行备案，管控的尺度更高。虽然这种差距虽然并不带来合规风险，但却会加重备案工作量。

　　为了消除这种差距，企业合规部门与业务单位不断讨论改进措施和方案，目标是完全遵循EAR的要求，仅针对涉及非标准加密算法的开源软件向BIS备案。这个方案中，最关键的一点是如何确定加密算法是否为标准算法，执行落地方案建议如下：

　　·首先依据法条中对标准加密算法的说明，确定目前已使用的标准加密清单，但此清单并不涵盖所有的标准加密算法，仅供使用人员参考；

　　·使用人员负责对加密开源软件的加密算法标准和非标准进行判定，判定方法是参考标准加密算法清单，如果加密软件使用的加密算法在此清单内，则认为是标准加密算法；

　　·如加密软件使用的算法不在此清单内，则需要根据非标准加密算法的定义进行判定，给出是否非标准加密算法的判定，判定依据：该算法在何种国际标准中公开发布；

　　·管理人员审查不在标准加密算法清单中的标准加密算法的判断依据。如果判断依据可靠，则将改算法加入标准加密算法清单；否则将涉及非标准加密算法的开源软件向BIS备案。

　　在该实践中，虽然开源软件的使用已完全遵循了美国的出口管制，但并不代表没有风险。从前面概述中的案例可以看出，可能存在一种极端的情况，一旦美国修改 EAR，将高性能软件、EDA 软件等一些核心基础软件加入到管制中（这并非不可能，2018 年 11 月，美国 BIS 曾就 AI 和机器学习等新兴技术是否加入管制名单征求公众意见），并且将目前“备案即不被管制”（这其中包含了 ASF 几乎所有开源项目），修改为“备案且需要被管制”，那就意味着大量核心开源项目将受到出口管制。

　　换句话说，如果我们使用的开源软件较多都来源于这些有影响力的外部社区，而这些社区又都受制于国家的出口管制政策，那么这些开源软件始终都将受到出口管制政策变化的影响。我们已经清楚地认识到，出口管制的本质是，国家不希望其在意的东西（物项）转移给其不喜欢的国家/人（禁运国家/受限制主体），目前国际局势风云变化莫测，如果一旦形式突变，开源软件作为严重影响各行各业的一把双刃剑，把其作为对付一个国家或企业的武器存在很大可能。

　　所以从长远来看，中国必须建立起自己有影响力的开源项目托管平台，发展自身的开源力量，并以更开放的方式吸引全世界的开源爱好者。中国在2008开始建设开源中国社区，目前已经建设成国内最大的开源技术社区。国家在第十四个五年规划中，已经把“开源”列入规划。纵观中国企业，华为作为风险管理杰出企业代表，也早早意识到自己在开源软件这一块的风险，已经在操作系统、数据库、AI深度学习框架等基础软件在国内构建了完善的开源生态，成为中国开源的重要力量。

　　对于受开源软件和出口管制影响深远的企业，也有必要居安思危，未雨绸缪，多作贡献。

　　[九] Linux 基金会：《Linux 基金会发布白皮书，解释如何应对美国对开源项目的出口管制》2020.7

　　[十] 中国开放指令生态（RISC-V）联盟：《开源项目风险分析与对策建议》。