Navigating Global Regulations and Open Source: US OFAC Sanctions

Chinese language version is also available.  在这里阅读中文版本
Japanese language version is also available. 日本語版もございます

Open source is a fundamental part of software supply chains and production systems. As such, it has reached a stage of maturity that requires new ways to deal with a complex world. The Linux Foundation has always pushed to promote and protect open collaboration in open source software and open standards-related activities. The model of allowing the brightest technical minds from around the world to contribute to an open commons has repeatedly proven its value over the past few decades. Protecting this commons is essential and something the Linux Foundation will continue to defend.

However, increased cybersecurity risk and regulatory compliance are creating burdens on open source communities that must be met. There are newer regulations such as the EU’s Cyber Resilience Act, where we and others in the open source ecosystem invested great energy to educate regulators on the issues and concerns and carve out explicit exemptions for open source. Sanctions regulations are often very old regulations that never contemplated exemptions for the type of open collaboration that underpins modern daily life, societal systems, and business. The Linux Foundation is committed to open source and global collaboration and doing so responsibly while complying with laws and regulations where the foundation and our community members operate.  Understanding the legal frameworks within which we all collaborate is essential to maintaining global collaboration.

One of these areas is trade and sanctions regulations many countries have enacted. Many of these trade and sanctions regulations were enacted decades ago but have more recently been used to target technology providers. While there are sanctions programs in place around the globe, many developers will need to be mindful of laws and regulations like U.S. OFAC (Office of Foreign Assets Control) sanctions. Issues involving OFAC sanctions programs and open source are not very common, but are important to be aware of. These sanctions regulate interactions (or, in their word, “transactions”) with specific countries, entities, and individuals. 

OFAC sanctions issues are not commonly seen or understood in open source communities. They target a specific list of entities, individuals, countries, or regions. Historically those targets were not engaged in open source communities. With the U.S. and international sanctions targeting technology companies based in Russia, this issue has become a topic in certain open source communities that have participation from entities targeted by such sanctions.

The OFAC sanctions rules are “strict liability”, which means it does not matter whether you know about them or not. Violating these rules can lead to serious penalties, so it's important to understand how they might affect your open source work. Many OFAC sanctions restrictions generally do not care if software or technology is public or published (although US export controls generally do) and are usually completely separate and independent of any Export Administration Regulations (EARs), which the LF has published guidance about In the past. It is important to note that the OFAC SDN List for sanctions programs is very different from the BIS’s Entity List for Export Controls. Entities on the BIS’s Entity List are not affected by the OFAC sanctions unless they are also added by OFAC to the SDN List. When looking at export controls and trade sanctions, they are separate programs and each list needs to be evaluated as the implications of export and trade sanctions are very different.

The following information is shared to generate awareness of the issues that may arise and current compliance obligations. This guide is not intended to provide legal advice and we encourage you to seek advice from your legal counsel if you should run into any issues or have any questions. The points raised in this article are intended for developers who need to follow the U.S. sanctions laws or who want to collaborate with others who are required to follow U.S. sanctions laws. Developers and companies operating in open source outside the U.S. will need to determine which sanctions laws are applicable and relevant to themselves and their project communities. Such a determination likely requires consulting with a legal counsel or your employer's legal team.

What Are OFAC Sanctions?

OFAC sanctions are U.S. government regulations that restrict or prohibit transactions with certain countries, entities, and individuals (“sanctions targets”). These rules are normally put in place to achieve economic emergency, foreign policy and national security goals. They apply not just to financial transactions, but often to almost all interactions with a sanctions target, including those in the open source community spaces.

For developers, this means you need to be cautious about who you interact with and where your contributions come from. OFAC sanctions can target specific countries, regions, and individuals or organizations, with many of the individuals and organizations listed on the Specially Designated Nationals and Blocked Persons (“SDN”) List. OFAC updates this list regularly, adding or removing names as global situations change. OFAC sanctions also apply to all entities that are owned 50% or more directly or indirectly by one or more SDN individuals or entities, whether or not the owned entity shows up on the SDN List. Some entities, such as entities owned or controlled by OFAC-sanctioned governments, may also be sanctioned but not included on the SDN List. In addition, the few comprehensively sanctioned governments, regions, and countries also are not included on the SDN List.

Violating these sanctions can result in serious consequences, including large civil fines and criminal penalties. In general, if you’re a U.S. citizen or a U.S.-based organization, or if you deal with U.S.-origin goods, services, or U.S. Dollars for prohibited transactions, you’re likely required to follow these rules, no matter where in the world you are.

Other International Sanctions Programs

U.S. OFAC sanctions only reflect the U.S. sanctions programs. Many other countries also have similar sanctions programs in place, including the European Union, United Kingdom, Japan, Australia, Switzerland, China, and many more. This post specifically addresses U.S. sanctions, but keep in mind if you are located elsewhere in the world, your local country may have similar sanctions in place.

It is disappointing that the open source community cannot operate independently of international sanctions programs, but these sanctions are the law of each country and are not optional. Many developers work on open source projects in their spare time, or for fun. Dealing with U.S. and international sanctions was unlikely on the list of things that most (or very likely any) open source developers thought they were signing up for. We hope that in time relevant authorities will clarify that open source and standards activities may continue unabated. Until that time, however, with the direct and indirect sponsorship of developers by companies, the intersection of sanctions on corporate entities leaves us in a place where we cannot ignore the potential risks.

What Developers Should Know

In addition to strict liability, OFAC sanctions do not always have a blanket exemption for all transactions involving “publicly available” technology as the U.S export control regulations generally do for nearly all export-controlled transactions.  

It is important to understand the basics of these sanctions programs. OFAC’s prohibited transactions often include:

• Financial investments and transactions (e.g. payment for services)
• Trade (import or export) of goods, technology, or services
• Any other property transactions (including intellectual property and contracts)

The OFAC sanctions may impact common community behaviors, such as two-way collaboration on a proposed software change which could be interpreted as a prohibited provision of services. It would be an issue for developers to provide services to a developer who is employed (directly or indirectly) by an SDN or an entity directly or indirectly owned 50% or more by an SDN.

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, there’s the 50% percent rule 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.

Conclusion

The open source community is built on collaboration, but compliance with sanctions programs is not optional for developers who could unknowingly violate the law. If you encounter situations that seem unclear, seek legal advice early to avoid compliance issues. The Linux Foundation’s goal is to help developers navigate these complexities, so you can focus on building great software without legal headaches. The Linux Foundation has already built compliance or verification checks into many of its processes and tools. If you are a maintainer of an LF project, please reach out to your LF contact point (or legal@linuxfoundation.org) for any questions you may have on our approach or for any support we can provide for your project. By staying aware and proactive, you can contribute to open source confidently while respecting global regulations.

As stated at the beginning, the Linux Foundation’s position is that open source and open standards are the most inclusive collaborative innovation model in the world. We hope that developers will begin to understand sanctions programs and regulations on the one hand, and at the same time, understand when to reach out to experts for help. It’s important to not overreact and to ensure open source communities take informed action when presented with a possible issue. For the vast majority of developers around the world, regardless of their nationality, country of residence, political system, cultural beliefs, or ideology, the open source community is still the most open collaboration ecosystem, just as it has always been before. In open source, communities are not used to having to exclude or curtail anyone’s ability to participate. It is understandable that trade and sanctions regulations may cast a different light on many people’s interpretations of the neutrality and equality of open source. We also hope that enactors of sanctions programs in the US and around the world will provide clear exemptions for open source cooperation in the future.