The Linux Foundation publishes a white paper explaining how to deal with U.S. export controls on open source projects

Original title: "Linux Foundation releases White Paper explaining how to Deal with U.S. Export Controls on Open source Projects"

Source: Unitimes

The Linux Foundation recently released a white paper describing how the open source community can understand and follow general principles related to U.S. export control requirements and open source encryption. The news was released in both Chinese and English, and the white paper presented the content in parallel.

The following is the full Linux Foundation release.

Introduction to the

One of the greatest advantages of open source development is that it enables the whole world to collaborate. However, because open source development is a global activity, it inevitably involves making available software across borders. Export control regulations in some countries, such as the United States, may require additional steps to ensure that an open source project meets its obligations under local regulations.

This article Outlines general principles related to U.S. export control requirements and open source encryption that the open source community should understand and follow.

Export controls in the United States and other countries

Export Administration Regulations (hereinafter referred to as "EAR") are the main Regulations of the US federal government restricting exports. They are issued and amended regularly by the Bureau of Industry and Security (BIS) under the US Department of Commerce. The Export Control Ordinance applies to all "articles controlled under the Export Control Ordinance and may control their export, re-export or transfer (domestically)".

The definition of "export" under EAR is broader. Exports include not only the movement of physical products from within the United States to abroad, but also other activities, such as the transfer of technology to non-U.s. citizens living in the United States or non-U.S. legal permanent residents, and the provision of software for electronic transmission to persons outside the United States.

This EAR may seem like a wake-up call to the open source community, but the good news is that open source technologies that are publicly available to the world are not subject to EAR. As a result, open source remains by far the most convenient model for global collaboration.

To comply with the EAR, if the open source technology is open and not subject to further dissemination, it is "published" and therefore "not subject" to the EAR.

In addition to the United States, the European Union has similar provisions in its export control regulations.

What open source projects are not subject to EAR and EU export restrictions?

All. The Open source software produced by the Linux Foundation and the project community we work with has been released and made publicly available without any restrictions on distribution.

The following (but not limited to) are not subject to EAR because they are "open source" and "released" :

◈ has publicly released by the open source software is not subject to the EAR
◈ has publicly released open source specification are not subject to the EAR
◈ has publicly released, the hardware design of the open source document is not subject to the EAR
◈ has publicly released by the open source software binary is not subject to the EAR

However, if the project involves encryption, the open source community may need to take additional steps to meet the EAR's "published" requirements.

Projects that use encryption technology

The EAR regulates the export of specific encryption software and technologies. The definition of "encryption software" is very broad and may include software that only activates or enables encryption functionality for other hardware and software products.

However, just as published software is not subject to AN EAR, software using encryption is not subject to an EAR if (1) the source code is "publicly available" and (2) an E-mail notification has been sent to the E-mail address provided in Section 742.15 (b).

To comply with the first exemption, "publicly available" means the definition of "published" under the EAR act, which includes publishing through a public site (that is, public dissemination). As long as a fully open source software project meets this standard, it should be deemed to have passed the first part of the measure: if the project's source code is publicly available on the Internet, it should be considered "publicly available."

To meet the second part of the measure, e-mails are sent to two designated E-mail addresses (the BIS's crypt@bis.doc.gov and the National Security Agency's enc@nsa.gov). The message content needs to include the URL address of the publicly available source code (or the source code itself). If there are any changes to the URL or source code, you need to notify the above email address again by email.

When the publicly available encrypted source code passes the above two measures, the corresponding object code is also not governed by the EAR.

All Linux Foundation project source code, including encryption software, is publicly available, and we have provided email notifications as described above. We also publish a copy of the email notice on the LF website. Therefore, the Linux Foundation project source code and its corresponding object code are not subject to EAR restrictions on encryption.

Note that this applies only to open source projects themselves. If the source code is not made public, the downstream distributor that has modified the project code or the downstream distributor that derived it will still have to evaluate for compliance with the EAR (just like any other software it exports).

In addition to the project using encryption, EAR added a new regulation in January 2020 for training systems using neural network-driven geospatial analysis. As with other publicly available open source technologies, publicly released open source software is not subject to EAR, even in the category of neural networking-driven geospatial analysis training.

Best practices for the open source software community

While open source projects are not subject to EAR, we have learned or mastered a number of practices that may benefit all open source communities, related to export regulations.

We often use the word "open" to describe many things: open source licenses, open and transparent discussions, open communities, publicly available source code stored in public think-tanks. "Open" may seem obvious to the open source community, but here are some specific Suggestions to consider.

Open, open

First, the community should try to keep the technology dialogue open and open. This is normal if private technical conversations take place within the community, but it is recommended that community decisions and results be made public. It was important for our project to make the information public and transparent because the technology or private exchange of technical information might not meet the EAR's "publicly available" criteria.

One issue that arises relates to the exchange of security-related information during the security disclosure process. As a best practice, projects might consider exposing such exchanges when fixes are available, rather than limiting this information to a confidential public list.

Send encrypted notifications to BIS and NSA

If your open source software project implements or USES encryption features specified in ECCN 5D002, you will need to send encryption notifications to BIS and NSA as required by the EAR. The specific requirements of EAR are as follows:

◈ send email to crypt@bis.doc.gov and enc@nsa.gov. If your project is LF's project and your notice does not appear on our export management page, please send a notice to legal@linuxfoundation.org.

◈ email should include to contain public access encrypted source web address, or the source code itself.

◈ if you provide the website address, so every time change web address, you must send a notification by email, but you do not need to notify the relevant update or change the source code itself.

◈ if you provide the source code itself, so whenever encryption after update or change, you must provide the latest source code.

The Linux Foundation recommends other details as best practices:

◈ to enhance transparency and show compliance, will be submitted to the bank and inform the public the NSA. This also helps to resolve downstream users' doubts about whether the community has sent notifications. You can avoid these hassles by making public notifications.

◈ additional contact information and is responsible for the name of the legal entity of project.

◈ design a medium to long-term proof system (prove notification email that was sent to the BIS and NSA has actually been delivered). Because if there is a problem in the future, or if the individual does not have access to the "sent" mailbox, it is not a good idea to rely on the "sent" mailbox record (e.g. the sender changes jobs).

In addition, if you are distributing publicly available encryption software in object code, you also need to ensure that it is also publicly available in source code.

If encryption software must be distributed in binary or object code, then you must make sure that the corresponding source code is publicly available. The easiest way is to expose the source code of the encryption software version as the source code of the project itself. (In fact, depending on the applicable open source license, this may also be necessary, or at least useful, to comply with open source licenses.)

In addition to manual auditing, there are a variety of scanning tools (such as Fossology and ExportCTL) that can scan source code and detect applications of encryption capabilities. No automated scanning tool can perfectly detect all applications, but these tools may help identify encryption software in a large code base.

Text link:https://mp.weixin.qq.com

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia