Conflict of Interest Guidelines/Policy Draft - Feedback Please

Project Discussion
1

Hi all,

About 18 months ago there was a decision made by a governance group in Fedora that removed someone’s ability to contribute to the project in a certain way. This decision was later overturned and a number of improvement opportunities came out of what was not the nicest of scenarios for anyone to be in. One of those improvement opportunities was to look into creating a Conflict of Interest policy or guidelines the project governance groups could use if they ever find themselves in a situation where they need to make a very big decision about someone or maybe even something, and a potential conflict of interest could occur.

Following our last meeting, Council had agreed to publish the draft of a Conflict of Interest policy that had been working on. It has been in a hackmd file for a few days and now and we would like more visibility on the draft.

Very Important: This draft is a draft only. This is not canon. We, the council, would like to hear from our community your thoughts on:

  1. Needing a conflict of interest policy or guidelines, and if yes
  2. The suitability of the one below for our projects needs.

The council ticket is >>here<< and you can read it on hackmd >>here<< too, in case you prefer that view.

Council will be meeting next Wednesday, 29 July 2026. We intend to discuss this topic again during this meeting (and probably after that too) and would like to have some feedback from. the community to consider as well. So, with that being said, below is the current draft of a Conflict of Interest policy/guidelines:

Fedora Conflict of Interest Policy - This is a DRAFT

This policy is a DRAFT. Its not even close to being a real thing so please keep that in mind when reading. The Fedora Council are examining whether we need this type of policy or not.

Fedora Project Conflict of Interest Policy

Note: The initial text of this document was generated using NotebookLM, and then revised using human editorial control.

This document outlines the Fedora Project’s policy regarding conflicts of interest within its various decision-making groups. This policy is designed to foster transparency, trust, and accountability across the Fedora community, acknowledging the collaborative and often interwoven nature of Open Source development and individual self-interest.

  1. Purpose This policy serves to establish a framework for identifying, disclosing, and managing actual, potential, or perceived conflicts of interest within the Fedora Project. Its primary goal is to ensure that all decisions made by Fedora Project groups (defined below in Scope) that affect a person’s ability to participate in the Fedora Project are considered fair, impartial, and aligned with the best interests of the Fedora Project and its community.

  2. Scope This policy applies to all individuals and groups participating in decision-making processes within any Fedora Project group or team operating beneath the Fedora Council, including but not limited to:
    Engineering Teams, such as FESCo, Engineering subprojects, Special Interest Groups (SIGs), Working Groups, and other engineering-focused teams.
    Mindshare Teams, which focus on outreach, brand, and other non-engineering activities.
    Program Management activities related to release planning, scheduling, and status tracking.
    Any other ad-hoc or standing groups or teams responsible for making decisions that impact the Fedora Project.

  3. Definition of Conflict of Interest For the purposes of this policy, a conflict of interest (COI) arises when an individual’s personal interests, or the interests of an organization they are affiliated with, could reasonably be seen to influence, or appear to influence, their ability to make objective decisions on behalf of the Fedora Project. Personal interests may include financial gain, professional advancement, personal relationships, or loyalty to another organization.

  4. Core Principles of Conflict Management The Fedora Project operates on principles that acknowledge the realities of its community and contributors:
    Expectation of Conflicts: Due to the nature of the work within an Open Source project and the involvement of individuals with diverse affiliations and self-interests (including those whose employment is tied to Red Hat, which sponsors Fedora), conflicts of interest are expected to happen frequently. The acknowledgement that such conflicts are inherent is a foundational principle of this policy.
    Communication and Transparency: The primary expectation is that individuals will openly and proactively communicate any actual, potential, or perceived conflicts of interest.
    Not Automatically Disqualifying: The mere existence of a conflict of interest is not assumed to be disqualifying from participation in a decision. The Fedora Project recognizes that valuable contributions come from individuals with various backgrounds and affiliations, and a conflict of interest does not inherently imply misconduct.

  5. Disclosure Process Any individual involved in a decision-making group who believes they may have a conflict of interest related to a specific discussion, vote, or task is expected to:
    Declare the conflict as early as possible in the relevant discussion. This disclosure should be made clearly and openly to the other members of the group as part of regular group communication.
    Recuse themselves from the decision process

  6. Conflict Remediation Individual decision-making groups are encouraged to reach consensus among themselves with regard to establishing what is disqualifying and what actions should be taken to remediate the situation. If remediation is necessary, it should be done in such a way that actions minimize limitations on participation.

  7. Conflict Escalation If the decision making group can’t reach consensus as to whether a conflict is disqualifying or on what remediation actions to take, the group may choose to escalate to the Fedora Council for review.
    Role of the Fedora Council Members of the Fedora Council may take on any of the roles described below to help navigate situations where a conflicts of interest occurs:

    • Mediator: The Fedora Council will act as the primary mediator in situations where the impact of a conflict of interest cannot be mitigated satisfactorily within the decision-making group itself, or when a dispute arises regarding the existence or nature of a conflict of interest.
    • Ultimate Decision-Maker: The Fedora Council may act as the ultimate decision-maker in situations where a declared conflict of interest may result in disqualifying an individual’s participation in the Project. specific decision or activity and what remediation is appropriate. The Fedora Council may suggest appropriate remediation steps to the decision-making group in an effort to refrain from acting as the ultimate decision maker. The council may also, at its discretion, overrule a decision made by a particular group if a clear conflict of interest in the decision is found.
    • Remediation Authority: The Fedora Council will determine what remediation steps should be taken on a case-by-case basis. This approach allows for flexibility and consideration of the specific context and severity of each conflict.
    • Examples of Remediation: Remediation steps, determined by the Council, may include, but are not limited to: recusal from specific votes or discussions, abstention from particular decisions, temporary removal from a specific working group or decision making body, or simply full public disclosure of the conflict without further restriction.

  8. Compliance and Review All participants in Fedora Project decision-making groups are expected to adhere to this policy. This policy may be reviewed periodically by the Fedora Council to ensure its continued relevance and effectiveness within the evolving Fedora Project ecosystem.

3 Likes
2

I think this is a pretty good start/draft though I’d like to ask for clarification on something as it could be that my brain may be misunderstanding.

In section 5, the policy states:-

However, section 4 also states:

2 Likes
3

I also believe that Recuse themselves from the decision process is too strong. It has been repeatedly agreed on FESCo that change owners, who happen to be FESCo members, may +1 their own change proposals. It should also be totally OK to run for a body to fight for my own interests. As long as disclosure is made, I don’t believe we should automatically require abstentions.

5 Likes
4

Parts of the policy are very general and applicable to all decision-making process in Fedora and other parts are specific to decisions “that affect a person’s ability to participate in the Fedora Project,” which I assume amounts to temporary bans, bans, or permission revocations (but that should be spelled out in the policy). Is this intended as a more overarching policy on Fedora governance or one specifically focused on conduct issues or policy violations that lead a specific group to consider enforcement actions against a participant/contributor to Fedora?

I think these two cases might need to be handled by separate policies, since the way decisions are made for issues involving a specific person vs. decisions about technical matters (even if that matter is contentious or controversial) are completely different — and for very good reason. Compare the CoC committee’s heavy focus on confidentially to protect project contributors’ safety vs. the very public and open way in which other Fedora governing bodies generally operate.

As a FESCo member, I don’t think that this policy provides sufficient clarity about how our processes and policies should be adapted. It has long been understood that members can vote on their own proposals, and members will usually explicitly point out their stake in the proposal when voting (e.g., submitting +1 (as a Change owner) instead of +1).

As for our policies that can lead to permissions being revoked, we have the Non-responsive maintainer policy and Package sponsor policy § Revoking Sponsorship. FESCo also has authority over the provenpackager group. Again, I’m not sure what actionable steps this policy is actually prescribing to address CoIs or interpersonal conflicts that can arise during these processes.

5

Okay, sorry, ignore the last two paragraphs of my previous response. I’ve re-read the policy text and skimmed the linked ticket, and it sounds like the goal is not to be overly prescriptive and pretty much generally remind bodies to consider conflicts of interest when making decisions and escalate to Council if necessary. If the Purpose is just intended to provide general guidance to other governing bodies, can the proposal state that more explicitly?

I think that makes sense, sans the aforementioned issues with the recusal requirement. I guess the main case where recusal MUST happen is when a decision “affect[s] a person’s ability to participate in the Fedora Project,” so maybe that part could be worked into 5. Disclosure Process, along with the other requested clarifications to that section, instead of being stated as the Purpose of the entire policy?

I also think the policy should state that Council should only consider overtuning decisions when the potential conflict would actually affect the outcome. E.g., if a vote is unanimous but then one person is determined to have a COI after the fact, the majority of the body would still have approved the decision, so revisting it wouldn’t make sense.

1 Like
6

I think the self-contradictions are resolved when assuming that point 5. item 2 “Recuse themselves from the decision process” only applies to the decision process for whether the previously declared conflict of interest disqualifies this person or any remediation actions should be taken (point 6.) - in which case I think that would be fine, but if this interpretation is indeed correct, this should be made explicit.

7

I understand that the escalation part of the policy draft can’t apply (Council can’t escalate to itself), but I think the rest of this should also apply to decision-making within Council itself.

4 Likes
8

Indeed - I would argue that with a significant fraction of Council members being appointed and not community-elected (directly or indirectly), having a Conflict of Interest policy here would be even more important.

Since Council can’t escalate “up” in this case, it can escalate “down” - i.e. to FESCo or Mindshare - depending on the topic?

2 Likes
9

I appreciate the work on this. My one concern: policy creep. Each new document is one more thing contributors, governance members, and people considering running for a seat need to read, understand, and navigate. Over time these accumulate, and the project becomes harder to engage with, not easier.
Could this be a paragraph in an existing doc rather than its own policy? What’s the lightest-weight version that still addresses the original incident?

4 Likes
10

On that matter, there is some interesting privacy problem here.

In 2022, the Court of Justice of European Union (eg, the highest possible court in the Union, read the equivalent of the US supreme court for US folks) had to decide on a case related to ethics and disclosure of private information and the interplay with GDPR (see case C-184/20 ). Notably, the court decided that disclosing romantic interests is equivalent to disclosing sexual orientation (kinda obvious in retrospect, but seems lots of people were surprised…), thus triggering elevated obligations under GDPR to process that kind information, eg you need to have a reason under article 9 and article 6 instead of just article 6. The interpretations of the CJEU are 1) binding 2) across the whole European Union (and also likely important for UK).

And I think that’s a big deal, because this can get someone in jail at least in France (see article 226-19 of the french Penal Code). In practice, I suspect no one will actually go physically in jail mainly because we are out of capacity, but someone could become a felon, with all the downside it imply. The listed penalties are either up to 5 years of jail and a 300k fine for natural persons, or 1.5M€ of fine for a juridical person, eg a corporation.

I think the policy should clarify that the people should only disclose there is a conflict of interest and not give any more information about the details if this imply a 2nd person, especially if this is not a public matter. I am sure no one in the Council want to be processing informations that fall under GDPR article 9 by error and the only solution for that is not processing the details unless they are explicitly made public. Under the principle of information minimization (as required by article 4 of GDPR), there is also most of the time no reason to get details of the conflict of interest. And in fact, even if people consent on giving the information, this would be more than dubious in a work context (see p20/21 of the guidelines on this topic) and put companies with presence in Europe or under GDPR-like regulations at risk (eg, Brazil, Canada, and others ) .

Obviously, this would make a leak of private tickets a lot more problematic.

And even without GDPR, I think having a policy that force people out of the closet would be bad.

I know this is not the intent, but that would be the result.

11

Thank you all for your feedback so far - please keep it coming! :slight_smile:

I will work on redrafting this in the hackmd to include some of the changes proposed thus far, and here are my thoughts on some of the excellent points raised:

  1. I believe this policy should only apply to governance groups - Council, FESCo, Mindshare and Code of Conduct committee. If the language makes this policy sound applicable to every group in the project, we need to edit that so its clear who this would apply to.
  2. I agree that this policy should not apply to FESCo members who are change owners voting on their change. And I have seen time and time again good practice from FESCo members when voting on their own changes that they state (own change) or something similar. I dont feel the project needs more than that in those circumstances.
  3. I wholeheartedly agree this policy should and will apply to Council as well. The escalation part might need to be revisited to have some kind of mechanism there that Council can use too.
  4. To @cverna 's point on policy creep - I think this could live inside the decision making sections of each of governance groups docs pages. Ultimately this is what this policy should assist with.
  5. I would agree that we need to reword the policy to not require someone to disclose information about why they have a conflict of interest, only that they do have one. I’m unsure how to address point 3 @misc :confused:
3 Likes
12

I think this document is unnecessary.

The initial motivation was the proven-packager-privilege-revocation issue. But that decision — with all its faults — was not influenced in any strong way by conflicts of interest. The current proposed policy wouldn’t have disclosed anything that was not known to all participants and wouldn’t have informed the decision in any useful way.

I see various decisions taken in Fedora slowly or erroneously (in hindsight), but those issues have little to do with conflicts of interest. I’d name the following reasons: lack of time to investigate details, misunderstandings about scope, preferences for certain technologies or approaches, overambitious plans, tiredness, lack of synchronization, etc. In some cases personal sympathies or trust/distrust between people exists, but those not the obvious types of relationships that would be disclosed under the proposed policy. (To put it more directly: I think that a FESCo member may in borderline cases vote for/against a propal if they like and trust/dislike or distrust the proposer, but not because of romantic or intimate or financial or career relationships.)

I think this proposal is trying to transplant a policy that is useful in other contexts, where personal conflicts of interest can be much more unexpected and can have a much bigger impact, into an environment where pretty much every decision has some potential conflict of interest, but those conflicts are known and unavoidable when we’re all working on a shared project.

EDIT: I referred to FESCo mostly in my reply. But the same logic applies even more to every SIG, engineering subproject, working group, and team.

3 Likes
13

In the current form the definition of the conflict of interest can be translated as
“you have an interest in doing something for whatever reason”.

All FOSS contributions are done based on some interest. Labelling all interests as potential conflict and then specifically provide an excuse for most of those conflicts being non-disqualifying feels like presumption of guilt.

I would go for something much smaller, something like:

“Decisions regarding Code of Conduct issues and other questions, related to access rights of a specific person in the Fedora Project, should not be made by people who are directly involved in such a conduct.”

All commercial interest, job-related or personal-interest related topics should not be touched at all, imho.

14

I would say that commercial interest and job related conflicts or interests should form the core of the required notifications.

15

And I would disagree :slight_smile:

I don’t say that we do not have conflicts of interests, but I say, and I think it is aligned with what @zbyszek said: conflicts of various interests is the definition of what our project is.

We don’t need more policies to state and govern the obvious. It just brings corporate-style bureaucracy to the human-oriented project.

“Assume good faith” is our default rule of communication. Making decisions based on technical merit and data, publicly and openly, providing the justifications - is our default approach to governance which helps build trust around it.

3 Likes
16

I do see the benefit here of assuming many contributors have commercial interest and thus not caring about it.

Therefore, if we all agree on that point, then there would be little point requiring a policy.

17

Re-reading my own statement,

if we scope down this policy to apply only to decisions which can not be done in public for whatever reason, it might make more sense to me. It will naturally cover code of conduct issues or similarly sensitive topics, which I tried to name in my previous comment.

If a decision can not be fully discussed and justified in public, there is no easy default way to gain trust, and some explicit conflict of interest considerations could help.

Upd: But then maybe we better write a dedicated “policy for making decisions which can not be done in public” instead. In which Conflict of Interest would be just one of the items.

1 Like
18

I’d say some things can’t be solved by policy.

Take RedHat as the most prominent “business interest” as example. RedHat profits from Fedora and Fedora profits from RedHat.

Now, if someone is employed by RedHat and works on Fedora, do they have a potential conflict of interest? They may declare so (as many do on their pre-election interviews), and it will be deemed non-disqualifying, and rightly so.

The important point in decision making is the transparent reasoning, though: Does X argue for a decision because it’s in the interest of company Y, or because they deem the decision good for Fedora?

We’ve had a couple of proposals which were framed technical and turned out to be at least “in line with a company agenda” that became transparent later. Company affiliations and potential c-o-i were known before in these cases, but it would have been necessary to be open about the full context of the proposals. Can this be solved by policy? What are the consequences of not following it?

19

It is more complicated even.

Just a personal example: I was the person who proposed ELN to Fedora. I was also the person who proposed ELN to Red Hat.

To this day many people in the project believe that ELN was pushed to Fedora “in line with the company agenda”. While I honestly believe that I pushed it to Red Hat in line of Fedora agenda. I believed that having such a project was beneficial for Fedora. And I was super proud of myself that I managed to “sell” it to Red Hat management and convince everyone inside Red Hat that it is in line with Red Hat’s agenda at that time :slight_smile:

So who’s interest it was in the end? Mine? Red Hat’s? Fedora? It doesn’t matter.

If someone’s interest leads them through the hoops of the Fedora governing process - good for them.

20

That’s exactly what I meant. You truly acted in the interest of Fedora, according to what you considered best. (Someone might still disagree with you on a technical level, but that’s not the point.) And that’s why I don’t want to have “automatic distrust” based on affiliations.

I’m also aware that transparency is often hindered by company policy or a company’s typical non-open decision process. In your example: You probably can’t openly say “I’m trying to sell this to RH”; OTOH waiting for RH to decide “we want it” and then trying to sell it to Fedora does not make it better either. The middle ground is being open about “it’s good for Fedora and RedHat”, for example, and laying out the technical reasons. In this case, RH working on Fedora as upstream directly benefits both, obviously. And you may have done so, I don’t even remember ELN as being controversial.

What I’ve seen (not in your example) is trying to sell things to Fedora on “lame technical arguments”, and then later an agenda becoming clear. That is what shatters trust, and I still don’t know how to solve this by policy.

1 Like