中國開源軟件：出口管制對其影響及未來展望
作者：邱夢赟 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
