Abolish Fedora Project Contributor Agreement #410
Labels
No labels
category
budget
category
code-of-conduct
category
docs
category
elections
category
events
category
initiatives
category
mindshare
category
policies
category
spending-request
category
Strategy Summit
category
trademarks
Next Meeting
state
resolved
good first issue
help wanted
needs
changes
needs
reporter feedback
needs
triage
needs
vote
role
engineering
role
fca
role
foa
role
fpl
role
initiative lead
role
mindshare
scope
bug
scope
improvement
scope
new
state
approved
state
blocked
state
duplicate
state
invalid
state
wontfix
No milestone
No project
No assignees
20 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
council/tickets#410
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The FPCA was introduced in ~2010 as a replacement for the controversial Apache-style Fedora ICLA which apparently Red Hat Legal asked Fedora to begin using sometime in the mid-2000s. The FPCA was an important and progressive advance for its time. However, as time went on (in large part growing out of Fedora's experience) Red Hat retreated from its partial flirtation with use of contributor license agreements for FOSS projects. Red Hat never used anything like the FPCA for any other project (although CentOS has some informal contribution guidelines that are based on the FPCA). Today Red Hat deliberately does not use CLAs or other types of contributor agreements (apart from the DCO) for projects as a matter of legal policy. Fedora, as a project closely connected to Red Hat, is the exception.
There have been some (at least theoretical) problems associated with the FPCA. It hasn't been clear (to me at least) whether it is supposed to extend to all Fedora-related project activity, thus I think the FPCA may in some cases lead to less certainty about licensing of contributions rather than more certainty The concept of "default licenses" has led to some interpretive problems for the licenses in question. It is not really clear whether the default licensing feature even applies to non-explicitly-licensed code contributions to repositories that are pretty clearly under a particular open source license. The specific issue of licensing of spec files is not really super important and could be handled in various other ways.
I recommend getting rid of the FPCA in favor of a looser set of guidelines around licensing of contributions that would cover all Fedora contributors, and perhaps a recommendation that Fedora-related projects use the DCO (Signed-off-by:) practice.
I've created a topic on Fedora Discussion for this ticket.
Please keep this ticket focused. Discuss there, and record votes and decisions here. Thanks!
@ref can you please address the comments in the Discussion thread.
Several Council members have raised concerns and indicated opposition to the proposal. Alternatively, we can close this as deferred.
Metadata Update from @bcotton:
Metadata Update from @bcotton:
Metadata Update from @ref:
Hi, I am reopening this ticket and I have responded to a bunch of the comments in the referenced Fedora Discussion thread.
Metadata Update from @jflory7:
Option b:
+1, option b
+1 Option B
+1
+1 Option B
+1, option b
+1 Option B
+1
+1
+1
+1 Option b
Point of order. This is subject to the Policy Change Policy and I see no evidence that's been followed here.
Excellent point Ben, thank you for bringing this to our attention. In order to comply with the policy changes policy, the votes of the council in this context can only be applied to the approval of a proposal to abolish the FPCA. This proposal will have to be publicly communicated with the fedora community first, in order to be in a position to accept this change or not.
A proposal will be written and communicated by the council to the fedora community, and this ticket will remain open until a decision, inclusive of feedback from the wider community, has been reached.
This dropped off the councils to-do from last year, but we are still in favour of converting the FPCA to a policy instead and use a CAPTCHA in FAS. @mattdm will work on this and we will use the policy change policy process to forward this work.
Metadata Update from @amoloney:
Metadata Update from @amoloney:
@mattdm is no longer a member of Fedora Council. Therefore, I am unassigning this ticket and labeling as
Needs Reviewso that we can identify a new owner.Metadata Update from @jflory7:
Metadata Update from @jflory7:
Looks ike this was agreed on and not actioned.
Ok this is the current summary for this ticket, brought to you by Google Gemini.
Prompts used: Summarize this ticket -> Summarise the discussion thread -> Summarise both ticket and discussion.
Output:
The Proposal: Why it was raised
The ticket was opened by Red Hat legal counsel Richard Fontana (@ref). He proposed abolishing the Fedora Project Contributor Agreement (FPCA) in favor of looser licensing guidelines or a simple Developer Certificate of Origin (DCO / "Signed-off-by" process).
His primary argument was that Red Hat had shifted its legal policy away from Contributor License Agreements (CLAs) for almost all other open-source projects. He argued that the FPCA was an outdated exception that created unnecessary corporate confusion, left ambiguity about whether it extended to all Fedora-related activities, and caused interpretive problems regarding "default licenses."
The Community Backlash: Why the Council hesitated
When the conversation moved to the Fedora Discussion forum, the Fedora Council and community members met the proposal with significant skepticism and several -1 (opposing) stances due to practical and legal complications:
Ripping Out Infrastructure: The FPCA group (historically called the "CLA" group) is woven into Fedora’s systems. For example, the elections system checks for an FPCA signature as a metric of project commitment to determine voting eligibility. Ripping it out would require replacing those verification checks across multiple platforms.
The Nightmare of Repository Boilerplate: Without a blanket agreement, every single repository, code file, and .spec file would need explicit licensing headers. With over 35,000 Fedora repositories, community members worried this would create massive administrative overhead.
The Gap in Non-Code Contributions: The DCO model works well for code (like the Linux Kernel), but Fedora has a massive community of non-code contributors creating artwork, badges, event presentations, and documentation. These creative assets are rarely explicitly licensed by authors. The FPCA provides a critical fallback—automatically licensing unannotated content as CC-BY-SA and code as MIT—which protects the project from contributors later pulling their work or demanding royalties.
The Loss of Retroactive Upgrades: The FPCA allows Fedora to upgrade project-wide default licenses cleanly (as they did when transitioning from CC-BY-SA 3.0 to 4.0). Without it, managing future license updates across decades of mixed content would become legally impossible.
The Lone Point of Agreement
The only major defense of the proposal came from contributors working at large enterprises (such as Meta). They noted that because the FPCA looks like a formal legal agreement, corporate lawyers often insist on vetting it before employees can contribute to Fedora. Replacing it with a non-signature model would undeniably lower the barrier to entry for corporate developers.
Final Outcome
Rather than supporting total abolition, community consensus leaned toward reforming the FPCA instead of killing it—such as updating its defaults (e.g., moving from CC-BY-SA to the less restrictive CC-BY) or modernizing the language to appease corporate legal departments.
Because the proposal faced heavy opposition and required a massive implementation plan that the reporter did not provide, Ben Cotton changed the priority to "Waiting on Reporter" and ultimately closed the ticket as deferred.
Aoifes 2c:
This looks almost accurate, and I would be confident to discuss this ticket from this point with other members of council to see what to do next with it. What it missed was at the Council F2F in Feb 2024, the sitting members at the time voted to convert the FCPA to a policy and use a CAPTCHA in FAS. That idea is worth revisiting to see if:
I confess that I didn't look closely at the discussion that followed initiating this ticket (indeed I still haven't but am relying on this summary). I think I mainly proposed this because I wanted to make clear as a matter of record that Red Hat is not forcing Fedora to use a contributor agreement -- that in fact Fedora is doing so despite Red Hat's preferences, which may be fine in some sense. Over the years I saw pro-CLA forces use the existence of the FPCA to argue, inaccurately, that "Red Hat endorses CLAs" when in fact Red Hat was a leading voice in the (substantially successful IMO) anti-CLA movement that started around 2010.
There are a few points that concern me so even if they're not really that relevant anymore I want to comment on them:
This is at best partially correct. You do need some sort of explicit licensing notices somehow, but it could reasonably be done in most cases at the repository level or via some sort of visible general policy document. To say that expecting explicit licensing for "every single repository" is administratively burdensome seems wrong - it's what is baseline acceptable as good practice in open source development. To the extent that there are Fedora repositories today that have no indication of licensing on the theory that people can fall back on the FPCA, that is problematic for several reasons.
Okay but this can be handled in other ways besides the traditional use of the DCO, or a contributor agreement, etc. Plenty of projects deal with this (even if the situation is less "massive"). Has anyone in Fedora's history tried to pull back their work and demand royalties? (I realize you could argue that, if not, this was a sign that the FPCA and the predecessor CLA were working as expected.)
I mean, it would become less convenient perhaps, but not legally impossible, and there is a cost to the project adopting such updating mechanisms that bypass direct agreement from the contributor.
This doesn't make any sense to me. Why should Fedora have a goal of "appeasing corporate legal departments"?
I suspect people would be unhappy about moving to less restrictive licenses for our artwork too. It's a pretty strong norm to use share-alike licenses for free culture content, which is why Fedora uses it.
Wait, pause ⏸️ I think the AI misled us on changing from CC BY-SA 4.0 to CC BY 4.0. To reiterate what I think is a shared belief, the goal is not to change licensing terms; it is a change in how the protections for Free Software and Open Source, partially encoded now into the FPCA, are upheld in a different agreement flow and user grant of consent with FAS.
@ref wrote in #410 (comment):
We are discussing policy for Fedora Forge in in #558. I remember when GitLab.com got onto us because they wanted all repositories to have open source licenses, since they granted us free open source community perks. While Pagure never had this requirement, I think people have generally had a practice of licensing works in our hosted repos. However, maybe this is changing now.
Is it worth creating detection and alerting on whether a repo in the Fedora Forge uses an unacceptable license or is missing a license? Do any of these license scanning tools hook into something like Forgejo?
@ref wrote in #410 (comment):
To split out the change of policy topic from the change of consent mechanism topic, do you mean to say that a vote of contributors would be more powerfully upheld as legitimate, if future revisions were amended to this FPCA-v2 policy?
@ref wrote in #410 (comment):
I bet on Beefy Miracle that someone, somewhere, sometime suggested this in public, and then Gemini assumed it was legitimate. To gain the required trust to make this change of delivery mechanism from the FPCA to a FPCA-v2 mechanism, the actual substance of the current FPCA should be upheld as much as possible. So… no license changes to the default licenses. As a reminder, any repository may license Fedora contributions under any of the Allowed Licenses and this is also acceptable.
Furthermore, a copyleft approach likely aligns best with the values and beliefs of the wider Linux contributor ecosystem, given the kernel upstream itself is a GPLv2 project, as well as many of our various Linux desktop projects.
I think this somewhat misses the point. We have 20000+ package repositories, and the overwhelming majority of them have no indication of their license (my educated guess would be ~99.9%: the only package repositories that I've ever seen that use a custom license are for Java packages that originated with the JPackage Project - for example ant - which use a BSD-3-Clause license). Adding explicit licensing information to all those repositories would be a huge amount of churn.
So unless there are actual problems with the current FPCA I would vote against dropping or changing it, just due to the large amount of churn and potential confusion it would cause.
@decathorpe wrote in #410 (comment):
I should have clarified, I wasn't thinking of package repositories at all, so the situation is therefore probably not that bad. I do not expect package repositories to have some conventional indication of a repository license, and this is precisely where a well-communicated meta-project-policy (in place of something like the FPCA) can be useful.
@jflory7 wrote in #410 (comment):
As I indicate in my reply to @decathorpe, I didn't understand that the "over 35,000" repositories largely referred to Fedora package repositories (though I now see this should have been obvious).
I would submit that the FPCA doesn't give you much that's useful for package repositories. It makes clear that spec files are under the MIT license; fine, but they're pretty thinly copyrightable (I'd argue) to begin with. Other stuff in package repositories would be better treated as subject to the applicable original license (in the case of a copyrightable patch, say) or else is likely not to be copyrightable. It's the things other than package repositories that always troubled me. Does the FPCA apply to any possible Fedora-related repository, no matter where hosted, for example, no matter how tangentially related to Fedora it might be?
@jflory7 wrote in #410 (comment):
Yes (except I'm not sure what you mean by FPCAv2). Those who have been around for a sufficiently long time may remember the relicensing of Fedora documentation from (gasp) the OPL (without so-called 'options', to be sure) to CC-BY-SA-3.0, which if I remember correctly could have been handled automatically by virtue of the ill-conceived pre-FPCA Fedora CLA which Red Hat apparently imposed upon Fedora in its early days. But the Fedora docs subproject was careful to handle things almost as though no such convenient relicensing mechanism existed.
Please let's not go there. Packaging is a reflection of the software, and enough things are weird and complicated that it's hard to say something like that firmly without upsetting a lot of people.
It is technically supposed to apply to pagure.io and now forge.fedoraproject.org. As for other places? It's trickier to argue. But it has implicitly applied to gitlab.com/fedora and gitlab.com/CentOS as well (which are both managed by FAS/FPCA). We've never set up the necessary arrangements to have a similar enforcement for Fedora GitHub organizations, and I am unsure if there is a capability for codeberg.org yet.
I guess I'm gonna have to read up on the prior discussion elsewhere... but for the moment..
@ref, its 3 years later.. does the top post here still encode your state of the art thinking as the originator? Just based on the top post here in this ticket... what if we started not by removing the contributor agreement mechanism.. what if we started by introducing a DCO process? Does that do anything useful from your pov? Does introducing a DCO process without making any other changes address some of the ambiguity concerns you presented?
I find the summarization's applicability of a DCO process.. perplexing. We should be able to use/require a DCO process for any git based contribution... whether its code or artwork( i just checked the badge submissions are git commits) or something else. But I am sensitive to the concern that a DCO process would have gaps for any type of contribution that is not a git commit. The wiki pages come to mind just off the top of my head . We'd have to have some other guidance for the non-DCO contributiions, its likely going to be in the same shape as the existing FPCA in terms of how its implemented as a catch all agreement when getting a fas account.
@jspaleta wrote in #410 (comment):
Pretty much, but I feel like the main point (the FPCA is now kind of strange, possibly more confusing than helpful, and something I'd contend present-day Red Hat would not want to be associated with) is not being well understood, probably because I mostly didn't say it clearly or explicitly, except for the part about it being confusing.
It isn't necessarily a bad idea (I like the DCO myself) but I'm not sure having both the DCO and the FPCA is going to clear everything up. The DCO refers to the (often absent) "license indicated in the file". If there's no license in the file, is the license being certified, as it were, the documented global license of the repository (this is typical open source folk-understanding) or is it the "default license" of the FPCA?
A lot (I think) of Fedora-related projects that are arguably covered by the FPCA use the DCO already.
I think there are other ways you could deal with that besides using the FPCA mechanism.
@amoloney wrote in #410 (comment):
I'd like to ... gently push back against Meta being named here. We have several active contributors and do not see any issue with the FPCA as it stands, as far as I know. And we don't have a problem with projects that require contributor agreements in general.
Why not have the FPCA for code stuff and an agreement that all of your non code work is public domain (or some other license)
@jflory7 wrote in #410 (comment):
Given it also did the FUD on Meta (which we deserve as an AI shop, I guess) ... can we... maybe not use AI for things like this? We're wasting people's (especially @ref's) valuable time responding to hallucinations
@salimma wrote in #410 (comment):
+1, never use AI for high stakes decisions such as this one
@ref wrote in #410 (comment):
@ngompa wrote in #410 (comment):
Is there consensus about this in the distribution community? I notice that Debian, which is quite meticulous about this, explicitly has an example showing how packaging metadata can be licensed separately from the rest of the source code. Implying it does matter.
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#examples
There is general consensus in the packaging community that packaging data is copyrightable work. That's why the FPCA declares a default license in lieu of doing what Debian does (declare separate licensing for packaging data).
Ack on the no-ai, and fully agree it did not summarise this years-old ticket well.
Fyi that was the intent - to try to summarise the discussion in the ticket and in the discourse post so council members who were not part of the council when this ticket opened, or subsequent years it was open for, could have a kind of starting point. I am one of those said council members. The summary was never to be used as something we make a final decision on.
Regardless, Gemini did not summarise it well, or even accurately. Test failed, lesson learned 🫡
Regarding this ticket, I dont think we are in a position to change or remove the FPCA at this time. It is to embedded in the projects policies (packaging, elections, etc) to which we are unlikely to have any time to scope a plan on how to handle these changes properly.
I suggest we close this ticket as in-actionable for now. We may have the opportunity to revisit this topic in the near future, but right now I dont see council having capacity for this change.
+1
@amoloney wrote in #410 (comment):
+1 to close as deferred. (Maybe this is worthy of a new
state/label, since we had a "deferred" close status on the previous Pagure.io repo.)I would like to see a successor to the FPCA for the reasons that @ref outlined above. What this ticket currently lacks is a clear proposal for what comes next. The complexity of this ticket understandably makes it hard for anyone without both a deep understanding of Fedora history and a modern legal outlook on open source licensing to propose a successor to the FPCA. So, closing as deferred is sensible to me, because if we did have a concrete proposal to review and discuss, I anticipate that the Council would be more ready to vote in favor of change.
Since we have been having this discussion on-and-off since August 2022, it makes more sense to me for us to clear this ticket from the Council backlog and address other pressing matters which are more actionable than this ticket is currently.
@amoloney wrote in #410 (comment):
+1, I also agree with @amoloney to close this ticket for now
+1 on closing and deferring to when we have capacity.
Following the decision reached by Council during yesterdays meeting[1], we will close this ticket as 'deferred/wont fix'. Unfortunately council members do not have the capacity to due the necessary due diligence required to propose either an alternative to the FPCA or understand the impact of removing it, or even changing it, would cause.
[1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-07-29/fedora-council-bi-weekly-meeting.2026-07-29-14.00.html
If no one has a strong objection, I plan to revise the Fedora documentation to make clear that the Fedora Council has made this decision despite the recommendation from Red Hat Legal, so that I can point to something the next time someone says "Red Hat supports CLAs, look at the FPCA" or "Red Hat forces Fedora to use the FPCA".
That seems like unnecessary verbiage to add to the documentation. If you want to have materials describing what it does and what it is not, that's fine. But "despite the recommendation from Red Hat Legal" is only going to create more confusion.
@ref No objections to helping keep track of history and decisions in docs, so we can avoid having the same conversations in perpetuity.
@ref I have no objection to put it in the FAQ section of the FPCA docs page? Maybe something like:
'Does Red Hat require Fedora to use the FPCA'?
'No, Fedora chooses to/Red Hat would prefer or whatever you think is better wording: , see council decision(ticket link).'
And I forgot the link https://docs.fedoraproject.org/en-US/legal/fpca/