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.
In July of 2020, The Linux Foundation published a whitepaper on how to address these issues in detail. In 2021, the primary update in the paper is to reflect a change in the US Export Administration Regulations.
- Previously, in order for publicly available encryption software under ECCN 5D002 to be not subject to the EAR, email notifications were required regardless of whether or not the cryptography it implemented was standardized.
- Following the change, email notifications are only required for software that implements “non-standard cryptography”.
Please see the updated paper and the EAR for more specific details about this change.
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
As of 2021, if an open source project uses standard cryptography, there are no additional requirements or analysis required. However, if a project is using non-standard cryptography, email notifications are still required. Uses of non-standard cryptography are fairly rare, so please read the full PDF for details on handling these situations.
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). Additionally downstream open source projects that implement non-standard cryptography would have to do a similar analysis.
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 non-standard encryption to BIS and the NSA
If your open source software project implements or uses non-standard 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 Linux Foundation suggests a few additional details as best practices for managing notifications:
- Make publicly available copies of any 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.
Authors
Steve Winslow, Director of Strategic Programs, Linux Foundation
Mike Dolan, SVP of Projects, Linux Foundation
Jason Perlow, Editorial Director, Linux Foundation
