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.

Open source software flows across borders effortlessly—a developer in Germany can commit code that a maintainer in Japan reviews and merges, creating software downloaded by users in 190 countries within hours. 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

The publicly available exception:

Section 742.15(b) of the EAR provides a critical exception for publicly available encryption source code. This exception permits export 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 exception enables open source cryptographic libraries, secure communication tools, and security software to be developed and distributed globally without individual export licenses.

Notification requirement:

Even when the publicly available exception applies, the EAR requires notification to BIS 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 technically constitutes a violation, even for otherwise compliant open source projects.

Object code considerations:

The publicly available exception 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© (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, making code publicly available through repositories is generally permissible as it does not constitute a "transaction" or "service." However, organizations should understand the distinction:

• Making software publicly available (posting to GitHub, registries) is generally permitted
• 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:

• Making software publicly available does not violate SDN restrictions
• 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 the publicly available exception protects most open source software, 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 restricts access to certain features for users in comprehensively sanctioned countries and regions, including Iran, North Korea, Syria, Cuba, Crimea, and (post-2022) Russia and Belarus. Restrictions have included:

• 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 cryptographic software—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 the publicly available and informational materials exceptions
• 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 open source encryption software—this simple step establishes compliance baseline

3. Ensure genuine public availability of open source releases, avoiding access restrictions that could undermine exceptions

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, the publicly available and informational materials exceptions protect most open source activity, enabling continued global collaboration within legal boundaries.