Hello,
In the FCPA https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement#FPCA_Text, The definition for “Moral Rights Clause Waiver” references “Section 4d of CC-BY-SA”, but that subsection doesn’t exist https://creativecommons.org/licenses/by-sa/4.0/legalcode#s4.
Also, the Other FAQs https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement#Other_FAQs’s first two questions still refer to CC BY-SA 3.0 even though the FCPA has been updated to use CC BY-SA 4.0.
Jason Yundt
On Fri, Aug 20, 2021 at 3:40 PM Jason Yundt swagfortress@gmail.com wrote:
Hello,
In the FCPA, The definition for “Moral Rights Clause Waiver” references “Section 4d of CC-BY-SA”, but that subsection doesn’t exist.
Also, the Other FAQs’s first two questions still refer to CC BY-SA 3.0 even though the FCPA has been updated to use CC BY-SA 4.0.
Indeed, this should have been caught when the FPCA was updated to reference CC BY-SA 4.0 as the default content license. The relevant perceived problematic feature of CC BY-SA 3.0 Unported was fixed in CC BY-SA 4.0.
I don't know if it is better to fix this error or to instead look into eliminating the FPCA requirement. The FPCA is now basically outdated and has the detriment of being pointed to by certain CLA advocates as proof that "Red Hat supports CLAs".
Richard
On Tue, Aug 24, 2021 at 10:09 PM Richard Fontana rfontana@redhat.com wrote:
On Fri, Aug 20, 2021 at 3:40 PM Jason Yundt swagfortress@gmail.com wrote:
Hello,
In the FCPA, The definition for “Moral Rights Clause Waiver” references “Section 4d of CC-BY-SA”, but that subsection doesn’t exist.
Also, the Other FAQs’s first two questions still refer to CC BY-SA 3.0 even though the FCPA has been updated to use CC BY-SA 4.0.
Indeed, this should have been caught when the FPCA was updated to reference CC BY-SA 4.0 as the default content license. The relevant perceived problematic feature of CC BY-SA 3.0 Unported was fixed in CC BY-SA 4.0.
I don't know if it is better to fix this error or to instead look into eliminating the FPCA requirement. The FPCA is now basically outdated and has the detriment of being pointed to by certain CLA advocates as proof that "Red Hat supports CLAs".
But, it's not a CLA? It's essentially project defaults for when new content is contributed to the project. AFAIK, that's how we avoid having to do what SUSE does (stuff license headers at the top of every spec file and other things).
On Tue, Aug 24, 2021 at 10:19 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 24, 2021 at 10:09 PM Richard Fontana rfontana@redhat.com wrote:
I don't know if it is better to fix this error or to instead look into eliminating the FPCA requirement. The FPCA is now basically outdated and has the detriment of being pointed to by certain CLA advocates as proof that "Red Hat supports CLAs".
But, it's not a CLA? It's essentially project defaults for when new content is contributed to the project. AFAIK, that's how we avoid having to do what SUSE does (stuff license headers at the top of every spec file and other things).
I agree, it's not a CLA. It's an un-CLA, as I've said more than once. :-) But those project defaults could be established without having an "agreement". See what CentOS does: https://www.centos.org/legal/licensing-policy/
On the topic of FPCA improvements, it would probably make sense (if the FPCA is retained) to replace the MIT license as the default code license with MIT No Attribution, aka MIT-0, recently approved by the OSI as an open source license: https://opensource.org/licenses/MIT-0 (which would also enable a minor simplification of the FPCA text).
Richard
On Tue, Aug 24, 2021 at 11:06 PM Richard Fontana rfontana@redhat.com wrote:
On Tue, Aug 24, 2021 at 10:19 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 24, 2021 at 10:09 PM Richard Fontana rfontana@redhat.com wrote:
I don't know if it is better to fix this error or to instead look into eliminating the FPCA requirement. The FPCA is now basically outdated and has the detriment of being pointed to by certain CLA advocates as proof that "Red Hat supports CLAs".
But, it's not a CLA? It's essentially project defaults for when new content is contributed to the project. AFAIK, that's how we avoid having to do what SUSE does (stuff license headers at the top of every spec file and other things).
I agree, it's not a CLA. It's an un-CLA, as I've said more than once. :-) But those project defaults could be established without having an "agreement". See what CentOS does: https://www.centos.org/legal/licensing-policy/
CentOS has the disadvantage (up until this point) of being a place that nobody could really contribute meaningful code/packaging to. I suspect we probably need to revise CentOS to match Fedora with CentOS Stream 9 having a more direct contribution model.
On the topic of FPCA improvements, it would probably make sense (if the FPCA is retained) to replace the MIT license as the default code license with MIT No Attribution, aka MIT-0, recently approved by the OSI as an open source license: https://opensource.org/licenses/MIT-0 (which would also enable a minor simplification of the FPCA text).
I would personally prefer we didn't. That has the knock-on effect of making it possible for RHEL folks to not include Fedora changelogs when they fork Fedora for RHEL, since the RPM changelogs are the only attribution we actually *have* in the distribution. And I've personally experienced very positive reinforcement for contributing to Fedora and CentOS Stream by pointing to public attribution via changelogs.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Tue, Aug 24, 2021 at 11:10:41PM -0400, Neal Gompa wrote:
On the topic of FPCA improvements, it would probably make sense (if the FPCA is retained) to replace the MIT license as the default code license with MIT No Attribution, aka MIT-0, recently approved by the OSI as an open source license: https://opensource.org/licenses/MIT-0 (which would also enable a minor simplification of the FPCA text).
I would personally prefer we didn't. That has the knock-on effect of making it possible for RHEL folks to not include Fedora changelogs when they fork Fedora for RHEL, since the RPM changelogs are the only attribution we actually *have* in the distribution. And I've personally experienced very positive reinforcement for contributing to Fedora and CentOS Stream by pointing to public attribution via changelogs.
I agree with Neal here as a deep gut reaction. Recognition is important, even if it is buried pretty deeply from endusers.
That said, uh, we trim changelogs, so if we're arguing that that's the attribution part, we have some digging through git history to do to repair that.
On Wed, Aug 25, 2021 at 7:05 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 24, 2021 at 11:10:41PM -0400, Neal Gompa wrote:
On the topic of FPCA improvements, it would probably make sense (if the FPCA is retained) to replace the MIT license as the default code license with MIT No Attribution, aka MIT-0, recently approved by the OSI as an open source license: https://opensource.org/licenses/MIT-0 (which would also enable a minor simplification of the FPCA text).
I would personally prefer we didn't. That has the knock-on effect of making it possible for RHEL folks to not include Fedora changelogs when they fork Fedora for RHEL, since the RPM changelogs are the only attribution we actually *have* in the distribution. And I've personally experienced very positive reinforcement for contributing to Fedora and CentOS Stream by pointing to public attribution via changelogs.
I agree with Neal here as a deep gut reaction. Recognition is important, even if it is buried pretty deeply from endusers.
That said, uh, we trim changelogs, so if we're arguing that that's the attribution part, we have some digging through git history to do to repair that.
Red Hat is going to have to fix *a lot* of the process around Fedora->RHEL/CentOS if we're going to rely on Git history for attribution. Especially if rpmautospec gets broader adoption. I was personally pretty upset about how the c9s branches were forked from Fedora Linux 34, where all the Fedora history was *gone*. I know that it's still there in the internal RHEL Dist-Git, but the fact they didn't push that for CentOS Stream irritated me. As it is right now, the fact that changelogs are part of the spec file means that history largely carries over from Fedora to RHEL/CentOS in some form. Once that's gone though, that's a license violation, since generated changelogs will lack complete attribution.
As for Fedora changelog trimming, we generally *don't* in the spec file itself, only in the built packages. So the SRPMs have the complete history (or are supposed to, at least).
On Wed, Aug 25, 2021 at 07:50:44PM -0400, Neal Gompa wrote:
As for Fedora changelog trimming, we generally *don't* in the spec file itself, only in the built packages. So the SRPMs have the complete history (or are supposed to, at least).
Some RPMs definitely have "changelog too long, removing old entries" (either as the last entry, or just apparently). Offhand, I think firefox is one example I've seen recently.
On Wed, Aug 25, 2021 at 07:50:44PM -0400, Neal Gompa wrote: ...snip...
As for Fedora changelog trimming, we generally *don't* in the spec file itself, only in the built packages. So the SRPMs have the complete history (or are supposed to, at least).
Well, not since 2018 at least:
(from redhat-rpm-config)
commit 8c5d5de24a177928e5177362532cc22aa604858d (HEAD) Author: Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl Date: Sun Mar 11 15:15:30 2018 +0100
Trim changelog entries older than two years
Inspired by http://gitweb.mageia.org/software/rpm/rpm-setup/tree/macros.in#n22 but changed to two years (3+ releases of Fedora).
diff --git a/macros b/macros index 87b6815..62f320a 100644 --- a/macros +++ b/macros @@ -214,6 +214,9 @@
%__global_compiler_flags -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches %{_hardened_cflags} %{_annotated_cflags}
+# Automatically trim changelog entries after 2 years +%_changelog_trimtime %{lua:print(os.time() - 2 * 365 * 86400)} + #============================================================================== # ---- Generic auto req/prov filtering macros #
On Wed, Aug 25, 2021 at 7:51 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Aug 25, 2021 at 7:05 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 24, 2021 at 11:10:41PM -0400, Neal Gompa wrote:
On the topic of FPCA improvements, it would probably make sense (if the FPCA is retained) to replace the MIT license as the default code license with MIT No Attribution, aka MIT-0, recently approved by the OSI as an open source license: https://opensource.org/licenses/MIT-0 (which would also enable a minor simplification of the FPCA text).
I would personally prefer we didn't. That has the knock-on effect of making it possible for RHEL folks to not include Fedora changelogs when they fork Fedora for RHEL, since the RPM changelogs are the only attribution we actually *have* in the distribution. And I've personally experienced very positive reinforcement for contributing to Fedora and CentOS Stream by pointing to public attribution via changelogs.
I agree with Neal here as a deep gut reaction. Recognition is important, even if it is buried pretty deeply from endusers.
That said, uh, we trim changelogs, so if we're arguing that that's the attribution part, we have some digging through git history to do to repair that.
Red Hat is going to have to fix *a lot* of the process around Fedora->RHEL/CentOS if we're going to rely on Git history for attribution. Especially if rpmautospec gets broader adoption. I was personally pretty upset about how the c9s branches were forked from Fedora Linux 34, where all the Fedora history was *gone*. I know that it's still there in the internal RHEL Dist-Git, but the fact they
You don't know that, and it's actually not there.
This is what the import commits look like:
commit eb6f429d3f0c2f41aa5bb7f8e5153668aa812553 Author: XXXX XXXXXX XXXXXX@redhat.com Date: Fri Oct 23 08:45:59 2020 -0700
RHEL 9.0.0 bootstrap
The content of this branch was automatically imported from Fedora ELN with the following as its source: https://src.fedoraproject.org/rpms/glibc#90ca20fd0234925743db5e1e231b73b4a38...
then later
commit df9ce2ff57e675edea493144401a1e1c9ed0f2b5 Author: DistroBaker xxxxxxxx@redhat.com Date: Tue Dec 15 10:59:21 2020 +0000
Merged update from upstream sources
This is an automated DistroBaker update from upstream sources. If you do not know what this is about or would like to opt out, contact the XXXX team.
Source: https://src.fedoraproject.org/rpms/glibc.git#525dee4c87180db08e1776a d3cb0e66a9b38e81f
Please don't fall into the trap of believing your assumptions are reality :)
josh
On Thu, Aug 26, 2021 at 7:38 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Aug 25, 2021 at 7:51 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Aug 25, 2021 at 7:05 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 24, 2021 at 11:10:41PM -0400, Neal Gompa wrote:
On the topic of FPCA improvements, it would probably make sense (if the FPCA is retained) to replace the MIT license as the default code license with MIT No Attribution, aka MIT-0, recently approved by the OSI as an open source license: https://opensource.org/licenses/MIT-0 (which would also enable a minor simplification of the FPCA text).
I would personally prefer we didn't. That has the knock-on effect of making it possible for RHEL folks to not include Fedora changelogs when they fork Fedora for RHEL, since the RPM changelogs are the only attribution we actually *have* in the distribution. And I've personally experienced very positive reinforcement for contributing to Fedora and CentOS Stream by pointing to public attribution via changelogs.
I agree with Neal here as a deep gut reaction. Recognition is important, even if it is buried pretty deeply from endusers.
That said, uh, we trim changelogs, so if we're arguing that that's the attribution part, we have some digging through git history to do to repair that.
Red Hat is going to have to fix *a lot* of the process around Fedora->RHEL/CentOS if we're going to rely on Git history for attribution. Especially if rpmautospec gets broader adoption. I was personally pretty upset about how the c9s branches were forked from Fedora Linux 34, where all the Fedora history was *gone*. I know that it's still there in the internal RHEL Dist-Git, but the fact they
You don't know that, and it's actually not there.
This is what the import commits look like:
commit eb6f429d3f0c2f41aa5bb7f8e5153668aa812553 Author: XXXX XXXXXX XXXXXX@redhat.com Date: Fri Oct 23 08:45:59 2020 -0700
RHEL 9.0.0 bootstrap The content of this branch was automatically imported from Fedora ELN with the following as its source: https://src.fedoraproject.org/rpms/glibc#90ca20fd0234925743db5e1e231b73b4a38749a9then later
commit df9ce2ff57e675edea493144401a1e1c9ed0f2b5 Author: DistroBaker xxxxxxxx@redhat.com Date: Tue Dec 15 10:59:21 2020 +0000
Merged update from upstream sources This is an automated DistroBaker update from upstream sources. If you do not know what this is about or would like to opt out, contact the XXXX team. Source: https://src.fedoraproject.org/rpms/glibc.git#525dee4c87180db08e1776ad3cb0e66a9b38e81f
Please don't fall into the trap of believing your assumptions are reality :)
That is insufficient. And when rpmautospec based packages start coming to RHEL, it'll be *definitely* insufficient because none of that will make it into the generated spec file and built packages.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Thu, Aug 26, 2021 at 8:45 AM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Aug 26, 2021 at 7:38 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Aug 25, 2021 at 7:51 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Aug 25, 2021 at 7:05 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 24, 2021 at 11:10:41PM -0400, Neal Gompa wrote:
On the topic of FPCA improvements, it would probably make sense (if the FPCA is retained) to replace the MIT license as the default code license with MIT No Attribution, aka MIT-0, recently approved by the OSI as an open source license: https://opensource.org/licenses/MIT-0 (which would also enable a minor simplification of the FPCA text).
I would personally prefer we didn't. That has the knock-on effect of making it possible for RHEL folks to not include Fedora changelogs when they fork Fedora for RHEL, since the RPM changelogs are the only attribution we actually *have* in the distribution. And I've personally experienced very positive reinforcement for contributing to Fedora and CentOS Stream by pointing to public attribution via changelogs.
I agree with Neal here as a deep gut reaction. Recognition is important, even if it is buried pretty deeply from endusers.
That said, uh, we trim changelogs, so if we're arguing that that's the attribution part, we have some digging through git history to do to repair that.
Red Hat is going to have to fix *a lot* of the process around Fedora->RHEL/CentOS if we're going to rely on Git history for attribution. Especially if rpmautospec gets broader adoption. I was personally pretty upset about how the c9s branches were forked from Fedora Linux 34, where all the Fedora history was *gone*. I know that it's still there in the internal RHEL Dist-Git, but the fact they
You don't know that, and it's actually not there.
This is what the import commits look like:
commit eb6f429d3f0c2f41aa5bb7f8e5153668aa812553 Author: XXXX XXXXXX XXXXXX@redhat.com Date: Fri Oct 23 08:45:59 2020 -0700
RHEL 9.0.0 bootstrap The content of this branch was automatically imported from Fedora ELN with the following as its source: https://src.fedoraproject.org/rpms/glibc#90ca20fd0234925743db5e1e231b73b4a38749a9then later
commit df9ce2ff57e675edea493144401a1e1c9ed0f2b5 Author: DistroBaker xxxxxxxx@redhat.com Date: Tue Dec 15 10:59:21 2020 +0000
Merged update from upstream sources This is an automated DistroBaker update from upstream sources. If you do not know what this is about or would like to opt out, contact the XXXX team. Source: https://src.fedoraproject.org/rpms/glibc.git#525dee4c87180db08e1776ad3cb0e66a9b38e81f
Please don't fall into the trap of believing your assumptions are reality :)
That is insufficient. And when rpmautospec based packages start coming to RHEL, it'll be *definitely* insufficient because none of that will make it into the generated spec file and built packages.
That's 3 years down the road. Perhaps things can be improved between now and then. Fortunately, work done against RHEL now via CentOS Stream will have attribution in the MRs, etc.
josh
On Thu, Aug 26, 2021 at 9:01 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Aug 26, 2021 at 8:45 AM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Aug 26, 2021 at 7:38 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Aug 25, 2021 at 7:51 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Aug 25, 2021 at 7:05 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 24, 2021 at 11:10:41PM -0400, Neal Gompa wrote:
> On the topic of FPCA improvements, it would probably make sense (if > the FPCA is retained) to replace the MIT license as the default code > license with MIT No Attribution, aka MIT-0, recently approved by the > OSI as an open source license: > https://opensource.org/licenses/MIT-0 > (which would also enable a minor simplification of the FPCA text). >
I would personally prefer we didn't. That has the knock-on effect of making it possible for RHEL folks to not include Fedora changelogs when they fork Fedora for RHEL, since the RPM changelogs are the only attribution we actually *have* in the distribution. And I've personally experienced very positive reinforcement for contributing to Fedora and CentOS Stream by pointing to public attribution via changelogs.
I agree with Neal here as a deep gut reaction. Recognition is important, even if it is buried pretty deeply from endusers.
That said, uh, we trim changelogs, so if we're arguing that that's the attribution part, we have some digging through git history to do to repair that.
Red Hat is going to have to fix *a lot* of the process around Fedora->RHEL/CentOS if we're going to rely on Git history for attribution. Especially if rpmautospec gets broader adoption. I was personally pretty upset about how the c9s branches were forked from Fedora Linux 34, where all the Fedora history was *gone*. I know that it's still there in the internal RHEL Dist-Git, but the fact they
You don't know that, and it's actually not there.
This is what the import commits look like:
commit eb6f429d3f0c2f41aa5bb7f8e5153668aa812553 Author: XXXX XXXXXX XXXXXX@redhat.com Date: Fri Oct 23 08:45:59 2020 -0700
RHEL 9.0.0 bootstrap The content of this branch was automatically imported from Fedora ELN with the following as its source: https://src.fedoraproject.org/rpms/glibc#90ca20fd0234925743db5e1e231b73b4a38749a9then later
commit df9ce2ff57e675edea493144401a1e1c9ed0f2b5 Author: DistroBaker xxxxxxxx@redhat.com Date: Tue Dec 15 10:59:21 2020 +0000
Merged update from upstream sources This is an automated DistroBaker update from upstream sources. If you do not know what this is about or would like to opt out, contact the XXXX team. Source: https://src.fedoraproject.org/rpms/glibc.git#525dee4c87180db08e1776ad3cb0e66a9b38e81f
Please don't fall into the trap of believing your assumptions are reality :)
That is insufficient. And when rpmautospec based packages start coming to RHEL, it'll be *definitely* insufficient because none of that will make it into the generated spec file and built packages.
That's 3 years down the road. Perhaps things can be improved between now and then. Fortunately, work done against RHEL now via CentOS Stream will have attribution in the MRs, etc.
As long as you don't import any *new* packages during the EL9 lifecycle where this problem occurs, yes, it's 3 years down the road.
On Thu, Aug 26, 2021 at 9:13 AM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Aug 26, 2021 at 9:01 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Aug 26, 2021 at 8:45 AM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Aug 26, 2021 at 7:38 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Aug 25, 2021 at 7:51 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Aug 25, 2021 at 7:05 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 24, 2021 at 11:10:41PM -0400, Neal Gompa wrote: > > On the topic of FPCA improvements, it would probably make sense (if > > the FPCA is retained) to replace the MIT license as the default code > > license with MIT No Attribution, aka MIT-0, recently approved by the > > OSI as an open source license: > > https://opensource.org/licenses/MIT-0 > > (which would also enable a minor simplification of the FPCA text). > > > > I would personally prefer we didn't. That has the knock-on effect of > making it possible for RHEL folks to not include Fedora changelogs > when they fork Fedora for RHEL, since the RPM changelogs are the only > attribution we actually *have* in the distribution. And I've > personally experienced very positive reinforcement for contributing to > Fedora and CentOS Stream by pointing to public attribution via changelogs.
I agree with Neal here as a deep gut reaction. Recognition is important, even if it is buried pretty deeply from endusers.
That said, uh, we trim changelogs, so if we're arguing that that's the attribution part, we have some digging through git history to do to repair that.
Red Hat is going to have to fix *a lot* of the process around Fedora->RHEL/CentOS if we're going to rely on Git history for attribution. Especially if rpmautospec gets broader adoption. I was personally pretty upset about how the c9s branches were forked from Fedora Linux 34, where all the Fedora history was *gone*. I know that it's still there in the internal RHEL Dist-Git, but the fact they
You don't know that, and it's actually not there.
This is what the import commits look like:
commit eb6f429d3f0c2f41aa5bb7f8e5153668aa812553 Author: XXXX XXXXXX XXXXXX@redhat.com Date: Fri Oct 23 08:45:59 2020 -0700
RHEL 9.0.0 bootstrap The content of this branch was automatically imported from Fedora ELN with the following as its source: https://src.fedoraproject.org/rpms/glibc#90ca20fd0234925743db5e1e231b73b4a38749a9then later
commit df9ce2ff57e675edea493144401a1e1c9ed0f2b5 Author: DistroBaker xxxxxxxx@redhat.com Date: Tue Dec 15 10:59:21 2020 +0000
Merged update from upstream sources This is an automated DistroBaker update from upstream sources. If you do not know what this is about or would like to opt out, contact the XXXX team. Source: https://src.fedoraproject.org/rpms/glibc.git#525dee4c87180db08e1776ad3cb0e66a9b38e81f
Please don't fall into the trap of believing your assumptions are reality :)
That is insufficient. And when rpmautospec based packages start coming to RHEL, it'll be *definitely* insufficient because none of that will make it into the generated spec file and built packages.
That's 3 years down the road. Perhaps things can be improved between now and then. Fortunately, work done against RHEL now via CentOS Stream will have attribution in the MRs, etc.
As long as you don't import any *new* packages during the EL9 lifecycle where this problem occurs, yes, it's 3 years down the road.
We're on a wild tangent now, but there are valid reasons we do not have the entire Fedora git history in an internal git instance despite many people expecting it. I doubt those are going to change during the life of RHEL 9. Also, I'm not concerned about rpmautospec Fedora packages. New imports into EL9 would import an SRPM, not from Fedora git. This is really a 3 year down the road thing.
I can certainly understand and agree with the sentiment here, but I think we need to figure out a better way to show attribution in general. RPM changelogs are extremely arcane, and disjoint package git repos aren't really cutting it either.
josh
On Tue, Aug 24, 2021 at 10:02:39PM -0400, Richard Fontana wrote:
Indeed, this should have been caught when the FPCA was updated to reference CC BY-SA 4.0 as the default content license. The relevant perceived problematic feature of CC BY-SA 3.0 Unported was fixed in CC BY-SA 4.0.
That sounds like a clerical update rather than actually any policy change, so presumably we can just make the edit without sending out new announcements, etc?
I don't know if it is better to fix this error or to instead look into eliminating the FPCA requirement. The FPCA is now basically outdated and has the detriment of being pointed to by certain CLA advocates as proof that "Red Hat supports CLAs".
I think we should make the change. I agree about this detriment -- GitLab, for example, erroneously called us out in their press release about adout this, and when Neal attempted to correct them, first argued
"While FPCA may not be a typical CLA with regard to rights and restrictions, this is not the only factor we looked into. We also were looking into whether there were terms in general, other than commonly used open source terms. Our analysis took into account that non-legal users do not always understand the nuances of legal language and can be deterred by any CLA, restrictive or not, if they do not understand the terms."
... before they eventually changed it. I know that some folks in the CentOS project had this notion about Fedora requiring a CLA as well. At some point, the downsides of perception outweigh any real benefits.
BUT THAT SAID: we have a lot of stuff in the project wired to the assumption that the FPCA was agreed to. (And as another awful aside, we still call that flag "CLA" pretty much everywhere.) Like, for example, voting. So all of that would need to be addressed, making this at least A Project.
On Wed, Aug 25, 2021 at 7:11 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 24, 2021 at 10:02:39PM -0400, Richard Fontana wrote:
Indeed, this should have been caught when the FPCA was updated to reference CC BY-SA 4.0 as the default content license. The relevant perceived problematic feature of CC BY-SA 3.0 Unported was fixed in CC BY-SA 4.0.
That sounds like a clerical update rather than actually any policy change, so presumably we can just make the edit without sending out new announcements, etc?
I don't know if it is better to fix this error or to instead look into eliminating the FPCA requirement. The FPCA is now basically outdated and has the detriment of being pointed to by certain CLA advocates as proof that "Red Hat supports CLAs".
I think we should make the change. I agree about this detriment -- GitLab, for example, erroneously called us out in their press release about adout this, and when Neal attempted to correct them, first argued
"While FPCA may not be a typical CLA with regard to rights and restrictions, this is not the only factor we looked into. We also were looking into whether there were terms in general, other than commonly used open source terms. Our analysis took into account that non-legal users do not always understand the nuances of legal language and can be deterred by any CLA, restrictive or not, if they do not understand the terms."
... before they eventually changed it. I know that some folks in the CentOS project had this notion about Fedora requiring a CLA as well. At some point, the downsides of perception outweigh any real benefits.
BUT THAT SAID: we have a lot of stuff in the project wired to the assumption that the FPCA was agreed to. (And as another awful aside, we still call that flag "CLA" pretty much everywhere.) Like, for example, voting. So all of that would need to be addressed, making this at least A Project.
For what it's worth, Red Hat *did* have a project that used a traditional CLA for a long time: eCos. Today, it uses a CAA to assign copyright to the FSF: https://ecos.sourceware.org/contrib.html
Cygwin also had a messy contribution process for a while as a result of the acquisition of Cygnus (yeah, I'm going that far back!). The website still references it, but I think it's out of date: https://cygwin.com/contrib.html
I wish we had promoted the FPCA as a general alternative framework to traditional CLAs promoted by proprietary-in-OSS/open-core companies. It's not like these agreements are valueless. Indeed, the FPCA shares more in common with the DCO than what most people consider CLAs and both are effectively contributor agreements.
And again, getting rid of it means we have to make some very significant process changes for accepting contributions. I'm not sure we really want to do that. For example, we're going to need some kind of agreement when accepting new packages into the project. We're also going to need to figure out how to make licensing a part of package specs and other content we typically don't directly note because we currently rely on the FPCA for that.
It's going to be *really* messy to switch to an agreement-less system.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Wed, Aug 25, 2021 at 08:31:37PM -0400, Neal Gompa wrote:
For what it's worth, Red Hat *did* have a project that used a traditional CLA for a long time: eCos. Today, it uses a CAA to assign
And Fedora, for quite a while really -- I don't remember the exact date, but this suggests F15. https://pagure.io/fedora-infrastructure/issue/2481
On Wed, Aug 25, 2021 at 8:35 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Aug 25, 2021 at 08:31:37PM -0400, Neal Gompa wrote:
For what it's worth, Red Hat *did* have a project that used a traditional CLA for a long time: eCos. Today, it uses a CAA to assign
And Fedora, for quite a while really -- I don't remember the exact date, but this suggests F15. https://pagure.io/fedora-infrastructure/issue/2481
Yup, I remember this change. :)
One thing I'm sad about with the new system is that the record of exactly how old my account is and all the "cruft" around that is gone. No more proof that I was around during that time will exist in the system. :P
On Wed, Aug 25, 2021 at 08:42:13PM -0400, Neal Gompa wrote:
One thing I'm sad about with the new system is that the record of exactly how old my account is and all the "cruft" around that is gone. No more proof that I was around during that time will exist in the system. :P
Off-topic, but: not so! This is still there in the IPA backend and available in the API even though it's not exposed in the UI right now. I can see it. :)
On Wed, Aug 25, 2021 at 7:03 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Aug 24, 2021 at 10:02:39PM -0400, Richard Fontana wrote:
Indeed, this should have been caught when the FPCA was updated to reference CC BY-SA 4.0 as the default content license. The relevant perceived problematic feature of CC BY-SA 3.0 Unported was fixed in CC BY-SA 4.0.
That sounds like a clerical update rather than actually any policy change, so presumably we can just make the edit without sending out new announcements, etc?
Makes sense to me, but that's probably a question for the Fedora Council. :-)
Richard
On Thu, Aug 26, 2021 at 03:40:42PM -0400, Richard Fontana wrote:
That sounds like a clerical update rather than actually any policy change, so presumably we can just make the edit without sending out new announcements, etc?
Makes sense to me, but that's probably a question for the Fedora Council. :-)
Fair, so let me return a question to you. :) The change to be made would be:
1. Remove the clause "supplemented by Moral Rights Clause Waiver and GPL Relicensing Permission" where that appears, and
2. the whole paragraph defining "Moral Rights Clause Waiver", and
3. replace "Creative Commons Attribution ShareAlike 3.0 Unported" in the FAQ with "Creative Commons Attribution-ShareAlike 4.0" where it appears, and
4. entirely remove the question in the FAQ referring to that clause.
Is there anything we need to do to note that for content to which the old default license applies, the 4d waiver was waived? Or can that just be a matter for the archives in the unlikely event it ever comes up?
On Thu, Aug 26, 2021 at 9:35 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Aug 26, 2021 at 03:40:42PM -0400, Richard Fontana wrote:
That sounds like a clerical update rather than actually any policy change, so presumably we can just make the edit without sending out new announcements, etc?
Makes sense to me, but that's probably a question for the Fedora Council. :-)
Fair, so let me return a question to you. :) The change to be made would be:
Remove the clause "supplemented by Moral Rights Clause Waiver and GPL Relicensing Permission" where that appears, and
the whole paragraph defining "Moral Rights Clause Waiver", and
replace "Creative Commons Attribution ShareAlike 3.0 Unported" in the FAQ with "Creative Commons Attribution-ShareAlike 4.0" where it appears, and
entirely remove the question in the FAQ referring to that clause.
Yes, but the "GPL Relicensing Permission" part was there for unrelated reasons. I would remove that since (a) Creative Commons has declared CC BY-SA 4.0 as one-way compatible with GPLv3, even though the "Permission" in the FPCA covers a larger range of licenses, and (b) this probably added more complexity than actual benefit. I doubt a single question about reuse of CC BY-SA "content" in a GPL-licensed work has come up in the years since the introduction of the FPCA. If it were to come up, it could be dealt with on a case by case basis.
Is there anything we need to do to note that for content to which the old default license applies, the 4d waiver was waived? Or can that just be a matter for the archives in the unlikely event it ever comes up?
I would leave it to the archives. It was a highly obscure point when it was introduced and was essentially embedding a criticism of a flaw in the 3.0 series of CC licenses into the FPCA, perhaps unjustifiably.
Richard
-
Jason Yundt -
Josh Boyer -
Kevin Fenzi -
Matthew Miller -
Neal Gompa -
Richard Fontana