Understanding US export controls with open source projects

Chinese Language Version Available

Introduction

One of the greatest strengths of open source development is how it enables collaboration across the entire world. However, because open source development is a global activity, it necessarily involves making available software across national boundaries. Some countries’ export control regulations, such as the United States, may require taking additional steps to ensure that an open source project is satisfying obligations under local regulations.

The Linux Foundation has recently published a whitepaper on considerations for open source communities in detail, which can be downloaded here. This blog post is a summary of the general principles open source communities should be aware of and follow as it relates to both US export control requirements and open source encryption.

Export controls in the United States and other countries

The primary source of United States federal government restrictions on exports are the Export Administration Regulations or EAR. The EAR is published and updated regularly by the Bureau of Industry and Security (BIS) within the US Department of Commerce. The EAR applies to all items “subject to the EAR,” and may control the export, re-export, or transfer (in-country) of such items.

Under the EAR, the term “export” has a broad meaning. Exports can include not only the transfer of a physical product from inside the US to an external location but also other actions. The simple act of releasing technology to someone other than a US citizen or lawful permanent resident within the United States is deemed to be an export, as is making available software for electronic transmission that can be received by individuals outside the US. 

This may seem alarming for open source communities, but the good news is open source technologies that are published and made publicly available to the world are not subject to the EAR. Therefore, open source remains one of the most accessible models for global collaboration.

For the purposes of compliance with the EAR, if the open source technology is publicly available without restrictions upon its further dissemination, then it is “published” and therefore “not subject to” the EAR. 

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

What kind of open source projects are not subject to the EAR and export restrictions?

All of them. Open source software from the Linux Foundation and project communities we work with is published and made available to the public without restrictions on further dissemination or distribution of the software. 

The following typical scenarios (but not an exhaustive list) are not subject to the EAR because “open source” is “published”:

• Open source software that is published publicly is not subject to the EAR
• Open source specifications that are published publicly are not subject to the EAR
• Open source files that describe the designs for hardware that are published publicly are not subject to the EAR
• Open source software binaries that are published publicly are not subject to the EAR

To meet the requirement of “published” under the EAR, however, open source communities may need to take an additional step if the project includes encryption technology.

Projects that use encryption

The EAR regulates exports of certain encryption software and technology. The definition of “encryption software” is very broad and can include software that merely activates or enables encryption features in another software or hardware product.

However, as with the EAR exemption for software that is published, there is also an exemption for software that uses encryption that is (1) it is “publicly available,” and (2) an email notification has been sent for it to the addresses listed in that section.

To meet the first of the exemption requirements, the meaning of “publicly available” refers to the EAR’s definition of “published,” which includes public dissemination by posting on the Internet on sites available to the public. Given this, the first part of the test should be met for all fully-public open source software projects: if the project’s source code is openly available on the Internet, then it should be considered “publicly available.”

To meet the second of the exemption requirements, it is additionally necessary to send an email to two specified addresses, one at BIS at crypt@bis.doc.gov and the other at the US National Security Agency (NSA) at enc@nsa.gov. The email should include the URL of the publicly-available code (or a copy of the code itself). An updated notification should be sent later if the previously-provided URL or copy has changed.

After these two requirements are satisfied, then its corresponding object code counterpart for the project is also not subject to the EAR.

At The Linux Foundation, the source code for all of our projects, including encryption software, is publicly available, and we have provided email notices as described above. We also make copies of these email notices publicly available for viewing on the LF’s website. As a result, the Linux Foundation’s project source code and corresponding object code are not subject to EAR encryption restrictions.

Please keep in mind that this applies only to the open source project itself. Downstream redistributors of modified project code or products derived from it, where the source code is not publicly available, would still need to evaluate their own compliance with the EAR (just as with any other software that they export).

In addition to projects that use encryption, the EAR added a new regulation in January 2020 for systems that employ a certain use of neural network-driven geospatial analysis training. As with other open source technologies that are publicly available, open source software that is published and publicly available, even in this category of neural network-driven geospatial analysis training, would also not be subject to the EAR. Please refer to our full whitepaper for more explanation.

Best practices for open source software communities

While open source projects are exempt from EAR restrictions, there are a few practices we have learned or developed that may be helpful for all open source communities as it relates to export regulations. 

We often use the word “open” to mean many things: an open source license, open and transparent discussions, open community, openly available source code on a public repository. “Open” may seem an obvious practice for open source communities, but the following are some specific recommendations for communities to consider. 

Be open and be public

First, communities should strive to keep their technical conversations open and public. If private technical conversations happen within communities, that’s normal, but it is recommended to make the community decisions and outcomes publicly available. It is important for our projects to make information available transparently and publicly as the private exchange of technology or technical information may not meet the “publicly available” standard according to the EAR.

One question that has come up has to do with exchanges of information related to security issues under a security disclosure process. As a best practice, projects may want to consider making exchanges like this public upon the availability of fixes, and not limit this information to only a confidential disclosure list.

Send notifications of encryption to BIS and the NSA

If your open source software project implements or uses encryption functionality classified under ECCN 5D002, you will likely want to deliver a notification of encryption to the BIS and the NSA according to the EAR requirements. The EAR describes these requirements:

• • Send an email to crypt@bis.doc.gov and enc@nsa.gov. If your project is an LF project and your notice is not listed on our export website, please notify legal@linuxfoundation.org.
  • The email should contain either the URL of the publicly available encryption source code or a copy of the source code itself. 
  • If you provided a URL to a site where you posted the source code on the Internet, you must notify by email again each time the Internet location is changed, but you are not required to notify them of updates or modifications made to the encryption source code at the previously notified location.
  • If you provided a copy of the source code, and you update or modify the source code, you must also provide additional copies to each of them each time the cryptographic functionality of the source code is updated or modified. 

The Linux Foundation suggests a few additional details as best practices:

• Make publicly available copies of the notices that were delivered to BIS and NSA, in order to increase transparency and visibility of compliance. This also helps with your community of downstream users who may wonder “do they send notices?” You can prevent concerns by making the notices themselves public.
• Include contact information and, where applicable, the name of the particular legal entity that is responsible for the project.
• Establish a system to ensure that you maintain evidence, for a medium- to long-term period of time, that the notification emails to BIS and NSA were in fact delivered. Relying solely on an individual’s “Sent” mailbox records may not be preferable if a question arises in the future, or if that individual loses access to that Sent mailbox (e.g. if they change employers).

Additionally, If you are distributing publicly available encryption software in object code form, then you will also want to ensure that it is publicly available in source code form as well.

If it is necessary to distribute encryption software in binary or object code form, then ensure that the corresponding source code is publicly available. The easiest way to do this is to make available the source code for that version of the encryption software yourself, as part of the project’s own code. (In fact, depending on the applicable open source license, this may be necessary or at least useful in complying with that open source license as well!)

In addition to manual review, there are some scanning tools (such as Fossology and exportctl) with varying degrees of ability to scan source code and detect usage of encryption functionality. No automated scanning tool is likely to be a perfect detector of all applicable uses, but these may be helpful in identifying copies of encryption software in a large codebase.

To download the “Understanding Open Source Technology and US Export Controls” whitepaper, click on the button below.