Key Points for Developers

The application of U.S. sanctions, including both their prohibitions and exemptions, to open source software or standards-related activities is not 100% well defined, as OFAC has yet to issue clear guidance on whether and how U.S. sanctions apply to open source or standards-related activities. Therefore, application of these sanctions programs to open source often relies on interpretation and looking at how the sanctions have previously been applied in similar contexts. If you run into any issues or if you have any questions, you should consult your legal counsel immediately. The information provided below is meant to help others understand general issues to watch out for and be aware of, including exemptions that can be helpful for open source project communities.

1. OFAC’s SDN “List” Is Not Enough

OFAC does publish an SDN List, and also offers an OFAC SDN list search tool. Using the search tool, a user can check if an organization is on the OFAC SDN List. OFAC SDN entities show up with “SDN” under the column “List”.

Please note this tool also searches other “Non-SDN Lists” that is not affected by the prohibited “transaction” outlined in this blog and all search hits are not necessarily for the OFAC SDN List.

The OFAC SDN list and search tool are also not exhaustive and any analysis cannot solely rely on this list:

  • First, the 50% percent rule applies if an entity is 50% or more owned directly or indirectly by one or more SDNs. That requires identifying who owns an entity, and (in many cases) who also owns that entity, up until all owners are identified.

  • Second, some sanctions apply to entire countries (e.g., Iran), regions (e.g., the Crimea region of Ukraine), or governments (e.g., the Government of Venezuela), and those countries, regions, and governments are not listed on the SDN List.

  • Additionally, the SDN List is constantly changing. Just because an individual or entity is not on the SDN List today does not mean they, or their owner, will not be added tomorrow. In some weeks, OFAC may add hundreds of individuals or entities to the list.

  • Finally, just because an individual or entity is not subject to U.S. OFAC sanctions does not mean that another country has not sanctioned the individual or entity. Remember that open source is global, and depending on where your project’s developers are located, other sanctions programs may apply.

2. Information Exemption

Most OFAC sanctions contain an exemption for the importation and exportations of “informational materials.” Open source code appears to generally be considered “informational material” by OFAC, and a one-way receipt of source code via an SDN therefore should be exempt from OFAC sanctions.

However, this would only apply to existing code sent by an SDN, and it would not apply if you requested a developer working for an SDN to create new code or to modify code.

In a simple example, if an SDN identified a memory bug and submitted an unsolicited patch to fix the issue, developers receiving this patch should be able to evaluate the patch on its technical merit, modify it if they see fit, and apply the patch to their repository. The SDN’s developer submitting the patch would see the patch being applied but should not be engaged in a two-way communication discussing the patch, the technical merits, or ways to improve the patch. The source code itself is informational material, but the concern is a developer crossing a line into providing a service to the SDN.

3. Avoid Two-Way Engagement

Reviewing an unsolicited patch from a contributor in a sanctioned region should generally be fine, but actively engaging them to better understand their issue, diagnose the problem, or help improve a patch or modify code would likely cross the line.

If the contributor is linked to a sanctioned entity or region, in general, it is best to keep communications strictly one-way. If a patch is received and you improve it and submit it upstream, that should be fine, but going back and forth in communications with the SDN developer likely would not.

4. Avoid Contributions Enabling SDNs

Accepting unsolicited patches that fix general issues in your open source project should be okay. However, if the changes directly benefit a restricted party’s products or services, it could be a problem.

For example, if a developer from AcmeSDN (and AcmeSDN is an SDN subject to OFAC sanctions) contributes a driver that enables the AcmeSDN processor to work in your software, that contribution would likely be an issue. Think carefully not just about the source code, but the impact of these unsolicited patches.

5. Avoid Indirect Contributions

Sanctioned entities might try to contribute indirectly through third parties or developers acting “individually.” Developers should understand other contributors’ affiliations and raise any concerns with their community and legal counsel.

For example, if in the prior example, AcmeSDN paid a developer in a country not subject to sanctions to make the driver contribution enabling AcmeSDN’s processor, that would still likely be an issue.

A common pattern is that an SDN’s developer is blocked from making a contribution, but then a very similar (or the same) patch is submitted to the project from another account or email address. It could be an anonymous email account. Just because the contributor has been obfuscated does not change an assessment of the situation.

6. Avoid Contributor License Agreements (CLAs) with SDNs

Many open source projects require a CLA, which would bar contributors from OFAC sanctioned entities. OFAC sanctions bar transacting in intellectual property, and specifically, any agreement in intellectual property or any other contract with an SDN. If your open source project requires a CLA, make sure your CLA validation process includes compliance checks against the SDN List.