开源软件的网络安全问题

开源软件网络安全的法律问题受到境外的进出口监管和境内《网络安全法》的双重考验。境外国家基于主权的出口规则穿透并从软件、源码、人员、平台等角度分别对开源进行监管，本国《网络安全法》的体系规则则对开源的繁荣与安全之间的平衡重新设定了评价机制。在两者多因素作用下， 开源软件的网络安全实践活动需要审慎调整以迎合或规避监管规则变化带来的深刻挑战。

本文分析了开源软件的协议安全问题，以事件导向引入并回答了合同与进出口监管冲突的若干问题，并以此为契机对开源软件的网络安全法律问题进行了梳理，提出了相应建议。

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）从网络安全法的基本法出发，将其作为一类特殊的安全审查和出境评估类型。

最后，开源的核心在于软件开发者的著作权利义务设计与分配，应从宏观与微观上给予开源软件开发以充分支援。这些支援不在于简单的资金投入或文件指引，而在于通过降低人员流动的成本，并特别注重未被定义为高端人才的人员价值和促进开源繁荣的作用，以开源代码和开源协议的参与度作为评价开源安全与繁荣的主要机制。