Fedora has a code of conduct which begins:
"In the interest of fostering an open and welcoming environment, we as the Fedora community pledge to collaborate in a respectful and constructive manner, and welcome everyone willing to join us in that pledge. We welcome individuals regardless of ability, age, background, body size, education, ethnicity, family status, gender identity and expression, geographic location, level of experience, marital status, nationality, national origin, native language, personal appearance, race and/or ethnicity, religion, sexual identity and orientation, socioeconomic status, or any other dimension of diversity."
However, Fedora is also sponsored by companies domiciled in the USA: https://docs.fedoraproject.org/en-US/legal/export/
If these policies should be in conflict, which one supersedes the other?
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.
Metadata Update from @jflory7: - Issue close_status updated to: no action needed - Issue status updated to: Closed (was: Open)
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
Metadata Update from @fed500: - Issue status updated to: Open (was: Closed)
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
Metadata Update from @jflory7: - Issue assigned to jflory7 - Issue tagged with: Needs Review, policies
@fed500 Thanks for re-opening with specific clarifying questions. I will also seek input from Red Hat Legal on this matter.
CC: @ref
Log in to comment on this ticket.