content
I. Overview
2. Countries’ export control policies for open source software
(1) U.S. Export Control Regulations on the Control of Open Source Software
(2) Control of open source software by export control regulations of China, the European Union and Japan
3. Export Control Strategies of Important Open Source Communities
(1) International open source organization project export control policy
1. Open Source Foundation
2. Open Source License
3. Code hosting platform
(2) The impact of community statements on the use of open source software
4. Open source software export control compliance control practice
(1) Open source software application management and control
1. Identification of open source software governed by the EAR
2. Open source software filing under the jurisdiction of EAR
(2) Open source external contribution control
1. Self-developed code contribution
2. Open source project construction
V. Open source software management and control improvement measures and risk analysis
(1) Open source software management and control gaps and improvements
(2) Potential risk analysis of open source software
6. References
I. Overview
Open source software is computer software whose source code is freely available. With access to the source code , anyone can view, modify, and distribute the code as they see fit. Open source is one of the production methods of the information society. It is characterized by large-scale collaboration and network service. The global open source code is a feature of open source software. my country's open source software technology has fully entered major fields such as operating systems, cloud native, artificial intelligence, and big data. For example, in container technology, microservice technology, and DevOps technology, there are open source contributions from China. Open source software has been widely used in all walks of life. As open source software hosted in an open source community, it must be subject to the management constraints of the relevant open source community. Due to the differences in laws and regulations in different countries, based on the fact that the community is initiated by different countries, the hosting platform exists in different countries, and the version attribution of these open source software is different, these open source projects are also subject to different "other external laws and regulations", such as " Export Control Requirements". The United States once placed a Chinese company and its affiliates on the "entity list" for export control, and then the United States Google announced that it would stop providing technical support and services for the Android system, which has always been a world-renowned open source project. .
Software products are one of the most important product forms for most high-tech companies today, and a large number of open source software has been involved. It is particularly important to conduct research on open source software-related compliance policies and compliance. This paper mainly studies the regulations and policies related to open source software and their impact from the perspective of export control. Through the current compliance management and control practices of enterprises, it analyzes the current status and gaps of open source software management and control, proposes improvement measures, and explains the future development of open source software. Risks you may face during use.
2. Countries’ export control policies for open source software
For the needs of political, economic, military and foreign policy, the state formulates laws and regulations restricting the export of products to exercise control over export activities. During our research on open source software, we scanned four of the world's major economies to summarize their requirements for regulating open source software. The four major economies are the United States, Japan, the European Union and China. The main export control regulations for these four economies are as follows:
Table 1 Names of export control laws and regulations in the four major economies
(1) U.S. Export Control Regulations on the Control of Open Source Software
Is open source software subject to export controls in the United States? A widely held view is that the source code of software is not regulated because it is protected by free speech. According to Bernstein v. Department of Justice (Bernstein v. Department of Justice) in 1995, software source code falls under the category of freedom of speech and cannot be regulated by government agencies. But it was rarely mentioned that the ruling in the case did not take effect. Therefore, the Bernstein case is not a valid precedent, and one cannot simply conclude that the source code of software cannot be regulated because it is protected by free speech. In fact, on the contrary, as long as the source code of the software is not "Publicly available", it is still subject to the jurisdiction of the US Export Administration Regulations (hereinafter referred to as "EAR").
The US jurisdiction over open source software is based on the concept of "Published" or "Publicly available". Disclosed information can be copied and disseminated arbitrarily, and it is impossible to control the disclosed information. Therefore, the legislator excluded the disclosed information from the jurisdiction of the EAR, that is, according to EAR 734.3(b)(3 ), "public" information and software are not governed by the EAR. Open source software can be downloaded and disseminated arbitrarily because its source code has been made public on websites or online communities on the Internet. Therefore, open source software is not subject to the EAR due to its public characteristics in principle.
But at the same time, U.S. export control laws attach great importance to encryption technology. U.S. lawmakers believe that encryption technology may be used to endanger the national security of the United States, so they treat open source software containing encryption functions specially. If the software containing encryption function belongs to the code developed in the United States or originates from the open source community under the jurisdiction of the United States, and is classified as 5D002 according to the functional performance, then even if the source code of the software has been made public on the Internet, the software is still subject to restrictions. governed by the EAR. If persons outside the United States want to download and use this software, an export authorization must be obtained. But the U.S. Department of Commerce's Bureau of Industry and Security (BIS) provides a way to exempt such open source software from the EAR. The software author or user can send the source code of the software to the specific mailboxes of the BIS and the National Security Agency (hereinafter referred to as "NSA") for the record, so that the software is no longer under the jurisdiction of the EAR. If the source code of the software changes frequently, the software author or user can also send the website for downloading the source code of the software and the name of the software to the specific mailboxes of BIS and NSA for recordation, and there is no need to repeatedly send the constantly changing software source code. Specific mailboxes for BIS and NSA. In addition, for object code with encryption function (that is, the source code is compiled to form machine code), if it is sourced from the United States, the corresponding open source code must be filed before the object code is exempt from the EAR jurisdiction.
(2) Control of open source software by export control regulations of China, the European Union and Japan
From the analysis of the export control regulations of the four major economies, only the EAR of the United States mentioned the concept of open source software and proposed detailed rules for the control of open source software. In Japan's control list, software is not even mentioned; although Chinese and EU regulations mention software, they do not mention the concept of open source software, and there is no control system specifically for open source software. The following illustrates how the control of software by China's export control laws will affect open source software:
The control of software under China's Export Control Law still focuses on the functions and performance of the software. The open-source nature of open source software does not make it exempt from the jurisdiction of China's Export Control Law. As long as the software itself is on the list under China's export control law, such as the dual-use item list, export authorization may be required for the software even if it is open source software. In particular, according to the provisions of Article 2 of the "Export Control Law of the People's Republic of China", the transfer of controlled items from the territory of the People's Republic of China to abroad is "export"; citizens, legal persons and unincorporated organizations of the People's Republic of China to foreign organizations and individuals The supply of controlled items is also an "export" (also known as a "deemed export").
Therefore, the scope of "export" or "deemed export" of open source software defined by China's Export Control Law will be very wide, and both companies and individuals operating in China need to pay special attention to this. The following provides examples of scenarios involving export or non-export of open source software.
Scenarios that may be identified as open source software exports:
(1) A domestic enterprise decides to open source a piece of software it has developed, and after selecting an open source license, uses GitHub as a platform for code hosting and subsequent collaboration. We know that in June 2018, Microsoft announced the acquisition of GitHub for $7.5 billion. Microsoft is an American company, and the specific operating company of GitHub is also an American company located in San Francisco, all of which belong to foreign organizations, and GitHub’s code storage space is mainly in the United States. . In fact, GitHub.com also mentioned that the GitHub website, enterprise servers, and products and information uploaded by users may be subject to trade control regulations, including EAR, and specified that users can only comply with applicable laws (including U.S. export control and sanctions laws). ) to access, use GitHub.com. Therefore, this form of open source source code, if it involves software technology whose export is prohibited or restricted, is likely to be identified as "export" by the competent authority.
(2) A domestic enterprise decides to donate its machine learning program to the Linux Foundation. Assuming that the machine learning program has advanced algorithms and is an export-prohibited technology, and that the Linux Foundation is a non-profit organization established under 501(c)(3) of the U.S. federal tax code, it is a foreign The act of donating source code and related materials is also highly likely to be identified as "export" by the competent authorities.
(3) A domestic enterprise has made significant technical contributions to the Linux kernel under the General Public License (hereinafter referred to as "GPL") license, and this innovation is a technology that is prohibited from exporting. According to the GPL open source license, the enterprise should disclose the source code in the corresponding foreign community. In this case, it is also very likely that the competent authority will consider it to be "export". The conflict and resolution of domestic laws and open source licenses involved here is not the scope of this article, and this article will not discuss it.
Scenarios that may not be considered open source software exports:
(1) A domestic enterprise decides to open source its software to gitee, but the software is a restricted export technology. The gitee operating company is a Chinese registered company located in Shenzhen, and the storage space of the source code should also be within the territory of my country. Although the network has global accessibility, it should not be regarded as "export". It should be pointed out that if the software involves state confidentiality regulations, relevant requirements should be complied with.
Since the concept of open source software is not mentioned in legislation, the EU also has similar problems, and there may be excessive jurisdiction over open source software. However, because Japan does not list software separately in its control list, Japan is much more lenient in the export and transfer of open source software, and there are no legal obstacles.
Three: Export Control Strategies for Important Open Source Communities
(1) International open source organization project export control policy
A complete open-source ecosystem includes open-source foundations (organizations), open-source projects, open-source licenses, and code hosting platforms, and other elements, all of which have different terms and conditions and legal constraints.
1. Open Source Foundation
The open source foundation manages open source projects, but the management methods of the foundation are quite different, and the open source projects under the foundation can also choose different management methods. Example:
-
The Linux Foundation's own management methods are not subject to U.S. export controls. Its projects, including Linux Kernel, follow this management method by default, but its distributed storage project Ceph clearly specifies that the jurisdiction belongs to California, USA, and requires users and exporters to follow the rules. U.S. export control is a special case in the Linux Foundation;
-
The management method of the Apache Foundation clearly states that it follows the US export control. Most of its projects, such as Hadoop and Spark, are not subject to EAR export control after filing (5D002);
-
The Mozilla Foundation expressly declares that jurisdiction is vested in California. According to the relationship between the aforementioned jurisdiction and export control, the Mozallia Foundation declares its jurisdiction, but only indicates that any disputes will be subject to the judgment of the court in Santa Clara, California. As mentioned earlier, this does not mean that the open source projects it manages are subject to export controls by default;
-
The RISC-V Foundation is affiliated with the Linux Foundation and has not specifically stated that it is subject to U.S. export controls, so the RISC-V open instruction set standard owned by the RISC-V Foundation is not subject to U.S. export controls. It is worth noting that the RISC-V Foundation's membership terms also specify that its jurisdiction is in Delaware, USA. According to the relationship between the aforementioned jurisdiction and export control, the RISC-V Foundation declares its jurisdiction, saying that all disputes over membership terms will be decided by a designated court, but it does not mean that the open source projects it manages are subject to export control by default .
2. Open Source License
Common open source licenses, such as GPL , LGPL, B SD, MIT, Mozilla, and Apache, do not contain statements that have nothing to do with government export controls. Moreover, it is easier for open source projects to follow and change license terms, so the risk of export control in open source licenses is relatively small.
3. Code hosting platform
From the research on the three code hosting platforms, GitHub, SourceForge and Google Code, all three platforms clearly state that they comply with the US export control regulations, and their jurisdiction is in California (that is, disputes need to be resolved according to California law).
Taking GitHub as an example, GitHub clearly states that its GitHub Enterprise Server is subject to export control and cannot be exported to sanctioned countries. As for the general functions of the GitHub website, since the uploading and downloading of the GitHub server set up in the United States are subject to export control and US laws, its normal use may be regulated. That is, the open source project code on GitHub may comply with export control and US laws as the information on GitHub while complying with the project's own open source license. The Huawei incident mentioned in the overview is also likely to be affected by the GitHub factor in this "entity list" incident, and its access to open source projects has been affected.
How can open source projects avoid export control risks? There are four situations, but all require the support and cooperation of the open source project sponsor or developer:
-
For open source projects that have been stored on GitHub, if they are also stored on other hosting platforms outside the United States, and the developers independently submit updates to GitHub and other hosting platforms, and do not download any information from GitHub during the development process, then the hosting platform outside the United States will Platform access to open source projects is not subject to U.S. export controls;
-
For open source projects that have been deposited on GitHub, if the sponsor has a local copy and has not downloaded updates from GitHub, the sponsor may create an open source project on another hosting platform outside the United States and upload the copy to that hosting platform. After that, developers independently submit updates to GitHub and hosting platforms outside the United States, and do not download any information from GitHub during the development process, so the acquisition of open source projects from hosting platforms outside the United States is not subject to US export controls;
-
For newly launched open source projects, the initiator can create the project on the hosting platform and GitHub outside the United States at the same time, and the developer independently submits updates to the hosting platform and GitHub outside the United States, and does not download any information from GitHub during the development process. then acquiring open source projects from hosting platforms outside the US is not subject to US export controls;
-
For newly launched open source projects, the initiator can directly create a project on a hosting platform outside the United States, and then the developer updates to the hosting platform, then the open source project obtained from the hosting platform is not subject to US export control.
It can be seen from the above analysis that, although not all source codes managed by open source foundations and open source communities are subject to US export controls, almost all international open source organizations or projects located in the United States comply with US export controls without exception. policy.
(2) The impact of community statements on the use of open source software
In the actual use of open source software, in order to enhance our ability to control the open source software, when choosing an open source software project, we need to consider the ability to refer to the version and technology in its entire life cycle at any time without restriction, so as to meet the requirements of referencing open source software. Full life cycle management of software products requires:
-
When choosing open source software, you need to carefully read the three declarations of the open source community/open source foundation to which it belongs, the declaration of the project itself, and the declaration of the open source license used to understand the export control jurisdiction and constraints of various countries. The above statement related to the open source software used needs to be tracked throughout the life cycle, and if its terms are changed, it needs to respond quickly and analyze its export control impact;
-
Under the same conditions, preference is given to open source software under the domestic open source foundation and open source community;
-
Open source hosting platforms are subject to both EAR export controls and U.S. jurisdictions, and are the biggest risk to open source. Under the same conditions, preference is given to open source software under the domestic open source community;
-
At the same time, after being subject to export control, whether there are other countermeasures, such as the replacement of open source software, the ability to protect open source software, etc.;
-
Make an open source benchmark library for the open source software you use, preferably a full version library of the open source components you use.
Full lifecycle control of selected open source software licenses to prevent compliance with license changes or even the introduction of new export control-affected licenses.
Four: Open source software export control compliance control practice
(1) Open source software application management and control
In the current high-tech R&D companies, open source software is involved in almost every software research project. In recent years, enterprises in the industry have begun to conduct open source compliance governance. Through continuous improvement, some enterprises have now formed a set of open source software management systems. The management system mainly includes three parts: open source security, licenses, and export controls. This section mainly discusses compliance control practices with regard to export control. Although as mentioned above, the export controls of Japan, the European Union and China among the four major economies either do not mention software, or do not have the concept of open source software. For example, China's export control policy is mainly based on the functional performance of the final product. Confirmation of concern, but in essence there are "invisible" export controls on the use of open source software. Here, the author discusses the compliance of the US EAR Act, which has more explicit and strict requirements for open source software control, based on the compliance management and control practice of open source software by a domestic enterprise.
In accordance with the provisions of the EAR (734.3(b)(3), 734.7(b) and 742.15(b)), encrypted open source software with ECCN 5D002 remains subject to the EAR unless its object code and source code are submitted to the BIS and ENC as required The Encryption Request Coordinator made a notification. Although filing is not a mandatory requirement of the EAR, in order to reduce the risk of export control compliance, enterprises have chosen to file and manage encrypted open source software whose ECCN is 5D002, and have taken control measures for the open source software under the jurisdiction of the EAR used in the research and development process.
1. Identification of open source software governed by the EAR
Correctly identifying all open source software used in R&D activities is the basis for identifying open source software under the jurisdiction of the EAR, but there is currently no mature and reliable solution for 100% correct identification in the industry. It improves the recognition efficiency and accuracy of open source software, avoids the problem of pure manual recognition errors, and also solves the problem of incomplete recognition that may occur due to the untimely update of the scanning tool database.
After identifying open source software, it is necessary to analyze these open source software to determine whether it is subject to the EAR. To this end, a scientific and feasible method for identification is summarized, which we call the four-element method for identifying open source software under the jurisdiction of the EAR, as shown in the following figure:
Simply put, if an open source software meets the above four conditions at the same time, we consider the open source software to be open source software governed by the EAR.
2. Open source software filing under the jurisdiction of EAR
This practice requires that open source software identified as subject to the EAR must complete the filing with the BIS before the software version is released to the public, and through the filing, the open source software under the jurisdiction of the EAR will be turned into non-jurisdictional open source software, thereby reducing the risk of export control compliance. The specific method is to notify the BIS and ENC Encryption Request Coordinator by email, and inform the URL or network address where the encrypted source code is located. Every time the URL changes, the BIS and ENC Encryption Request Coordinator need to be notified again, but the source code update or modification does not require Notice again.
Enterprises centrally manage the filing of open source software from the perspective of the company. On the one hand, it can ensure the reliability and credibility of the source; on the other hand, it realizes resource sharing and avoids different R&D units. Repeated filing reduces resource consumption and improves efficiency.
(2) Open source external contribution control
As open source software users, but also open source software contributors. There are two common ways to make external contributions to open source. One is to directly contribute self-developed code to the open source community, and the other is to lead construction projects in the open source community.
1. Self-developed code contribution
In order to realize the co-construction of the open source community and realize the sharing of technology and code, in some cases, the R&D project needs to share the source code with the open source community while obtaining the open source project from the open source community. To comply with export control policies, software involving EAR-controlled technology or software cannot be disclosed to the open source community as open source software. In this practice, the control requirements for external contribution of open source code are: before submitting source code to the open source community, the project team needs to identify whether it contains controlled software, and the controlled software cannot be released as open source software; the software of controlled projects involving controlled technologies Source code cannot be contributed to the outside world.
2. Open source project construction
At present, many enterprises in my country have their own open source software construction projects, the code is hosted by the Linux Foundation, and at the same time, mirrors are built on the open source Chinese community. Open Source China is currently the largest open source technology community. Although open source projects have autonomy in the choice of hosting platforms, most Chinese project teams choose to build mirror images in China when hosting code on large international platforms. Not only Chinese projects, but also open source China is similar to many large international platforms. Signing relevant agreements, on the one hand, can continuously develop the open source community, and at the same time, it is also a long-term guarantee for the security of the use of domestic open source code.
Five: open source software control improvement measures and risk analysis
(1) Open source software management and control gaps and improvements
In the above open source software control practice, enterprises have formulated relatively comprehensive control measures for open source software, and the risk of export control compliance has been completely controlled. However, there is still a certain difference between the implementation and the existing policy requirements, which is reflected in the current EAR regulations that only control open source software involving non-standard encryption algorithms. That is to say, only open source software involving non-standard encryption algorithms is the concern of US export control. The object of the company, others are not within its jurisdiction, and there is no need to file with it. This policy will be changed in March 2021. However, at present, if the filing is still carried out in accordance with the original requirements, all encrypted open source software will be filed, and the standard of control will be higher. While this gap does not pose a compliance risk, it does increase the filing workload.
To close this gap, corporate compliance and business units are constantly discussing improvement measures and proposals, with the goal of fully complying with the EAR requirements and filing with BIS only for open source software involving non-standard encryption algorithms. In this scheme, the most critical point is how to determine whether the encryption algorithm is a standard algorithm. The recommendations for implementing the implementation plan are as follows:
-
First, according to the description of standard encryption algorithms in the law, determine the list of standard encryption algorithms that have been used at present, but this list does not cover all standard encryption algorithms and is only for the reference of users;
-
The user is responsible for judging the encryption algorithm standard and non-standard of the encryption open source software. The judgment method is to refer to the list of standard encryption algorithms. If the encryption algorithm used by the encryption software is in this list, it is considered to be a standard encryption algorithm;
-
If the algorithm used by the encryption software is not in this list, it needs to be judged according to the definition of the non-standard encryption algorithm, and the judgment of whether it is a non-standard encryption algorithm is given, and the judgment basis: in which international standard the algorithm is publicly released;
-
Judgment basis for managers to review standard encryption algorithms that are not in the list of standard encryption algorithms. If the judgment basis is reliable, the modified algorithm will be added to the list of standard encryption algorithms; otherwise, open source software involving non-standard encryption algorithms will be filed with BIS.
(2) Potential risk analysis of open source software
In this practice, although the use of open source software has fully complied with US export controls, it does not mean that there is no risk. As can be seen from the cases outlined above, there may be an extreme situation. Once the EAR is modified in the United States, some core basic software such as high-performance software and EDA software will be added to the control (this is not impossible, in November 2018, The US BIS has solicited public opinions on whether emerging technologies such as AI and machine learning should be added to the control list), and changed the current "filing is not regulated" (which includes almost all ASF open source projects) to "filing and needs to be regulated" ”, which means that a large number of core open source projects will be subject to export controls.
In other words, if most of the open source software we use comes from these influential external communities, and these communities are subject to national export control policies, then these open source software will always be affected by changes in export control policies . We have clearly recognized that the essence of export control is that countries do not want the things (items) they care about to be transferred to countries/people (embargoed countries/restricted subjects) that they do not like. The current international situation is unpredictable. , if once the form mutates, open source software, as a double-edged sword that seriously affects all walks of life, is very likely to be used as a weapon against a country or enterprise.
So in the long run, China must establish its own influential open source project hosting platform, develop its own open source power, and attract open source enthusiasts around the world in a more open manner. China began to build an open source Chinese community in 2008, and it has now become the largest open source technology community in China. In the country's fourteenth five-year plan, "open source" has been included in the plan. Looking at Chinese enterprises, Huawei, as a representative of outstanding risk management companies, has also realized its risks in open source software early. Huawei has built a complete open source ecosystem in China for basic software such as operating systems, databases, and AI deep learning frameworks. Become an important force in China's open source.
For companies that are far-reachingly affected by open source software and export controls, it is also necessary to be prepared for danger and make more contributions.
Six: References
[1] China: "Export Control Law of the People's Republic of China"
[2] China: "Dual-use item catalog"
[3] Japan: << Security Trade Management >>;
[4] Japan: "Japan Export Trade Control Order";
[5] United States: "Part 734 - Scope of the Export Administration Regulations";
[6] United States: "Part 742 - Control Policy - CCL Based Controls";
[七]《Official Journal of the European Union》（欧盟公报）：《eu-council-regulation-ec-no-428-2009-of-5-may-2009-setting-up-a-community-regime-for-the-control-of-exports-transfer-brokering-and-transit-of-dual-use-items》
[8] The Linux Foundation released a white paper: "Understanding Open Source Technology and U.S. Export Control";
[9] The Linux Foundation: "The Linux Foundation Releases a White Paper Explaining How to Respond to U.S. Export Controls on Open Source Projects" 2020.7
[10] China Open Command Ecology (RISC-V) Alliance: "Risk Analysis and Countermeasure Suggestions for Open Source Projects".
Authors of this article: Z.YQ, F.YP, Zh.X, X.ShM
Disclaimer
The information required for the writing of this article is collected from legal and public channels, and we cannot provide any form of guarantee for the authenticity, completeness and accuracy of the information;
This article is only for the purpose of sharing, communication and learning, and no one should take all or part of the contents of this article as the basis for decision-making, and the consequences will be the responsibility of the actor.
Source: Compliance Xiaoke
