31.3: Sanctions and Open Source Participation¶

In 2019, Iranian developers discovered their GitHub accounts had been restricted without warning. Repositories became inaccessible; years of work and community connections were suddenly severed. Similar restrictions affected developers in Crimea, Syria, Cuba, and other sanctioned regions. The developers hadn't violated any terms of service—they simply lived in the wrong place. GitHub, complying with U.S. sanctions law as a U.S.-based company, had limited their access to the platform that had become essential infrastructure for global software development.

Economic sanctions—restrictions on commercial activity with designated countries, entities, or individuals—present profound challenges for open source software. Open source operates on principles of global access and universal participation. Sanctions regimes demand restrictions based on nationality and geography. These systems collide in ways that satisfy no one: sanctions enforcement struggles to meaningfully restrict access to publicly available code, while the restrictions that are enforceable disrupt innocent developers and fragment the global commons.

Navigating this collision requires understanding both the legal frameworks driving restrictions and the practical effects on open source communities. Neither dismissing sanctions concerns nor ignoring their costs to global collaboration serves the goal of thoughtful policy.

Sanctions Regimes and Open Source¶

Multiple sanctions regimes potentially affect open source participation, with U.S. programs having the broadest impact due to American platform dominance.

U.S. sanctions programs:

The Office of Foreign Assets Control (OFAC) administers U.S. sanctions programs:

Comprehensive programs: Nearly all transactions prohibited with Cuba, Iran, North Korea, Syria, and the Crimea region
Sectoral programs: Targeted restrictions on specific industries or activities
SDN List: Specially Designated Nationals with whom transactions are prohibited regardless of location

Sanctions prohibit U.S. persons (including U.S. companies) from providing services, including software services, to sanctioned parties. Since major open source platforms—GitHub, GitLab, npm, PyPI—are U.S. companies, sanctions law directly affects their operations.

Informational materials exception:

As discussed in Section 28.4, U.S. sanctions include an exception for "informational materials", including:

"publications, films, posters, phonograph records, photographs, microfilms, microfiche, tapes, compact disks, CD ROMs, artworks, and news wire feeds" — 31 CFR 560.210©

The Treasury Department has clarified that publicly available software generally qualifies for this exception. However, the exception applies to the software itself—not to services surrounding it. Hosting platforms, collaboration features, and private repositories may not be covered.

EU and other sanctions:

European Union sanctions similarly restrict commercial activity with designated countries and individuals. Other jurisdictions maintain their own programs. Multinational platforms must navigate multiple, sometimes conflicting, requirements.

Platform Restrictions¶

Major platforms have implemented varying restrictions in response to sanctions requirements.

GitHub:

GitHub's approach has evolved over time:

2019 restrictions: - Blocked private repositories for users in Iran, Syria, Crimea, Cuba, North Korea - Restricted access to GitHub Actions, Packages, and other paid services - Public repository access initially maintained under informational materials exception

Developer impact: - Accounts flagged based on location signals (IP address, profile information) - Some developers blocked despite living elsewhere or holding dual citizenship - Appeals process created but initially inadequate - Community backlash significant

Subsequent refinement: - GitHub obtained OFAC license in January 2021, enabling full service restoration for Iranian developers - Process improvements for appeals and false positives - Continued restrictions on certain paid services in other sanctioned regions - Ongoing navigation of evolving sanctions requirements

Post-2022 Russian restrictions: - Following Russia's invasion of Ukraine, GitHub suspended accounts at sanctioned companies starting April 2022 - Restrictions varied based on sanctions targeting and company decisions - Individual Russian developers generally retained access - Distinction between legal compliance and corporate policy not always clear

Other platforms:

GitLab: Similar compliance with sanctions requirements
npm/PyPI: Package downloads generally available; account restrictions implemented
Cloud providers: AWS, Azure, Google Cloud restricted access for sanctioned regions
Payment processors: Financial services restrictions affect open source funding

Developer Exclusion and Community Impact¶

Sanctions-driven exclusions affect real developers with real contributions.

Individual impact:

Affected developers experience:

Loss of work: Years of contributions, repositories, and connections inaccessible
Career damage: Open source contributions are resume items and professional credentials
Community severance: Relationships and collaborations disrupted
Stigmatization: Being treated as security threat due to nationality

Community impact:

Open source communities suffer:

Lost contributions: Talented developers excluded from global projects
Reduced diversity: Geographic exclusion reduces perspective diversity
Trust erosion: Community members question platform reliability
Collaboration barriers: Cross-border cooperation becomes more difficult

Specific examples:

Individual stories illustrate the human cost:

Iranian developers with significant open source contributions losing repository access overnight
Crimean developers blocked from projects they maintained
Students losing access to educational resources and collaboration opportunities
Developers caught by false positives due to VPN use or travel history

Community response:

The open source community has responded through:

Advocacy for clearer sanctions guidance
Platform pressure for better appeals processes
Alternative infrastructure proposals
Vocal opposition to overbroad restrictions

Community members have argued that excluding developers based on where they were born contradicts open source's core principle of transcending borders, while platforms like GitHub have emphasized they implement restrictions because they legally must, not because they want to.

Compliance Challenges¶

Organizations face significant challenges complying with sanctions in open source contexts.

For platforms:

Hosting platforms must navigate:

Legal requirements: Sanctions violations carry severe penalties
Detection challenges: Identifying users in sanctioned regions is imperfect
False positives: Over-blocking affects innocent users
Scope uncertainty: What services are covered vs. exempted remains unclear
Multiple jurisdictions: Different sanctions regimes may conflict

For projects:

Open source projects face questions:

Contribution acceptance: Should projects accept contributions from sanctioned regions?
Maintainer restrictions: Can sanctioned individuals serve as maintainers?
Distribution: Can projects distribute to sanctioned regions?
Compliance responsibility: Who is responsible—project, foundation, platform?

For foundations:

Open source foundations must determine:

Membership eligibility: Can sanctioned individuals or entities be members?
Event participation: Can sanctioned individuals attend conferences?
Grant distribution: Can funds be provided to sanctioned regions?
Governance: How to handle sanctions affecting community members?

Practical approaches:

Organizations navigate these challenges through:

Legal counsel: Obtaining specific guidance for their situation
Conservative compliance: Restricting more than strictly required to avoid risk
OFAC licensing: Seeking specific licenses for desired activities
Structural separation: Organizing to isolate sanctions exposure

Most organizations choose conservative compliance given severe penalties for violations, resulting in restrictions beyond what sanctions strictly require.

Humanitarian and Technical Arguments¶

The application of sanctions to open source raises both humanitarian and technical objections.

Humanitarian arguments:

Critics argue restrictions cause disproportionate harm:

Collective punishment: Individual developers are punished for government actions they don't control
Development impediment: Restricting software access hinders economic and educational development
Asymmetric impact: Restrictions affect ordinary people while regimes find workarounds
Civil society harm: Open source tools support civil society, journalism, and human rights work

The U.S. government has recognized some of these concerns through the "Internet freedom" policy, which supports tools enabling communication in repressive environments—sometimes in tension with sanctions restricting the same technologies.

Technical arguments:

Technical realities complicate enforcement:

Publicly available code: Open source code is globally accessible regardless of platform restrictions
Mirrors and forks: Code can be obtained from multiple sources
VPN circumvention: Determined users can bypass geographic restrictions
Enforcement futility: Restrictions prevent legitimate access more than adversarial access

The argument follows: if sanctioned parties can access open source code anyway through alternative means, restrictions primarily harm innocent developers who comply with access limitations while providing minimal security benefit.

Security arguments:

Defenders of restrictions argue:

Service denial: Even if code is accessible, platform services provide value worth denying
Collaboration disruption: Restricting participation has effects beyond code access
Compliance signaling: Enforcement demonstrates commitment to sanctions regime
Incremental friction: Even imperfect restrictions create costs for adversaries

The debate involves genuine trade-offs without clear resolution.

Balancing Competing Interests¶

Sanctions and open source represent genuinely competing interests requiring balance rather than easy answers.

Legitimate security interests:

Sanctions serve legitimate purposes:

Pressuring governments over human rights violations or aggression
Restricting access to technologies with military application
Denying resources to designated malicious actors
Signaling international condemnation

These interests don't disappear because open source is involved. Governments reasonably seek to apply sanctions consistently, including to technology platforms.

Legitimate open source interests:

Open source principles have legitimate claims:

Global collaboration produces better software benefiting everyone
Developer exclusion based on nationality contradicts open source values
Restrictions fragment the commons to everyone's detriment
Technical futility suggests alternative approaches might serve security interests better

Finding balance:

Balanced approaches might include:

Clearer exemptions: Explicit guidance on publicly available software
Targeted restrictions: Focus on specific high-risk services rather than broad exclusions
Better processes: Improved appeals and reduced false positives
Service differentiation: Distinguishing public collaboration from restricted services
International coordination: Consistent approaches across jurisdictions

Recommendations¶

We recommend stakeholders approach sanctions and open source with nuance:

For platforms:

Seek clear guidance from regulators on scope of restrictions
Minimize over-compliance avoiding restrictions beyond legal requirements
Implement robust appeals processes for incorrectly affected users
Be transparent about restrictions and their bases
Advocate for clarity in regulatory guidance

For projects:

Understand exposure determining which activities face restrictions
Consult legal counsel before excluding contributors or limiting distribution
Document decisions showing good-faith compliance efforts
Consider foundation affiliation for guidance and liability protection
Distinguish code from services recognizing different treatment may apply

For policy makers:

Provide clear guidance specifically addressing open source scenarios
Consider technical realities in designing enforceable restrictions
Balance interests recognizing costs of broad exclusions
Support exemption processes enabling legitimate activities
Coordinate internationally reducing compliance complexity

For affected developers:

Understand restrictions knowing what is and isn't accessible
Explore alternatives including mirrors, alternative platforms, and exemptions
Document impact contributing to policy understanding
Engage advocacy organizations working on these issues
Maintain perspective recognizing restrictions may change

Sanctions and open source will continue to create tension as long as both exist. The goal is not to resolve this tension—which may be impossible—but to manage it thoughtfully, minimizing harm to innocent developers while preserving legitimate security interests. Neither ignoring sanctions requirements nor accepting overbroad restrictions serves this goal.