US Export Administration Regulations (EAR)

The primary source of United States federal government restrictions on exports is 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. [1] The EAR applies to all items that are “subject to the EAR,” and may control the export, re-export or transfer (in-country) of such items.

Under the EAR, “item” [2] and “export” [3] are terms with broad meanings. An “item” may be a physical product, software, or other technology, such as specifications, protocols, or other information. And exports can include not only the transfer of an item from inside the US to an external location, but also other actions. For example, releasing technology to someone other than a US citizen or lawful permanent resident physically within the United States is deemed to be an export, [4] as is making available software for electronic transmission that can be received by individuals outside the US, providing “access information” [5] or “software license keys” [6] if done with “knowledge” [7] that such transfer would result in the release of such “technology” [8] or “software” [9] without a required authorization. [10]

At first this may seem alarming for open source communities, but the good news is that standards and open source software that are published or are intended to be published, as well as other open source technologies that are developed transparently and made publicly available to the world are not ordinarily subject to the EAR. Therefore, open source remains one of the most accessible models for global collaboration.

In the following sections, we will explain why concerns over the United States export control regulations are generally not a problem for the open source model and discuss how the EAR generally does not apply to the export of open source software with a few example situations. We will then address two subject matter areas in certain circumstances: first, open source software that includes non-standard cryptography functionality; and second, sharing information in the context of open standards-related activities. Finally, we will suggest some best practices for open source communities to consider in their projects.

Please note that the suggestions provided in this paper do not constitute and should not be construed as legal advice. When considering export control compliance and prior to making associated decisions, readers are strongly encouraged to consult their own legal counsel to understand their obligations in their specific contexts.

Footnotes