28.4: Export Controls and Sanctions¶

Disclaimer: This section provides general educational information about export control and sanctions considerations. It does not constitute legal advice. Organizations and individuals should consult qualified legal counsel and relevant government agencies for guidance on specific export control and sanctions compliance matters.

This borderless nature of open source development collides uncomfortably with export control and sanctions regimes designed for a world of physical goods and identifiable transactions. When a cryptographic library is "exported" to a sanctioned country simply by being publicly available on GitHub, traditional export control concepts strain to apply.

For organizations participating in open source supply chains, export control and sanctions compliance creates legal obligations that can conflict with open source principles of universal access. Understanding these regimes—including the exceptions that protect most open source activity—enables organizations to participate in global open source development while maintaining compliance.

Encryption Export Controls¶

The United States regulates export of encryption technology through the Export Administration Regulations (EAR), administered by the Bureau of Industry and Security (BIS)¹ within the Department of Commerce. These regulations implement the Wassenaar Arrangement², a multilateral export control regime with 42 participating countries coordinating controls on conventional arms and dual-use technologies.

EAR encryption classification:

Encryption items are classified under Export Control Classification Number (ECCN) 5D002, which covers software implementing cryptographic functionality. Without exceptions, exporting such software requires a license from BIS—a process that would make global open source cryptographic development impossible.

Key classification factors include:

• Encryption algorithm strength and key length
• Whether encryption is the primary function
• Mass market availability
• Publicly available status

Publicly available source code treatment:

Section 742.15(b) of the EAR³ provides critical treatment for publicly available encryption source code. After the required notification, qualifying source code is not subject to the EAR, enabling public release of encryption source code that is:

• Published and available to the public
• Not subject to access restrictions that would prevent public dissemination
• Freely available without payment of license fees

This treatment enables open source cryptographic libraries, secure communication tools, and security software to be developed and distributed globally without individual export licenses.

Notification requirement:

For publicly available encryption source code, the EAR requires notification to BIS and NSA before or contemporaneously with public release. Developers must send an email to crypt@bis.doc.gov and enc@nsa.gov with:

• The public URL where the source code is available
• A brief description of the encryption functionality

This notification is informational—no response or approval is required. However, failure to notify can jeopardize the treatment that removes qualifying encryption source code from EAR controls.

Object code considerations:

The publicly available treatment applies explicitly to source code. Compiled object code (binaries) has historically received different treatment, though enforcement against publicly available compiled open source software has been minimal. Organizations distributing compiled cryptographic software should evaluate whether separate exceptions (such as mass market provisions) apply.

Wassenaar Arrangement and intrusion software:

The 2013 Wassenaar Arrangement added controls on "intrusion software"—software designed to defeat protective countermeasures or extract data from computer systems. The U.S. implementation of these controls generated significant controversy, with security researchers concerned that security tools and vulnerability research could require export licenses.

BIS ultimately adopted a narrower implementation, but the episode highlighted tension between export controls and security research. Organizations developing or distributing security testing tools should evaluate Wassenaar-related obligations.

Sanctioned Countries and Open Source Participation¶

Beyond encryption-specific controls, the United States maintains comprehensive sanctions programs restricting transactions with certain countries, entities, and individuals. The Office of Foreign Assets Control (OFAC) within the Treasury Department administers these programs.

Country-based sanctions:

OFAC maintains sanctions programs against several countries with varying scope:

Comprehensive sanctions generally prohibit providing services—including software—to persons in sanctioned countries. This creates tension with open source's universal availability principle.

The informational materials exception:

OFAC regulations⁴ include an exception for informational materials. However, it's important to note that 31 CFR 560.210(c)⁵ (for Iran) and similar provisions explicitly do not authorize "transactions incident to the exportation of software subject to the Export Administration Regulations." The informational materials exception covers certain publications and communications but does not extend to software that falls under EAR controls.

For open source software, public repository availability may be permissible under applicable exceptions, general licenses, or platform authorizations, but organizations should not assume that all sanctions restrictions disappear. They should understand the distinction:

• Making software publicly available (posting to GitHub, registries) may be permitted where applicable law or platform authorizations allow it
• Providing personalized services, customization, or tailored development is not covered
• Receiving payment from sanctioned persons is prohibited
• Technical support arrangements may create compliance issues

SDN list compliance:

The Specially Designated Nationals (SDN) List⁶ identifies individuals and entities subject to sanctions regardless of location. Providing services to SDN-listed persons is prohibited, even if they reside in non-sanctioned countries.

For open source projects:

• Public availability alone is less likely to create SDN issues than targeted engagement
• Accepting contributions from SDN-listed persons may create issues
• Providing personalized support or services to SDN-listed persons is prohibited
• Financial transactions with SDN-listed persons are blocked

Project maintainers generally cannot know whether anonymous contributors appear on the SDN list. However, if maintainers become aware that a contributor is SDN-listed, continued engagement with that specific individual could create compliance issues.

Sectoral sanctions:

Russian sanctions following the 2022 Ukraine invasion introduced sectoral restrictions affecting technology. Sanctions prohibit providing various categories of goods and services to Russian entities, with certain exceptions for personal communications and informational materials.

The interaction between these sanctions and open source participation remains complex. While making software publicly available generally falls within exceptions, providing tailored services, accepting certain contributions, or engaging in commercial transactions with sanctioned Russian entities may be prohibited.

Dual-Use Software Considerations¶

Dual-use items have both civilian and military applications, making them subject to export controls even when developed for peaceful purposes. Software categories potentially subject to dual-use controls include:

• Cryptographic software (discussed above)
• Intrusion and penetration testing tools
• Network analysis and monitoring software
• Certain artificial intelligence and machine learning capabilities
• High-performance computing software
• Specific industrial control system software

Identification challenges:

Determining whether software qualifies as dual-use requires technical analysis of capabilities against EAR classifications. Key considerations include:

• Specific technical parameters (algorithm strength, performance characteristics)
• Primary intended use
• Potential military or intelligence applications
• Whether functionality exceeds civilian requirements

Organizations developing potentially dual-use software should conduct classification analysis before public release. While publicly available treatment protects much open source source-code distribution, certain categories may face restrictions even when source code is public.

Entity list restrictions:

The BIS Entity List⁷ identifies organizations subject to specific export restrictions. Providing certain items to Entity List organizations requires a license, with presumption of denial for many entries.

For open source projects, Entity List restrictions create challenges:

• Contributions from Entity List organizations may be problematic
• Commercial relationships with Entity List organizations are restricted
• Even informational exchanges may require licenses depending on subject matter

Major technology platforms have implemented Entity List screening, sometimes resulting in account restrictions affecting legitimate contributors associated with listed organizations.

Platform Compliance¶

Major platforms hosting open source software—GitHub, GitLab, npm, PyPI—implement their own compliance programs that affect project accessibility.

GitHub's compliance approach:

GitHub⁸ implements trade-control compliance while trying to keep public repository services available where legally permitted. GitHub states that GitHub.com cloud services are available to developers in Iran and Cuba, while access may be restricted for Specially Designated Nationals, denied or blocked parties, certain government officials, and prohibited end uses. GitHub Enterprise Server and other commercial offerings remain subject to export restrictions for Country Group E:1 destinations and certain regions of Ukraine. Restrictions may include:

• Private repository limitations
• GitHub Actions and Pages restrictions
• Paid feature restrictions

Public repositories remain accessible for viewing and forking. GitHub has worked with OFAC to clarify permissible activities and obtained an OFAC license for Iran in January 2021, enabling broader access to GitHub services.

Platform account restrictions:

Platforms may restrict accounts based on:

• User location in sanctioned countries
• Association with sanctioned entities
• Entity List connections
• Payment from sanctioned sources

These restrictions sometimes affect contributors without direct sanctions exposure, creating challenges for international projects.

Hosting infrastructure considerations:

Organizations self-hosting open source infrastructure must implement their own compliance programs, including:

• Geo-blocking for sanctioned countries (if providing services)
• Screening for SDN-listed users
• Entity List verification for significant relationships
• Record-keeping for compliance demonstration

Cloud providers may restrict certain deployments based on sanctions compliance, affecting infrastructure choices for international projects.

Compliance Program Elements¶

Organizations participating in international open source supply chains should implement compliance programs proportionate to their risk exposure.

Risk assessment:

Evaluate your organization's specific exposure:

• Do you develop or distribute encryption software?
• Do you have contributors, customers, or partners in sanctioned countries?
• Does your software have potential dual-use applications?
• Do you accept payments or provide commercial services internationally?

Classification and screening:

For organizations with meaningful exposure:

• Conduct ECCN classification for products with encryption or dual-use potential
• Implement SDN and Entity List screening for significant relationships
• Document publicly available status for open source releases
• Maintain notification records for encryption software

Policies and procedures:

Establish documented procedures addressing:

• Classification determination process
• BIS notification requirements for encryption
• Screening procedures for high-risk relationships
• Escalation paths for sanctions questions
• Record-keeping requirements

Training:

Ensure relevant personnel understand:

• Basic export control and sanctions concepts
• Organization-specific compliance procedures
• Red flags requiring escalation
• Resources for compliance questions

Practical Challenges for Maintainers¶

Individual maintainers and small projects face particular challenges with export control and sanctions compliance.

Resource constraints:

Volunteer maintainers typically lack:

• Legal resources for classification analysis
• Infrastructure for sanctions screening
• Time for compliance program administration
• Budget for compliance tools or services

Practical approaches:

Maintainers can take reasonable steps within resource constraints:

1. BIS notification: Send notification emails for qualifying encryption source code—this takes minutes and creates a compliance record

2. Public availability: Ensure software is genuinely publicly available without access restrictions (beyond platform requirements)

3. Geographic restrictions: Consider whether geographic restrictions are appropriate if your project receives targeted contributions from sanctioned regions

4. Escalation awareness: Know when to seek help—if you receive contributions from entities you know are sanctioned or Entity-Listed, consult legal resources

5. Foundation support: Projects under foundation umbrellas may benefit from foundation compliance infrastructure

Open source principles tension:

Export controls and sanctions fundamentally conflict with open source principles of universal access. Most maintainers resolve this tension by:

• Relying on publicly available treatment for source code and applicable sanctions exceptions or licenses
• Treating public availability as the boundary of their obligations
• Not implementing proactive screening of anonymous contributors
• Seeking legal guidance if specific concerns arise

This approach may not satisfy all compliance obligations for all organizations, but represents a practical accommodation for volunteer-maintained projects.

Recommendations¶

We recommend organizations navigating export control and sanctions in open source contexts:

1. Conduct risk assessment to understand your organization's specific exposure based on technology type, geographic reach, and commercial activities

2. File BIS notifications for qualifying open source encryption source code—this simple step establishes compliance baseline

3. Ensure genuine public availability of open source releases, avoiding access restrictions that could undermine favorable export-control treatment

4. Implement proportionate screening for commercial relationships and significant partnerships, particularly with organizations in high-risk jurisdictions

5. Document compliance activities including classification determinations, notifications, and screening results

6. Monitor regulatory changes as sanctions programs evolve, particularly regarding Russia and China-related restrictions

7. Consult legal counsel for specific questions, particularly regarding novel situations or commercial activities in sanctioned regions

8. Engage with platforms to understand their compliance approaches and how they affect your projects

Export control and sanctions compliance adds complexity to international open source development. However, publicly available treatment for source code and applicable sanctions exceptions or licenses protect much ordinary open source activity, enabling continued global collaboration within legal boundaries.