Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following:
1) how do you (package maintainers) interpret this policy in practice?
2) what further information/documentation about this policy would be helpful?
3) should this policy be different, and if so, how?
4) any other related thoughts or observations
Thanks! Jilayne
On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following:
how do you (package maintainers) interpret this policy in practice?
what further information/documentation about this policy would be helpful?
should this policy be different, and if so, how?
any other related thoughts or observations
I generally interpret it to mean the effective license that covers the resulting artifacts shipped in the binary RPM. I think this is fine, but we definitely have a gap in RPM packaging in that we can't declare the license of the Source RPM anywhere. This is particularly kludgy when you have vendored or bundled code.
To be honest, I don't particularly relish redoing the licensing of some things with SPDX identifiers because it's going to triple the length of the license string there. Too much specificity can hurt...
I don't have specific solutions here, but I would like to avoid having the list licenses for literally everything in a source tree when it doesn't matter for binary RPMs.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 5/23/22 10:44 AM, Neal Gompa wrote:
On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following:
how do you (package maintainers) interpret this policy in practice?
what further information/documentation about this policy would be helpful?
should this policy be different, and if so, how?
any other related thoughts or observations
I generally interpret it to mean the effective license that covers the resulting artifacts shipped in the binary RPM. I think this is fine, but we definitely have a gap in RPM packaging in that we can't declare the license of the Source RPM anywhere.
Are you saying we should have a way to declare both 1) the license that covers the resulting artifacts shipped in the binary RPM and 2) the license of the source (that creates said binary)?
This is particularly kludgy when you have vendored or bundled code.
I don't have specific solutions here, but I would like to avoid having the list licenses for literally everything in a source tree when it doesn't matter for binary RPMs.
isn't having to list license for everything in the source the same as 2??
Jilayne
-- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, May 23, 2022 at 1:03 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 5/23/22 10:44 AM, Neal Gompa wrote:
On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following:
how do you (package maintainers) interpret this policy in practice?
what further information/documentation about this policy would be helpful?
should this policy be different, and if so, how?
any other related thoughts or observations
I generally interpret it to mean the effective license that covers the resulting artifacts shipped in the binary RPM. I think this is fine, but we definitely have a gap in RPM packaging in that we can't declare the license of the Source RPM anywhere.
Are you saying we should have a way to declare both 1) the license that covers the resulting artifacts shipped in the binary RPM and 2) the license of the source (that creates said binary)?
This is particularly kludgy when you have vendored or bundled code.
I don't have specific solutions here, but I would like to avoid having the list licenses for literally everything in a source tree when it doesn't matter for binary RPMs.
isn't having to list license for everything in the source the same as 2??
We are required to document source licensing for bundled stuff, which contravenes the "effective binary licensing" policy we have in general. If we didn't have that, we could avoid this whole problem.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, May 23, 2022 at 2:03 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, May 23, 2022 at 1:03 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 5/23/22 10:44 AM, Neal Gompa wrote:
On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following:
how do you (package maintainers) interpret this policy in practice?
what further information/documentation about this policy would be helpful?
should this policy be different, and if so, how?
any other related thoughts or observations
I generally interpret it to mean the effective license that covers the resulting artifacts shipped in the binary RPM. I think this is fine, but we definitely have a gap in RPM packaging in that we can't declare the license of the Source RPM anywhere.
Are you saying we should have a way to declare both 1) the license that covers the resulting artifacts shipped in the binary RPM and 2) the license of the source (that creates said binary)?
This is particularly kludgy when you have vendored or bundled code.
I don't have specific solutions here, but I would like to avoid having the list licenses for literally everything in a source tree when it doesn't matter for binary RPMs.
isn't having to list license for everything in the source the same as 2??
We are required to document source licensing for bundled stuff, which contravenes the "effective binary licensing" policy we have in general. If we didn't have that, we could avoid this whole problem.
Do you mean bundled stuff that is distributed with the binary RPM (whether in the same form or somehow transformed), or bundled stuff that happens to be in the source tarball or whatever but is ignored in building the binary RPM?
If it's the latter then that does seem to contradict the "license of the binary" policy.
Richard
On 5/23/22 1:30 PM, Richard Fontana wrote:
On Mon, May 23, 2022 at 2:03 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, May 23, 2022 at 1:03 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 5/23/22 10:44 AM, Neal Gompa wrote:
On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following:
how do you (package maintainers) interpret this policy in practice?
what further information/documentation about this policy would be helpful?
should this policy be different, and if so, how?
any other related thoughts or observations
I generally interpret it to mean the effective license that covers the resulting artifacts shipped in the binary RPM. I think this is fine, but we definitely have a gap in RPM packaging in that we can't declare the license of the Source RPM anywhere.
Are you saying we should have a way to declare both 1) the license that covers the resulting artifacts shipped in the binary RPM and 2) the license of the source (that creates said binary)?
This is particularly kludgy when you have vendored or bundled code.
I don't have specific solutions here, but I would like to avoid having the list licenses for literally everything in a source tree when it doesn't matter for binary RPMs.
isn't having to list license for everything in the source the same as 2??
We are required to document source licensing for bundled stuff, which contravenes the "effective binary licensing" policy we have in general. If we didn't have that, we could avoid this whole problem.
Do you mean bundled stuff that is distributed with the binary RPM (whether in the same form or somehow transformed), or bundled stuff that happens to be in the source tarball or whatever but is ignored in building the binary RPM?
If it's the latter then that does seem to contradict the "license of the binary" policy.
Richard
I'm also wondering where the "required to document source licensing for bundled stuff" is documented? Can you point to that?
J.
On Mon, May 23, 2022 at 3:53 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 5/23/22 1:30 PM, Richard Fontana wrote:
On Mon, May 23, 2022 at 2:03 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, May 23, 2022 at 1:03 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 5/23/22 10:44 AM, Neal Gompa wrote:
On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following:
how do you (package maintainers) interpret this policy in practice?
what further information/documentation about this policy would be helpful?
should this policy be different, and if so, how?
any other related thoughts or observations
I generally interpret it to mean the effective license that covers the resulting artifacts shipped in the binary RPM. I think this is fine, but we definitely have a gap in RPM packaging in that we can't declare the license of the Source RPM anywhere.
Are you saying we should have a way to declare both 1) the license that covers the resulting artifacts shipped in the binary RPM and 2) the license of the source (that creates said binary)?
This is particularly kludgy when you have vendored or bundled code.
I don't have specific solutions here, but I would like to avoid having the list licenses for literally everything in a source tree when it doesn't matter for binary RPMs.
isn't having to list license for everything in the source the same as 2??
We are required to document source licensing for bundled stuff, which contravenes the "effective binary licensing" policy we have in general. If we didn't have that, we could avoid this whole problem.
Do you mean bundled stuff that is distributed with the binary RPM (whether in the same form or somehow transformed), or bundled stuff that happens to be in the source tarball or whatever but is ignored in building the binary RPM?
If it's the latter then that does seem to contradict the "license of the binary" policy.
Richard
I'm also wondering where the "required to document source licensing for bundled stuff" is documented? Can you point to that?
It was something we were told to do years ago for Rust/Go stuff. I'm not sure I can find a specific reference for it. I have mentioned it before though[1].
[1]: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/...
On Mon, May 23, 2022 at 3:58 PM Neal Gompa ngompa13@gmail.com wrote:
I'm also wondering where the "required to document source licensing for bundled stuff" is documented? Can you point to that?
It was something we were told to do years ago for Rust/Go stuff. I'm not sure I can find a specific reference for it. I have mentioned it before though[1].
Leaving aside the specifics of the bundling/Rust cases, one of the questions here is whether we want to have License: fields that state something relatively complex like
License: ASL 2.0 and (ASL 2.0 or Boost) and (ASL 2.0 or MIT) and ISC and MIT and ((MIT or ASL 2.0) and BSD) and (Unlicense or MIT) or its equivalent in SPDX which if anything might seem slightly more complex depending on the details.
The assumption I've been making is that we basically can't avoid having complex license expressions in the general case, and that is (for me) a major justification for switching from Callaway to SPDX, since SPDX is a somewhat richer and more coherent expression language for complex licensing details.
But if people think we should find ways of making license expressions simpler, that doesn't mean not using SPDX or something that seems syntactically/symbolically identical to SPDX for the representation of the resulting simplified expressions.
I think this also goes to how "licenses of the contents of the binary RPM" is ambiguous. It might mean, for example: * Every identifiable license in a source file that is included (in compiled form or otherwise) in the binary RPM -- I think we see some packages that attempt this * A simplified representation of those licenses based on application of common / seemingly noncontroversial FOSS (often GPL-community-specific) folkloric legal conventions. Two examples: 1) an executable program built from GPLv2+ and MIT licensed source files gets represented simply as "GPLv2+" (GPL-2.0-or-later in SPDX) 2) an executable program built from GPLv2+ source files but which dynamically links against a GPLv3+ separately-packaged library (also distributed in Fedora) gets represented as "GPLv3+" I think there are many examples of 1) and I know of one example of 2), but I think neither of those kinds of cases are handled consistently across Fedora packages today (not saying that we need absolute consistency)
Are simpler or more complex license expressions preferable, even if simpler expressions mean some loss of useful information or accuracy? That's one issue that is connected to Jilayne's question.
Richard
* something else?
On Mon, May 23, 2022 at 4:29 PM Richard Fontana rfontana@redhat.com wrote:
On Mon, May 23, 2022 at 3:58 PM Neal Gompa ngompa13@gmail.com wrote:
I'm also wondering where the "required to document source licensing for bundled stuff" is documented? Can you point to that?
It was something we were told to do years ago for Rust/Go stuff. I'm not sure I can find a specific reference for it. I have mentioned it before though[1].
Leaving aside the specifics of the bundling/Rust cases, one of the questions here is whether we want to have License: fields that state something relatively complex like
License: ASL 2.0 and (ASL 2.0 or Boost) and (ASL 2.0 or MIT) and ISC and MIT and ((MIT or ASL 2.0) and BSD) and (Unlicense or MIT) or its equivalent in SPDX which if anything might seem slightly more complex depending on the details.
The assumption I've been making is that we basically can't avoid having complex license expressions in the general case, and that is (for me) a major justification for switching from Callaway to SPDX, since SPDX is a somewhat richer and more coherent expression language for complex licensing details.
That might be the case in the container circus, but in the RPM world, we mostly get to avoid complex licensing details.
The weirdest license expression is the one for perl-Exporter-Tidy[1], which requires us to evaluate the entire list of acceptable licenses and export them to the License tag since the license terms state as such[2]. Outside of that, only crazy packages like Chromium wind up having complex licensing. The rest are reasonably simple.
[1]: https://src.fedoraproject.org/rpms/perl-Exporter-Tidy [2]: https://metacpan.org/pod/Exporter::Tidy#LICENSE
But if people think we should find ways of making license expressions simpler, that doesn't mean not using SPDX or something that seems syntactically/symbolically identical to SPDX for the representation of the resulting simplified expressions.
I think this also goes to how "licenses of the contents of the binary RPM" is ambiguous. It might mean, for example:
- Every identifiable license in a source file that is included (in
compiled form or otherwise) in the binary RPM -- I think we see some packages that attempt this
- A simplified representation of those licenses based on application
of common / seemingly noncontroversial FOSS (often GPL-community-specific) folkloric legal conventions. Two examples:
- an executable program built from GPLv2+ and MIT licensed source
files gets represented simply as "GPLv2+" (GPL-2.0-or-later in SPDX) 2) an executable program built from GPLv2+ source files but which dynamically links against a GPLv3+ separately-packaged library (also distributed in Fedora) gets represented as "GPLv3+" I think there are many examples of 1) and I know of one example of 2), but I think neither of those kinds of cases are handled consistently across Fedora packages today (not saying that we need absolute consistency)
Are simpler or more complex license expressions preferable, even if simpler expressions mean some loss of useful information or accuracy? That's one issue that is connected to Jilayne's question.
The point of the License tag in Fedora is to provide good guidance on leveraging the software. If you want total accuracy, then you need per-file license metadata. That's even *more* prone to errors, and isn't even useful in most cases. I would prefer simpler, understandable expressions than crazy accurate ones. For example, if we changed to per-file accuracy, we'd need to start documenting all the autotools bundled licensing, which we've never done.
On Mon, May 23, 2022 at 5:17 PM Neal Gompa ngompa13@gmail.com wrote:
The weirdest license expression is the one for perl-Exporter-Tidy[1], which requires us to evaluate the entire list of acceptable licenses and export them to the License tag since the license terms state as such[2]. Outside of that, only crazy packages like Chromium wind up having complex licensing. The rest are reasonably simple.
I think for that one it would be better to treat the contents of that LICENSE file as a unique license (that happens to incorporate some set of OSI-approved licenses that may vary at any given point in time).
The point of the License tag in Fedora is to provide good guidance on leveraging the software. If you want total accuracy, then you need per-file license metadata. That's even *more* prone to errors, and isn't even useful in most cases. I would prefer simpler, understandable expressions than crazy accurate ones. For example, if we changed to per-file accuracy, we'd need to start documenting all the autotools bundled licensing, which we've never done.
Well, I assume that "license of the binary" is designed in part to easily exclude autotools.
You could have per-source-file accuracy but only for files that are "in" the binary, if you will. But then you have the overhead of figuring out what is "in" the binary.
If you give up on per-source-file accuracy, this seems to imply the overhead of making a legal or quasi-legal (e.g. what I call 'folkloric') conclusion.
Maybe instead of that we can come up with simple rules with the understanding that the (generally very simple) result is sometimes going to be fairly inaccurate.
I don't know which of these options is better. There are probably various other ones.
Richard
great discussion, Neal and Richard!
Just a ping that it'd be great to hear from others in the Fedora community on this topic (see questions in original posts)
Thanks!!
On 5/24/22 8:46 AM, Richard Fontana wrote:
On Mon, May 23, 2022 at 5:17 PM Neal Gompangompa13@gmail.com wrote:
The weirdest license expression is the one for perl-Exporter-Tidy[1], which requires us to evaluate the entire list of acceptable licenses and export them to the License tag since the license terms state as such[2]. Outside of that, only crazy packages like Chromium wind up having complex licensing. The rest are reasonably simple.
I think for that one it would be better to treat the contents of that LICENSE file as a unique license (that happens to incorporate some set of OSI-approved licenses that may vary at any given point in time).
The point of the License tag in Fedora is to provide good guidance on leveraging the software. If you want total accuracy, then you need per-file license metadata. That's even *more* prone to errors, and isn't even useful in most cases. I would prefer simpler, understandable expressions than crazy accurate ones. For example, if we changed to per-file accuracy, we'd need to start documenting all the autotools bundled licensing, which we've never done.
Well, I assume that "license of the binary" is designed in part to easily exclude autotools.
You could have per-source-file accuracy but only for files that are "in" the binary, if you will. But then you have the overhead of figuring out what is "in" the binary.
If you give up on per-source-file accuracy, this seems to imply the overhead of making a legal or quasi-legal (e.g. what I call 'folkloric') conclusion.
Maybe instead of that we can come up with simple rules with the understanding that the (generally very simple) result is sometimes going to be fairly inaccurate.
I don't know which of these options is better. There are probably various other ones.
Richard
Following up on this thread: A few of us in Red Hat discussed this issue and settled on the idea that we should preserve the "licenses of the contents of the binary rpm" policy, rather than the most obvious alternative which would be "list the licenses found in the source tarball". A major justification for that is that there isn't much point in having the License: field merely replicate what you could get by using a source code license scanner with some minimal analysis.
However, it seems clear that "licenses of the contents of the binary rpm" is ambiguous and this partly explains why today Fedora packagers seem to be applying non-uniform standards to figuring out what to include in the License: field. There also may continue to be cases where different licensing of binary subpackages makes a difference to some package consumers.
We considered a few different options and we concluded that the best approach is for the License: field to consist of a simple enumeration of the licenses (including, possibly, disjunctive license expressions) covering anything that ends up in a given binary RPM (whether compiled to binary code or otherwise). The Fedora package maintainer is in the best position to figure out what this subset of material in the source code is, and how it appears to be licensed.
Importantly, this "simply enumerate" approach means not attempting to do any sort of further analysis such as GPL derivative works analysis, algebraic simplifications or resolutions of long strings of conjunctive license expressions based on longstanding community conventions around FOSS licensing, etc.
As before, any comments on this are most welcome!
Richard
On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following:
how do you (package maintainers) interpret this policy in practice?
what further information/documentation about this policy would be helpful?
should this policy be different, and if so, how?
any other related thoughts or observations
Thanks! Jilayne _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Dne 06. 06. 22 v 21:33 Richard Fontana napsal(a):
Following up on this thread: A few of us in Red Hat discussed this issue and settled on the idea that we should preserve the "licenses of the contents of the binary rpm" policy, rather than the most obvious alternative which would be "list the licenses found in the source tarball". A major justification for that is that there isn't much point in having the License: field merely replicate what you could get by using a source code license scanner with some minimal analysis.
Please note that source licenses does not map to binary RPMs 1:1. It is well possible the source tarball contains multiple licenses while some subpackage content is licensed by only subset of the licenses. E.g. you might have source tarball containing MIT code and CC0 data. Then you have -data subpackage which contains just the data, therefore the license for that subpackage should be just CC0.
Of course the guidelines could suggest against using specific License field for subpackages. Dunno if that would help anything.
Vít
However, it seems clear that "licenses of the contents of the binary rpm" is ambiguous and this partly explains why today Fedora packagers seem to be applying non-uniform standards to figuring out what to include in the License: field. There also may continue to be cases where different licensing of binary subpackages makes a difference to some package consumers.
We considered a few different options and we concluded that the best approach is for the License: field to consist of a simple enumeration of the licenses (including, possibly, disjunctive license expressions) covering anything that ends up in a given binary RPM (whether compiled to binary code or otherwise). The Fedora package maintainer is in the best position to figure out what this subset of material in the source code is, and how it appears to be licensed.
Importantly, this "simply enumerate" approach means not attempting to do any sort of further analysis such as GPL derivative works analysis, algebraic simplifications or resolutions of long strings of conjunctive license expressions based on longstanding community conventions around FOSS licensing, etc.
As before, any comments on this are most welcome!
Richard
On Mon, May 23, 2022 at 12:37 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline... ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following:
how do you (package maintainers) interpret this policy in practice?
what further information/documentation about this policy would be helpful?
should this policy be different, and if so, how?
any other related thoughts or observations
Thanks! Jilayne _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-
Jilayne Lovejoy -
Neal Gompa -
Richard Fontana -
Vít Ondruch