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

Project Discussion
1

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

Ticket text:

2

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?

3

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
4

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.

5

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?

6

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.

7

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?

8

This came up in today’s Council meeting and we were directed to add questions to this thread.

  • I am not sure all of our projects are based in pagure, (for example the Design team uses Gitlab) so how would we make sure that every current project was using the correct licenses?
  • What would be differences (if any) in coding projects versus non-coding?
  • How much work would this generate overall, now and in the future?
  • How would we ensure that everyone starting a new project in Fedora would adopt the correct licenses?

That’s my questions for now… For now I am 0 to soft -1 until we can understand what the impacts will be and how we would implement the changes.

9

A question I have: the FPCA has language allowing us to update the default license. We have taken advantage of that in the past, updating from CC-BY-SA 3.0 to 4.0. Would we be able to do something similar for a theoretical 5.0? I like that it allows us to update things retroactively so if there are compatibility concerns we don’t have to deal with “before this date, it’s this license” — and weird questions of what happens when updating text.

10

I’d like to hear more about the concerns here. If it’s mostly a matter of confusion, I think clarifying guidance would be less effort than trying to rip out out of all of the places it is used. And worse, trying to ensure that every repo, website, etc, has the correct language for indicating license and contribution requirements.

11

I am -1 to dropping the FPCA, at least until a few questions are clarified.

The Fedora engineering ecosystem more often interacts with Free & Open licenses. In the non-engineering/mindshare Fedora ecosystem, Fedora contributors create contributions for use by the Project. These contributions are often both ambiguously licensed (if at all) and tied closely to the Fedora trademark. Some examples:

  • Fedora Badges
  • Fedora Zine
  • Design assets for Fedora contributor swag

Could this be an opportunity to increase certainty about the licensing?

While we cannot expect the default license on everything a person ever creates after they sign FPCA, could we limit the “Default Licensing of Unlicensed Contributions” condition on the basis of submitting contributions to Fedora-owned platforms? e.g. Pagure, gitlab.com/fedora/ with FAS link, Fedora Docs, Fedora Badges? This way, we would knowingly ensure the “Default Licensing of Unlicensed Contributions” condition is linked to Fedora-owned platforms for contributions. Plus, because of the historical presence of the FPCA, many apps in Fedora Infrastructure are already FPCA-aware.

I am curious what this means for copyright. The FPCA was never a copyright assignment, but it provided a good-faith assurance that an unlicensed contribution submitted and used by Fedora was being submitted under the default license. The size and scope of the Fedora Community makes it very difficult to centrally manage licensing and copyright assignment. So, something like the FPCA provides an assurance to me that an unlicensed contribution is made in terms that are right for the Fedora Community.

A hypothetical example is the unlikely scenario that a new contributor demands royalties after creating several design assets for a Fedora release party and later claimed ownership of the design assets. Does the FPCA help or hurt us here?

This is the language the FPCA uses today:

“Current Default License”, with respect to a Contribution, means (i) if the Contribution is Code, the MIT License, and (ii) if the Contribution is Content, CC-BY-SA.

If an update to the FPCA is potentially on the table as an outcome of this discussion, I think the default licenses should be updated with a provision about data and switching the Content default license to CC BY:

  1. Data: How does Fedora treat data collected from Fedora systems? The Fedora Community provides ample tools and systems for contributors to collect data about package activity, communication channels, and contribution history. Is this data shared under any provisions? What are the expectations of others using data collected from Fedora systems about the Fedora Project?
  2. Content: Fedora contributor content, especially unlicensed contributions like slideshows, presentations, and video, should be shared without the ShareAlike provision. I believe this broadens the pool of people who can benefit from content created by and for the Fedora Community. Additionally, I think this helps us avoid a topic like compliance for the ShareAlike provision, where pursuit of compliance could be damaging to how a Fedora contributor chooses to respin Fedora-created content.
    • I could see a side for the official Fedora Documentation preserving a ShareAlike license.

This is where I would encourage @ref to weigh in, as I remind that I am not a lawyer. :x: But as a project, I don’t think we are forcing every new project in Fedorato adopt the “correct” license. Actually, anyone can bring any Open Source license that is recognized as a Good license for Fedora. This is something in the current FPCA:

2. Licensed Contributions.

If Your Contribution is Licensed, Your Contribution will be governed by the terms under which it has been licensed.

The edge case where I believe the FPCA is a very good thing for Fedora is its “Default Licensing of Unlicensed Contributions” section. I am still not convinced that FPCA does more harm than good for Fedora. But I concede there are definite gaps in the current FPCA that would be good to either amend or clarify, especially around content and data.