The EAR and “Standards-Related Activities”¶
Open collaboration across boundaries involves more than just open source software. In particular, the production of mutually-agreed upon technical standards is critical to interoperability among individuals, organizations, and nations. Trust and confidence in the effectiveness, reliability and security of standards comes only through transparent, collaborative development practices.
Participation in standards development inherently involves the release and exchange of technology and technical practices. Over the past few years, the EAR has evolved to recognize more explicitly the importance of enabling the release of technology in a standards-related context.
As discussed earlier, “software” and “technology” are not subject to the EAR when they are “published,” by being made available to the public without restrictions on further dissemination. However, unlike open source software patches that are immediately posted on websites or mailing lists, standards development—even for open standards—may involve releases of technology that are not immediately “published” in the same way. Individuals, companies and other organizations with technical expertise will meet to discuss varying approaches to solving a technical problem, sometimes initially in settings that are not fully public. The outcomes of those discussions may not be immediately “published” in the same way as an open source patch or pull request; instead, they are later “published” when the coalesced specification is finally agreed upon and issued.
Because some information relating to software and technology can be exchanged in a standards-development context prior to being “published,” and because some shared technology will often not be included in a final standard, contributors to open standards expressed their concerns to BIS about a lack of clarity in the EAR. [1] In particular, their comments reflected uncertainty about whether engaging in technical conversations with non-“published” information as part of open standards development could violate the EAR due to the involvement or presence of certain other third-party participants who were identified on the EAR’s “Entity List”. [2]
To address these concerns, BIS issued a series of guidance documents and revisions to the applicable portions of the EAR, the most recent being an “interim final rule” published in July 2024. [3] This latest rule clarified several aspects of the EAR’s applicability to standards development, by revising prior language into a new provision in the EAR § 734.10(b). [4]
Specifically, the updated rule states that releases of software or technology are not subject to the EAR when all of the following apply:
it is released for a “standards-related activity”; AND
the technology or software is either not on the Commerce Control List (i.e. EAR99), or within one of the permitted ECCNs on the Commerce Control List; AND
the standards-related activity is for a “published” standard, or occurs with the intent that the resulting standard will be published.
Let’s look at each of these requirements in more detail.
Standards-Related Activity¶
The first prong of the new standards exclusion requires that the release be for a “standards-related activity.” § 734.10(b) indicates that a “standard” is:
… any document or other writing that provides, for common and repeated use, rules, guidelines, technical or other characteristics for products or related processes and production methods… [5]
Although § 734.10(b) does not explicitly define the outer bounds of what counts as a “standards-related activity,” it gives several examples of activities that are included, such as:
development of a standard;
adoption or application of a standard;
conformity assessment procedures; or
actions taken for the purpose of developing, promulgating, revising, amending, issuing or reissuing, interpreting, implementing or otherwise maintaining or applying such a standard.
The examples from this rule, together with BIS’s responses to comments discussed in the interim final rule, [6] suggest a broad scope for what counts as a “standards-related activity.” Eligible activities are not limited to the initial drafting and publication of the standard, or solely the parties involved in the initial drafting of the standard. Standards-related activities can also include ongoing revision and maintenance of a standard, as well as exchanges of information involved in working out interoperabilities and incompatibilities when in furtherance of compliance with the standard, including disclosures of security vulnerability-related information. [7]
Note also that the rule’s focus on a “standards-related activity” indicates that it is about the nature of the activity, rather than the nature of the standards body. BIS declined to adopt a rule that would, for example, define “standards-related activity” to automatically include all activities occurring within a “voluntary consensus standards body” (VCSB); [8] or, alternatively, to retain requirements that exempt standards must be developed under traditional standards development processes in a VCSB. By defining “standards-related activities” to cover a broad swath of actions relating to development, maintenance, and implementation of standards, for purposes of this rule BIS appears to be less concerned with formalities regarding the nature of the standards body entity itself.
Uncontrolled and Permitted Categories¶
Second, the EAR exclusion for standards-related activities requires that the applicable software or technology fall into one of the permitted categories on the Commerce Control List (CCL). [9] The CCL [10] is the Department of Commerce’s formal categorization of controlled items into ECCNs, as described earlier in this paper.
This second prong of the standards-related activity exclusion requires that the applicable released software or technology be either (A) controlled only for anti-terrorism reasons (“AT” controls); (B) included in particular subsets of the ECCNs for encryption-related software or technology; (C) included in certain software and technology related to commercial satellites/spacecraft; or else (D) not listed in the CCL at all and therefore designated as “EAR99”.
A full summary of the CCL and ECCNs is beyond the scope of this paper. Participants in standards-related activities which may involve software or technology specified on the CCL—including those relating to encryption—will likely want to consult their own legal counsel to understand whether this requirement is satisfied for their use case. However, for participants in standards-related activities involving software or technology that are not specified in any CCL category, the EAR99 designation should typically apply.
Published or Intent to Publish¶
Finally, the last part of the exclusion requires that the standards-related activity either:
(i) Is for a “published” standard; or
(ii) Occurs with the intent that the resulting standard will be “published.” [11]
If the applicable standard has been “published” by being made generally available to the public without restrictions upon its further dissemination, such as through posting on the Internet on sites available to the public, then option (i) would be satisfied.
However, it may be that the standard is still in a development stage and has not yet been published. Or, it may be that the release of technology relates to activities such as evaluating options for revisions and improvements to a standard. Option (ii) would instead be satisfied by demonstrating—presumably with clear documentation, such as meeting minutes—that the parties involved in the release of technology intended that the standard would subsequently be published.
Footnotes
