Fedora-Council/tickets ticket #410: Abolish Fedora Project Contributor Agreement

@ref filed Fedora-Council/tickets ticket #410. Discuss here and record votes and decisions in the ticket.

Ticket text:

If @ref says we should drop the FPCA, I won’t argue. I don’t see the FPCA as particularly cumbersome, personally, but it’s not something I’m going to fight for.

As a practical matter, though, are there things that are currently hardcoded to require having signed it? Elections does, I believe, although we can disable that fairly easily. What else?

And what would a “looser set of guidelines” look like?

I don’t particularly like the idea of moving away from the FPCA. In practice, switching away means we need to add a lot more boilerplate to individual package sources and projects.

In openSUSE, for example, all spec files need a license header to declare the licensing intent specifically because there’s nothing that specifies defaults in the project. There’s also the awkward bit that openSUSE as a collective “thing” is licensed GPLv2, and I don’t even know how that squares.

Our FPCA principally sets licensing defaults and ensures we know everyone knows this. That makes the inbound=outbound thing really easy, and makes derivatives from Fedora straightforward from a legal perspective.

We’ve done a particularly bad job advocating for this style of contributor agreements, which I think are much better than what the industry typically uses, but I think it serves our purposes well and ensures there’s a degree of clarity on project code and content that we wouldn’t have otherwise.

1 Like

As I understand conversations with Richard, we can set some rules like “spec files are under this MIT-style license unless otherwise specified” without adding boilerplate but also without requiring a specific opt-in. (I think that’s the fundamental “inbound/outbound” idea.)

I share Ben’s practical concern that we do use it in a different way, as an opt-in signal of deeper commitment to the project (the election thing is just one example). That’s maybe not the right tool for that job, though. And also, that group is still named “CLA” even all these years later, and that causes confusion.

Actually with the new account system, there’s no more CLA…
it’s called “Fedora Project Contributor Agreement”

I kind of like having this at that level so every other parts of the project don’t need to ask for a DC0 type thing. But I suppose pagure could ask that in the ‘create pull request’ and ‘new ticket’ flows?

One datapoint: when I started contributing to Fedora as a Facebook employee, I had to get our corporate lawyers to vet the FPCA and provide their blessing it was ok for me to sign it, which took a few days. The specific concern, as I understand it, was that it “looks” like a CLA even if it actually isn’t. If we could replace it with something that doesn’t require a formal signature, that might lower the barrier for some companies to contribute.

In practice, switching away means we need to add a lot more boilerplate to individual package sources and projects.

In openSUSE, for example, all spec files need a license header to declare the licensing intent specifically because there’s nothing that specifies defaults in the project.

I don’t know whether adding license boilerplate is necessary, but it seems desirable anyway. I sometimes feel that many things would be simpler if pretty much every git repository specified licenses for all files, with REUSE compliance preferably checked by CI. Standardizing and automating everything will just save more time in the end than skimping on license clarity.

If it seems like too much overhead to have license or other meta files in repositories for all package sources, I’ll observe that the conda-forge repositories have license, readme, multiple CIs, code owners, and gitattributes in each and every one of their 16.9k repositories. The files are managed and updated automatically for all repos by a bot. It seems to work fine, or they’d have stopped doing it? Fedora package sources are 35,668 repositories, but, nevertheless.

More automation = better

If every file has the SPDX headers (or REUSE’s separate file for binary files and types that don’t support comments), submitting a commit that changes a file without removing the header effectively means you’re publishing the file, with your edits, together with the license header… so that’s pretty clear that your changes are covered by the license, right? No need for the DCO or a checkbox in the merge request, then?