The statement in our code of conduct is fundamental to Fedora's values, as expressed in our "Friends" foundation.

At the same time, we have to follow the law in the places we operate. Currently, the major conflict I am aware of is with sanctioned countries; as our systems are US-based (like, literally, the servers), we can't provide services or accept contributions from people in certain locations (as listed on the page you link). I've looked into getting some exemptions, but this is incredibly difficult.

Anything beyond that... we'll have to figure out.

How does this apply when considering packagers and packages for inclusion in Fedora? In particular:

a) If an openly developed FOSS package has primary developer(s)/maintainer(s) in a US sanctioned region, can it be included?
b) If the sanctioned regions change, or a person changes residence does a package/packager already in Fedora need to be removed? Conversely if the package/packager was not in Fedora, can they be added?

What extent of due diligence is required? For example, this is not at present explicitly checked when going through package review or packager sponsorship process.

Hi @fed500, thank you for your follow-up questions.

Your questions, particularly (a) and (b), explore hypothetical situations concerning packagers and packages. The Fedora Council avoids providing definitive answers to hypothetical questions because the specific details and context of any actual situation are essential for a proper assessment. How Fedora might address a potential situation depends heavily on the precise circumstances at that future time.

As @mattdm previously stated, the Fedora Project upholds its Code of Conduct and strives to foster an open and welcoming community for everyone. At the same time, the Fedora Project and its infrastructure must comply with all applicable laws and regulations in the jurisdictions where it operates. This includes US export laws, as our core systems are based in the USA.

The Fedora Project will continue to navigate these requirements carefully. We make decisions regarding specific packages or contributors based on the actual facts of each case as they arise, always aiming to align with our community values and our legal obligations.

If you encounter a specific, current instance where these legal or policy considerations create an actual barrier to contributing to Fedora, or if you have a precise problem that prohibits a contribution, please present that particular situation. This will allow the appropriate Fedora bodies to examine the specific details and provide a relevant response.

Thank you for your understanding.

a) As a sponsor is this something I need to be concerned about when sponsoring new packagers?
b) Could the following be packaged for Fedora:
https://apps.gnome.org/DrumMachine/

c) There is a related issue for https://bugzilla.redhat.com/show_bug.cgi?id=2316327

with regard to c)
while we wait for a legal opinion on whether the license text should be considered an acceptable license as per the bugzilla discussion for the open-fm, I'm not seeing a policy conflict that is specific to that in process package request. If accepted it will be under the same export laws as all the other packages distributed by Fedora. I should note for context that for the opa-fm upstream sources are hosted on github which has the exact same export control requirements as a US based company.

My interpretation of the issue with the opa-fm package submission appears to me that the upstream (which again is yet another US based vendor, or a series of them in fact) mixed in export guidance language into the top level LICENSE file, and its a matter of legal interpretation as to whether that has materially changed the license from an acceptable BSD 3 clause to something new. But this is the same sort of block any package would have if any additional clause was added to the license.

With regards to b) as its not in process yet as a Fedora asset... I don't want to speculate as to particulars. But to provide some context the software is hosted by GitHub (a vendor subject to the same export controls) the following document is useful information for any future discussion:
https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls

@fed500 Thanks for re-opening with specific clarifying questions. I will also seek input from Red Hat Legal on this matter.

CC: @ref

Just finished review of https://bugzilla.redhat.com/show_bug.cgi?id=2348783
My expectation is it should probably be ok, but I do not track contributor locations.

Upon looking back at the Bugzilla ticket in question, the package repository was created and the Bugzilla ticket status is CLOSED.

The previous information that @jspaleta and I provided about the context with the Code of Conduct remains relevant. At this point, there is no further action for the Fedora Council to take.

To address one of the previous questions about whether a package sponsor should be concerned with this, I think the legal context of the Fedora Export Control Policy says you only need to be concerned if a user informs you that they are contributing from Cuba, Iran, North Korea, Syria, and the Crimea Region of Ukraine. We do not discriminate against people with these ethnic and national origins, but if they are directly contributing from one of these countries, then action must be taken as according to US federal law which we are bound by.

Per recent discussion (#541) and other current events, I hope we can eventually look at removing Syria from this list.

Closing this ticket as no action needed.

This seems like a Don't Ask Don't Tell policy. Given preferences for an open internet, it maybe good to update US lawmakers on the realities of openly developed free and open source software. It may also be good to indicate that the code of conduct is secondary to national legislation, though such legislation may differ from location to location.

I would like to live in a world where public policymakers had a deep, thorough, and nuanced understanding of how free and open source software works, and its role in providing stability and reliability for digital infrastructure. In that sense, I think that Fedora is recognized as a Digital Public Good is meaningful. But we are not US federal policymakers, we are a collection of open source contributors, maintainers, and activists, and so, our plight continues. I am hesitant to modify our Code of Conduct for accounting for differing national legislations as it creates new possibilities of exposing us to risk, and our existing Code of Conduct has already undergone a thorough and detailed legal review in its ratification in 2021.

https://en.wikipedia.org/wiki/FeatherPad
FeatherNotes is currently under review and is primarily developed by the developer of FeatherPad
https://bugzilla.redhat.com/show_bug.cgi?id=2425235

FeatherPad is already packaged:
https://src.fedoraproject.org/rpms/featherpad

IMPORTANT: This issue moved from Pagure to Forgejo

On Wednesday, 18 February 2026, the Fedora Council moved our issue tracker from Pagure.io to Fedora Forge, AKA Forgejo. Using the native Pagure importer tool in Forgejo, we imported git history and all public issues to a new Forgejo repository in the Council organization, forge.fedoraproject.org/council/tickets.

Please update any bookmarks or hyperlinks to the new location.

This specific ticket can be found on the new Forgejo issue tracker below:

https://forge.fedoraproject.org/council/tickets/issues/528