@ref filed Fedora-Council/tickets ticket #410. Discuss here and record votes and decisions in the ticket.
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.
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?
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.
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.
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.
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:
- 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?
- My preference would be to designate the default data license used by Fedora as either Open Data Commons Open Database License (ODbL) or Open Data Commons Attribution License (ODC-By).
- 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. 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.
There are various other ways to facilitate future updates to the âcontentâ license besides use of the FPCA. Anything contributed under the FPCA in the past would still be covered by its terms. Maximum future licensing flexibility is probably not a reasonable goal for Fedora (this was implicitly a reason for getting rid of the old Fedora CLA).
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?
I donât see how the FPCA solves this problem; it exists whether you have the FPCA or not. The FPCA says you can either explicitly designate a Fedora-allowed license or you can let the default license rule apply.
I suppose there is something unclear in the FPCA because it doesnât really explain what happens if you use an explicit license that is not allowed in Fedora. But is there any evidence this is a serious problem? The vast majority of Fedora activities that involve licensing something involve use of a handful of very well known free software and content licenses.
What would be differences (if any) in coding projects versus non-coding?
If we got rid of the FPCA? No meaningful differences I guess.
How much work would this generate overall, now and in the future?
I think weâd mostly just have to eliminate the requirement to agree to the FPCA and then maybe update some stuff in Fedora legal docs.
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?
I might be misinterpreting this comment but it seems to suggest that the FPCA currently applies to the many thousands of Fedora packages. The original intention was that it would cover spec files (and that in the vast majority of cases spec files would therefore be licensed by default under the MIT license). Iâve noted somewhere (I think) separately why this is actually problematic, but anyway the FPCA was never intended to apply to anything else in Fedora packages. It was not intended to apply to Fedora patches to packages of upstream software, for example. Those should be understood as much as possible as inheriting the corresponding license(s) of the upstream code being patched, to the limited extent the changes in the patches are copyrightable.
If you mean, in the non-engineering/mindshare part of the Fedora ecosystem, could abolishing the FPCA be an opportunity to increase certainty about the licensing, yes, I think in practice that could be so as long as those activities clearly indicate how any created assets or whatever are licensed.
I forget whether I mentioned this but one idea is to do what CentOS did (at least in theory), which is adopt something based on the FPCA but in a licensing policy statement rather than an agreement. I think that would be an improvement on the current situation, though maybe not ideal.
This was certainly its major unconventional feature when it was adopted. A problem though is that the FPCA doesnât really adequately define what âUnlicensedâ means (the definition in the FPCA is essentially circular). The FPCA in its current form isnât actually that useful in providing greater licensing certainty, in part for that reason. I can point to any number of code contributions to Fedora and say it is not clear whether it is licensed (implicitly) under some project license or under the MIT license by virtue of the FPCA.
A policy on data licensing seems like a good idea, but doesnât have to be implemented in an agreement (that is more generally my point about all this, why do you need an agreement when you can just have a policy?) However, I canât agree with your suggested licenses - ODbL is notoriously problematic (we considered it barely approvable for Fedora) and ODC-By is not allowed in Fedora at all (data/ODC-By-1.0.toml ¡ main ¡ fedora / Fedora Legal / fedora-license-data ¡ GitLab).
It helps, but there are other ways to deal with this. If itâs unlikely, why should we worry too much about it happening? Fedora has now existed for over 20 years and to my knowledge no contributor has come back and demanded a royalty for anything. (Speaking more generally about open source, such a thing is extremely uncommon.)
Patches being licensed the same as the upstream code is good. In almost all package repositories there is nothing that indicates how the patches are licensed. Explicitness could be beneficial to any people wanting to reuse the patches.