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
On Mon, May 23, 2022 at 10:07 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, May 23, 2022 at 3:53 PM Jilayne Lovejoy jlovejoy@redhat.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].
Side note: We actually worked around the problem you're discussing with Rust packaging.
- source package name: rust-%{crate} - built packages (containing source code): rust-%{crate}-devel etc. - built packages (containing binaries): %{crate} (usually) - there is no built package with the name rust-%{crate}
So while the main "License" tag from the rust-%{crate} source package (which can be generated from upstream's SPDX metadata) is automatically inherited by all subpackages, the subpackage that actually contains the binaries can have a different "License" tag (i.e. one that takes all statically linked content into account), because its name is different than the name of the source package.
Fabio
On 5/23/22 19:44, 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. This is particularly kludgy when you have vendored or bundled code.
I seem to have a dim recollection of ability to define source license separately being requested at some point years ago, but it never went anywhere, for whatever reason.
...
After rummaging through some dusty archives, turns that discussion took place between Spot and myself in August 2007. No wonder the recollection was dim. I guess there was never any ticket/bug filed on it and the email simply got slowly buried in the sediment.
Feel free to open a ticket at https://github.com/rpm-software-management/rpm/ if this is something we should look into. Doesn't seem like rocket science to add an optional SourceLicense that would be used for the src.rpm license if present, or something like that.
- Panu -
Dne 25. 05. 22 v 8:45 Panu Matilainen napsal(a):
On 5/23/22 19:44, 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. This is particularly kludgy when you have vendored or bundled code.
I seem to have a dim recollection of ability to define source license separately being requested at some point years ago, but it never went anywhere, for whatever reason.
...
After rummaging through some dusty archives, turns that discussion took place between Spot and myself in August 2007. No wonder the recollection was dim. I guess there was never any ticket/bug filed on it and the email simply got slowly buried in the sediment.
Feel free to open a ticket at https://github.com/rpm-software-management/rpm/ if this is something we should look into. Doesn't seem like rocket science to add an optional SourceLicense that would be used for the src.rpm license if present, or something like that.
Sorry for resurrecting old thread. But it was never referred here, that after all. this was requested and implemented in RPM:
https://github.com/rpm-software-management/rpm/issues/2079
https://github.com/rpm-software-management/rpm/pull/2117
therefore there is now `SourceLicense` tag supported by RPM 4.19+ available in F40+.
And I wonder, should we update our license guidelines and start to use the `SourceLicense` tag?
Vít
- Panu - _______________________________________________ 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
On Fri, Mar 22, 2024 at 9:40 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 25. 05. 22 v 8:45 Panu Matilainen napsal(a):
On 5/23/22 19:44, 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. This is particularly kludgy when you have vendored or bundled code.
I seem to have a dim recollection of ability to define source license separately being requested at some point years ago, but it never went anywhere, for whatever reason.
...
After rummaging through some dusty archives, turns that discussion took place between Spot and myself in August 2007. No wonder the recollection was dim. I guess there was never any ticket/bug filed on it and the email simply got slowly buried in the sediment.
Feel free to open a ticket at https://github.com/rpm-software-management/rpm/ if this is something we should look into. Doesn't seem like rocket science to add an optional SourceLicense that would be used for the src.rpm license if present, or something like that.
Sorry for resurrecting old thread. But it was never referred here, that after all. this was requested and implemented in RPM:
https://github.com/rpm-software-management/rpm/issues/2079
https://github.com/rpm-software-management/rpm/pull/2117
therefore there is now `SourceLicense` tag supported by RPM 4.19+ available in F40+.
And I wonder, should we update our license guidelines and start to use the `SourceLicense` tag?
There was an issue several months ago where this was brought up, IIRC. My thought was that use of `SourceLicense:` could be optional in addition to populating `License` but wouldn't be encouraged. But did you mean, should we actually deprecate use of `License` in favor of `SourceLicense` (with all that would imply: the `SourceLicense` tag would then consist of an enumeration of licenses covering the entirety of the source code)? That seems like it would be a pretty radical change, which is not to suggest that it's a bad idea.
Richard
Dne 25. 03. 24 v 14:26 Richard Fontana napsal(a):
On Fri, Mar 22, 2024 at 9:40 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 25. 05. 22 v 8:45 Panu Matilainen napsal(a):
On 5/23/22 19:44, 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. This is particularly kludgy when you have vendored or bundled code.
I seem to have a dim recollection of ability to define source license separately being requested at some point years ago, but it never went anywhere, for whatever reason.
...
After rummaging through some dusty archives, turns that discussion took place between Spot and myself in August 2007. No wonder the recollection was dim. I guess there was never any ticket/bug filed on it and the email simply got slowly buried in the sediment.
Feel free to open a ticket at https://github.com/rpm-software-management/rpm/ if this is something we should look into. Doesn't seem like rocket science to add an optional SourceLicense that would be used for the src.rpm license if present, or something like that.
Sorry for resurrecting old thread. But it was never referred here, that after all. this was requested and implemented in RPM:
https://github.com/rpm-software-management/rpm/issues/2079
https://github.com/rpm-software-management/rpm/pull/2117
therefore there is now `SourceLicense` tag supported by RPM 4.19+ available in F40+.
And I wonder, should we update our license guidelines and start to use the `SourceLicense` tag?
There was an issue several months ago where this was brought up, IIRC. My thought was that use of `SourceLicense:` could be optional in addition to populating `License` but wouldn't be encouraged. But did you mean, should we actually deprecate use of `License` in favor of `SourceLicense` (with all that would imply: the `SourceLicense` tag would then consist of an enumeration of licenses covering the entirety of the source code)? That seems like it would be a pretty radical change, which is not to suggest that it's a bad idea.
My thinking is that we redistribute SRPM and therefore the `SourceLicense:` would be ideal to cover the content of SRPM.
But since you also mentioned deprecating `License` field, it sounds radical, but after all, it would probably make my life easier. I am asking because currently, I am looking at:
https://github.com/ruby/ruby/blob/v3_3_0/missing/dtoa.c
Presumably, this code is used just sometimes on some platforms. Now how am I supposed to know when it happens?
OTOH if we deprecated the `License` tag, then we could keep using it in the `SourceLicense` meaning, right? We went full circle here :)
Vít
Richard
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, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 25. 03. 24 v 15:18 Vít Ondruch napsal(a):
Dne 25. 03. 24 v 14:26 Richard Fontana napsal(a):
On Fri, Mar 22, 2024 at 9:40 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 25. 05. 22 v 8:45 Panu Matilainen napsal(a):
On 5/23/22 19:44, 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. This is particularly kludgy when you have vendored or bundled code.
I seem to have a dim recollection of ability to define source license separately being requested at some point years ago, but it never went anywhere, for whatever reason.
...
After rummaging through some dusty archives, turns that discussion took place between Spot and myself in August 2007. No wonder the recollection was dim. I guess there was never any ticket/bug filed on it and the email simply got slowly buried in the sediment.
Feel free to open a ticket at https://github.com/rpm-software-management/rpm/ if this is something we should look into. Doesn't seem like rocket science to add an optional SourceLicense that would be used for the src.rpm license if present, or something like that.
Sorry for resurrecting old thread. But it was never referred here, that after all. this was requested and implemented in RPM:
https://github.com/rpm-software-management/rpm/issues/2079
https://github.com/rpm-software-management/rpm/pull/2117
therefore there is now `SourceLicense` tag supported by RPM 4.19+ available in F40+.
And I wonder, should we update our license guidelines and start to use the `SourceLicense` tag?
There was an issue several months ago where this was brought up, IIRC. My thought was that use of `SourceLicense:` could be optional in addition to populating `License` but wouldn't be encouraged. But did you mean, should we actually deprecate use of `License` in favor of `SourceLicense` (with all that would imply: the `SourceLicense` tag would then consist of an enumeration of licenses covering the entirety of the source code)? That seems like it would be a pretty radical change, which is not to suggest that it's a bad idea.
My thinking is that we redistribute SRPM and therefore the `SourceLicense:` would be ideal to cover the content of SRPM.
But since you also mentioned deprecating `License` field, it sounds radical, but after all, it would probably make my life easier. I am asking because currently, I am looking at:
https://github.com/ruby/ruby/blob/v3_3_0/missing/dtoa.c
Presumably, this code is used just sometimes on some platforms. Now how am I supposed to know when it happens?
OTOH if we deprecated the `License` tag, then we could keep using it in the `SourceLicense` meaning, right? We went full circle here :)
BTW this is also one of problems with license scanners. Looking at scancode toolkit results for Ruby:
http://miroslav.suchy.cz/fedora/spdx-reports/ruby.html
There are for example referenced `artistic-1.0 OR gpl-1.0-plus` / `gpl-1.0-plus OR artistic-perl-1.0` license. At closer look, this is where the licenses are coming:
https://github.com/ruby/ruby/blob/e51014f9c05aa65cbf203442d37fef7c12390015/L...
and very likely, the win32 files are of no use on Linux. Therefore these licenses are rightfully omitted from the `License` tag. But then, the license scanner output won't ever match the license information captured .spec file. We can never do the basic sanity check that "all licenses reported by scanner are captured in .spec file".
IOW as long as we are trying to provide license of binaries, the results of license scanners always require manual review, which makes them not so convenient.
Vít
Jilayne Lovejoy kirjoitti 23.5.2022 klo 19.31:
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
As a maintainer of modest amount of packages and occassional new package reviewer, the issues I have with the current licensing policy as linked above are:
1. The "effective license" thing that is already discussed in another thread does not appear in the policy at all, and it does not appear in Fedora Licensing page, either. The only places that mention it that I have discovered are Licensing:FAQ [1] and random discussions at mailing lists and so on. This makes it quite difficult to understand if "effective licensing" is actually part of the policy or not. It would be easier to understand its status if it was covered in the policy itself. The policy itself should be unambiguous and possible to interpret without reference to any FAQ. A FAQ should not introduce new requirements and exceptions.
2. In general, it is confusing that the policy is split between Packaging Guidelines, Fedora Licensing main page and, apparently, also the FAQ. How can I determine if any given docs or wiki page is authorative? Would it be possible to consolidate everything that is authorative to a single page and declare it such?
3. Specifically related to the effective licensing question, MIT and BSD basically *only* ask to include the license text when shipping binaries. The effective licensing thing then erases those licenses, if there is GPL somewhere in the mix. The cognitive dissonance between wanting to honor upstream licenses and not shipping them due to effective licensing is serious. Since MIT and BSD are very common licenses, and code under them is also very commonly found embedded in otherwise GPL projects, I would like the licensing policy explicitly cover this situation and explain why it is allowed to not ship the MIT/BSD license in this case. (Perhaps, it would be good to revisit the part of the policy that discussed shipping license texts and consider, why is that required: It is in order to honor upstream licenses, or for some other reason, like end user convenience?)
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen oturpe@iki.fi wrote:
As a maintainer of modest amount of packages and occassional new package reviewer, the issues I have with the current licensing policy as linked above are:
- The "effective license" thing that is already discussed in another
thread does not appear in the policy at all, and it does not appear in Fedora Licensing page, either. The only places that mention it that I have discovered are Licensing:FAQ [1] and random discussions at mailing lists and so on. This makes it quite difficult to understand if "effective licensing" is actually part of the policy or not. It would be easier to understand its status if it was covered in the policy itself. The policy itself should be unambiguous and possible to interpret without reference to any FAQ. A FAQ should not introduce new requirements and exceptions.
That part of the FAQ will have to be revisited, if the approach I suggested today is adopted (a good example of why it isn't exactly maintaining the existing policy). Basically, the "simple enumeration" approach would mean that there is no such thing as "effective licensing".
If people think that "effective licensing" is something that is so valuable that it is worth the resulting unavoidable complexity of analysis and inconsistency across packages, that view should be voiced. I *can* imagine providing some more detailed rules about what "effective licensing" means (and at an earlier stage I was actually thinking of working on something like this). I basically gave up because it's clear no one agrees on what effective licensing means, which means it's not effective. :)
- In general, it is confusing that the policy is split between
Packaging Guidelines, Fedora Licensing main page and, apparently, also the FAQ. How can I determine if any given docs or wiki page is authorative? Would it be possible to consolidate everything that is authorative to a single page and declare it such?
Good idea.
- Specifically related to the effective licensing question, MIT and BSD
basically *only* ask to include the license text when shipping binaries. The effective licensing thing then erases those licenses, if there is GPL somewhere in the mix. The cognitive dissonance between wanting to honor upstream licenses and not shipping them due to effective licensing is serious. Since MIT and BSD are very common licenses, and code under them is also very commonly found embedded in otherwise GPL projects, I would like the licensing policy explicitly cover this situation and explain why it is allowed to not ship the MIT/BSD license in this case. (Perhaps, it would be good to revisit the part of the policy that discussed shipping license texts and consider, why is that required: It is in order to honor upstream licenses, or for some other reason, like end user convenience?)
All the licenses are shipped in that they are found in the SRPM. Implicitly, Fedora's position is that this is compliant with those permissive licenses. I think the issue you're raising is Fedora's policy on what license texts to install in /usr/share/licenses. I don't think that issue is directly tied to how the License: field is populated. I couldn't immediately find any documentation on the /usr/share/licenses policy, but my intuition from looking at lots of Fedora and RHEL packages is that this contains any license text that seems to be "global" in some way, and in cases where there is no obvious such license, some appropriate license is selected from the source files for this purpose. We might want to separately revisit the /usr/share/licenses policy at some point if there is interest.
Richard
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
--
On Mon, Jun 6, 2022 at 5:13 PM Richard Fontana rfontana@redhat.com wrote:
We might want to separately revisit the /usr/share/licenses policy at some point if there is interest.
Oh, while we are on that topic, I will repeat what I think I've said before, that Fedora should consider adopting the Debian approach of having a /usr/share/common-licenses directory. (Debian also has a per-package "copyright file" approach that is related to this topic but that would probably be more controversial.)
Richard
Richard Fontana rfontana@redhat.com writes:
Oh, while we are on that topic, I will repeat what I think I've said before, that Fedora should consider adopting the Debian approach of having a /usr/share/common-licenses directory.
How would this differ from what we do currently, besides the obvious name change from the current /usr/share/licenses directory? Is it a question of the directory layout, or something more basic like ignoring the license text from upstream completely and just linking to it?
- J<
On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen oturpe@iki.fi wrote:
As a maintainer of modest amount of packages and occassional new package reviewer, the issues I have with the current licensing policy as linked above are:
- The "effective license" thing that is already discussed in another
thread does not appear in the policy at all, and it does not appear in Fedora Licensing page, either. The only places that mention it that I have discovered are Licensing:FAQ [1] and random discussions at mailing lists and so on. This makes it quite difficult to understand if "effective licensing" is actually part of the policy or not. It would be easier to understand its status if it was covered in the policy itself. The policy itself should be unambiguous and possible to interpret without reference to any FAQ. A FAQ should not introduce new requirements and exceptions.
That part of the FAQ will have to be revisited, if the approach I suggested today is adopted (a good example of why it isn't exactly maintaining the existing policy). Basically, the "simple enumeration" approach would mean that there is no such thing as "effective licensing".
I wonder what you think about simple cases of "effective" licenses? For example, most Rust projects are dual-licensed as "Apache-2.0 OR MIT", but some odd ones are released under "MIT"-only or "Apache-2.0"-only licenses.
So, for a binary package that contains code from both "Apache-2.0 OR MIT" and "MIT"-only projects, we usually "collapsed" that into just "MIT". Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND MIT" - would be kind of silly, in my opinion. Adding the full "Apache-2.0 OR MIT" choice from the first project seems to be pointless, since it actually cannot result in a choice of license - because that choice is already forced by the "MIT"-only second project. Please correct me if this analysis is wrong.
Fabio
On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen oturpe@iki.fi wrote:
As a maintainer of modest amount of packages and occassional new package reviewer, the issues I have with the current licensing policy as linked above are:
- The "effective license" thing that is already discussed in another
thread does not appear in the policy at all, and it does not appear in Fedora Licensing page, either. The only places that mention it that I have discovered are Licensing:FAQ [1] and random discussions at mailing lists and so on. This makes it quite difficult to understand if "effective licensing" is actually part of the policy or not. It would be easier to understand its status if it was covered in the policy itself. The policy itself should be unambiguous and possible to interpret without reference to any FAQ. A FAQ should not introduce new requirements and exceptions.
That part of the FAQ will have to be revisited, if the approach I suggested today is adopted (a good example of why it isn't exactly maintaining the existing policy). Basically, the "simple enumeration" approach would mean that there is no such thing as "effective licensing".
I wonder what you think about simple cases of "effective" licenses? For example, most Rust projects are dual-licensed as "Apache-2.0 OR MIT", but some odd ones are released under "MIT"-only or "Apache-2.0"-only licenses.
So, for a binary package that contains code from both "Apache-2.0 OR MIT" and "MIT"-only projects, we usually "collapsed" that into just "MIT". Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND MIT" - would be kind of silly, in my opinion.
I wanted to follow up on this point since it does feel to me like we are stubbornly clinging to the practice of recording a FOSS dual license in the license tag, when not doing so could provide some simplification of license tag expressions.
In my mind, there were a few reasons for this practice: (1) it was what Fedora traditionally did; (2) it matches general upstream culture (the idea of passing down a FOSS license choice through a chain of distributees; (3) there's a contrary corporate culture seen in some quarters of making sure that "bad" (from their perspective) FOSS licenses in a dual license scheme are eliminated, which I think is based mostly on ignorance and copyleftphobia and so forth, which we don't want to encourage or be associated with; (4) there isn't going to be a good, consistently-applicable basis for selecting one or the other license -- this is related to (3). (4) is also related to the "effective license" problem: there isn't really any coherent effective license doctrine that can be consistently applied. I guess also (5) which is a community counterpart to (3): you would end up with licenses being selected out of a dual license based on the individual preferences of a Fedora packager. In one case, a Fedora packager might personally prefer the Apache License 2.0 over MIT, in another case the opposite. This contradicts the tradition of passing down the choice to the user.
Adding the full "Apache-2.0 OR MIT" choice from the first project seems to be pointless, since it actually cannot result in a choice of license - because that choice is already forced by the "MIT"-only second project. Please correct me if this analysis is wrong.
I understand this point but the idea that the choice is forced seems to be a form of "effective license" analysis. I am not dismissive of the idea since I think there is something fundamentally unclear about what composite licensing means. However, the general problems with effective license analysis apply to this case too.
Richard
On 7/12/22 8:31 AM, Richard Fontana wrote:
On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen oturpe@iki.fi wrote:
I wonder what you think about simple cases of "effective" licenses? For example, most Rust projects are dual-licensed as "Apache-2.0 OR MIT", but some odd ones are released under "MIT"-only or "Apache-2.0"-only licenses.
So, for a binary package that contains code from both "Apache-2.0 OR MIT" and "MIT"-only projects, we usually "collapsed" that into just "MIT". Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND MIT" - would be kind of silly, in my opinion.
I wanted to follow up on this point since it does feel to me like we are stubbornly clinging to the practice of recording a FOSS dual license in the license tag, when not doing so could provide some simplification of license tag expressions.
In my mind, there were a few reasons for this practice: (1) it was what Fedora traditionally did; (2) it matches general upstream culture (the idea of passing down a FOSS license choice through a chain of distributees; (3) there's a contrary corporate culture seen in some quarters of making sure that "bad" (from their perspective) FOSS licenses in a dual license scheme are eliminated, which I think is based mostly on ignorance and copyleftphobia and so forth, which we don't want to encourage or be associated with; (4) there isn't going to be a good, consistently-applicable basis for selecting one or the other license -- this is related to (3). (4) is also related to the "effective license" problem: there isn't really any coherent effective license doctrine that can be consistently applied. I guess also (5) which is a community counterpart to (3): you would end up with licenses being selected out of a dual license based on the individual preferences of a Fedora packager. In one case, a Fedora packager might personally prefer the Apache License 2.0 over MIT, in another case the opposite. This contradicts the tradition of passing down the choice to the user.
Ha, you start out with "stubbornly clinging" and that maybe not recording the dual license in the license tag helping simply things, but then after reading your points (1) through (5), I felt even more convinced of the value in recording/retaining such info!
I must say - the scenario where someone makes the choices (point (3) by example) can be really annoying for downstream recipients or downstream of downstream. I have memories of doing source code audits and running into this and relying on some form of "tribal knowledge" that there was a choice upstream that had gotten removed and then going upstream to find it, so the choice could be made "again". Fedora, as a free and open source software distro, need not make an explicit choice between two free and open source licenses (in the way a commercial software distribution might), so the policy of passing along the original choice makes sense to me as a matter of convenience (for downstream recipients) and in keeping with the principles of Fedora being free and open more generally.
Adding the full "Apache-2.0 OR MIT" choice from the first project seems to be pointless, since it actually cannot result in a choice of license - because that choice is already forced by the "MIT"-only second project. Please correct me if this analysis is wrong.
sort of, but given the above points, I don't think it hurts to capture "(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as to what is going on.
I understand this point but the idea that the choice is forced seems to be a form of "effective license" analysis. I am not dismissive of the idea since I think there is something fundamentally unclear about what composite licensing means. However, the general problems with effective license analysis apply to this case too.
Richard _______________________________________________ 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
On Wed, Jul 13, 2022 at 10:38 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 7/12/22 8:31 AM, Richard Fontana wrote:
On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen oturpe@iki.fi wrote:
I wonder what you think about simple cases of "effective" licenses? For example, most Rust projects are dual-licensed as "Apache-2.0 OR MIT", but some odd ones are released under "MIT"-only or "Apache-2.0"-only licenses.
So, for a binary package that contains code from both "Apache-2.0 OR MIT" and "MIT"-only projects, we usually "collapsed" that into just "MIT". Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND MIT" - would be kind of silly, in my opinion.
I wanted to follow up on this point since it does feel to me like we are stubbornly clinging to the practice of recording a FOSS dual license in the license tag, when not doing so could provide some simplification of license tag expressions.
In my mind, there were a few reasons for this practice: (1) it was what Fedora traditionally did; (2) it matches general upstream culture (the idea of passing down a FOSS license choice through a chain of distributees; (3) there's a contrary corporate culture seen in some quarters of making sure that "bad" (from their perspective) FOSS licenses in a dual license scheme are eliminated, which I think is based mostly on ignorance and copyleftphobia and so forth, which we don't want to encourage or be associated with; (4) there isn't going to be a good, consistently-applicable basis for selecting one or the other license -- this is related to (3). (4) is also related to the "effective license" problem: there isn't really any coherent effective license doctrine that can be consistently applied. I guess also (5) which is a community counterpart to (3): you would end up with licenses being selected out of a dual license based on the individual preferences of a Fedora packager. In one case, a Fedora packager might personally prefer the Apache License 2.0 over MIT, in another case the opposite. This contradicts the tradition of passing down the choice to the user.
Ha, you start out with "stubbornly clinging" and that maybe not recording the dual license in the license tag helping simply things, but then after reading your points (1) through (5), I felt even more convinced of the value in recording/retaining such info!
I must say - the scenario where someone makes the choices (point (3) by example) can be really annoying for downstream recipients or downstream of downstream. I have memories of doing source code audits and running into this and relying on some form of "tribal knowledge" that there was a choice upstream that had gotten removed and then going upstream to find it, so the choice could be made "again". Fedora, as a free and open source software distro, need not make an explicit choice between two free and open source licenses (in the way a commercial software distribution might), so the policy of passing along the original choice makes sense to me as a matter of convenience (for downstream recipients) and in keeping with the principles of Fedora being free and open more generally.
Sorry, I'm somewhat confused by these last two responses to my question.
On the other hand, you seem to be making arguments that *favor* simplification of dual licenses. But the conclusion seems to be that "just specify everything" is still better?
For a few packages, the license string would get very long (hundreds of characters), and basically meaningless for any user of the package.
And what I don't understand: In the case of a project that contains - or includes - both "(ASL 2.0 OR MIT)" and "MIT" licensed code, hasn't the upstream project basically already made the decision about the resulting license (i.e. "MIT")?
Assume that I as the packager would actually make a "choice" here, and "choose" ASL 2.0", that would result in a package with license "ASL 2.0 and MIT". However, if I make the more "obvious" choice of "MIT", the license will be just "MIT".
So the first "choice" results in a package with *strictly more* licensing restrictions than the second "choice". I as the packager don't want to (or should?) produce a package that has stronger licensing restrictions than necessary (or intended).
Adding the full "Apache-2.0 OR MIT" choice from the first project seems to be pointless, since it actually cannot result in a choice of license - because that choice is already forced by the "MIT"-only second project. Please correct me if this analysis is wrong.
sort of, but given the above points, I don't think it hurts to capture "(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as to what is going on.
It might be accurate. But this is also a very simplified example to illustrate my point.
Here's a more realistic one (taken from one of my packages, where I also happen to be the upstream developer). This is the list of licenses of the project itself and its dependencies, which are all statically linked together into a final binary:
# (ASL 2.0 or MIT) and BSD # ASL 2.0 # ASL 2.0 or Boost # ASL 2.0 or MIT # BSD # MIT # MIT or ASL 2.0 # MIT or ASL 2.0 or zlib # Unlicense or MIT # zlib or ASL 2.0 or MIT
Just recording everything would result in a license string of: License: (ASL 2.0 or MIT) and BSD and ASL 2.0 and (ASL 2.0 or Boost) and (ASL 2.0 or MIT) and BSD and MIT and (MIT or ASL 2.0) and (MIT or ASL 2.0 or zlib) and (Unlicense or MIT) and (zlib or ASL 2.0 or MIT)
This is already kind of silly, because it's stupidly long, and there are duplicates, or clauses that are identical except for the order of their contents. I would not say that this is "somewhat obvious as to what is going on", because nobody will even read this string in its entirety.
Now, is reordering the contents of the clauses and removing any duplicates already considered as doing an "effective license analysis"? :)
Anyhow, for this package, I have "simplified" the license string to: License: ASL 2.0 and BSD and MIT
This satisfies every clause, and I'd argue it is *much more obvious* to users what it means than the silly long string above. It doesn't give users any "choices", but any "choice" they would have made (differently than what I did when packaging this project) would have resulted in a package with *strictly more* restrictions, but never *fewer*.
I'd argue that 1) minimizing restrictions and 2) making the resulting license actually understandable for users is much more important than to preserve any "choice" that, if exercised differently, would only result in either more restrictions, more complicated licensing terms, or both.
Fabio
HI Fabio
On 7/13/22 3:09 PM, Fabio Valentini wrote:
On Wed, Jul 13, 2022 at 10:38 PM Jilayne Lovejoyjlovejoy@redhat.com wrote:
On 7/12/22 8:31 AM, Richard Fontana wrote:
On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentinidecathorpe@gmail.com wrote:
On Mon, Jun 6, 2022 at 11:14 PM Richard Fontanarfontana@redhat.com wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainenoturpe@iki.fi wrote:
I wonder what you think about simple cases of "effective" licenses? For example, most Rust projects are dual-licensed as "Apache-2.0 OR MIT", but some odd ones are released under "MIT"-only or "Apache-2.0"-only licenses.
So, for a binary package that contains code from both "Apache-2.0 OR MIT" and "MIT"-only projects, we usually "collapsed" that into just "MIT". Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND MIT" - would be kind of silly, in my opinion.
I wanted to follow up on this point since it does feel to me like we are stubbornly clinging to the practice of recording a FOSS dual license in the license tag, when not doing so could provide some simplification of license tag expressions.
In my mind, there were a few reasons for this practice: (1) it was what Fedora traditionally did; (2) it matches general upstream culture (the idea of passing down a FOSS license choice through a chain of distributees; (3) there's a contrary corporate culture seen in some quarters of making sure that "bad" (from their perspective) FOSS licenses in a dual license scheme are eliminated, which I think is based mostly on ignorance and copyleftphobia and so forth, which we don't want to encourage or be associated with; (4) there isn't going to be a good, consistently-applicable basis for selecting one or the other license -- this is related to (3). (4) is also related to the "effective license" problem: there isn't really any coherent effective license doctrine that can be consistently applied. I guess also (5) which is a community counterpart to (3): you would end up with licenses being selected out of a dual license based on the individual preferences of a Fedora packager. In one case, a Fedora packager might personally prefer the Apache License 2.0 over MIT, in another case the opposite. This contradicts the tradition of passing down the choice to the user.
Ha, you start out with "stubbornly clinging" and that maybe not recording the dual license in the license tag helping simply things, but then after reading your points (1) through (5), I felt even more convinced of the value in recording/retaining such info!
I must say - the scenario where someone makes the choices (point (3) by example) can be really annoying for downstream recipients or downstream of downstream. I have memories of doing source code audits and running into this and relying on some form of "tribal knowledge" that there was a choice upstream that had gotten removed and then going upstream to find it, so the choice could be made "again". Fedora, as a free and open source software distro, need not make an explicit choice between two free and open source licenses (in the way a commercial software distribution might), so the policy of passing along the original choice makes sense to me as a matter of convenience (for downstream recipients) and in keeping with the principles of Fedora being free and open more generally.
Sorry, I'm somewhat confused by these last two responses to my question.
On the other hand, you seem to be making arguments that *favor* simplification of dual licenses. But the conclusion seems to be that "just specify everything" is still better?
yeah... I think Richard and I are both sort of working through this as you all come up with additional and perhaps more complex examples :) (and trying to add to/draft guidance that will be (relative) easy to follow and captures enough actual examples as well)
Adding the full "Apache-2.0 OR MIT" choice from the first project seems to be pointless, since it actually cannot result in a choice of license - because that choice is already forced by the "MIT"-only second project. Please correct me if this analysis is wrong.
sort of, but given the above points, I don't think it hurts to capture "(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as to what is going on.
It might be accurate. But this is also a very simplified example to illustrate my point.
ok, fair enough - that was a simple example. And I have a feeling that the guidance on dual-licensed packages probably contemplated more simple scenarios, but...
Here's a more realistic one (taken from one of my packages, where I also happen to be the upstream developer).
great!
This is the list of licenses of the project itself and its dependencies, which are all statically linked together into a final binary:
# (ASL 2.0 or MIT) and BSD # ASL 2.0 # ASL 2.0 or Boost # ASL 2.0 or MIT # BSD # MIT # MIT or ASL 2.0 # MIT or ASL 2.0 or zlib # Unlicense or MIT # zlib or ASL 2.0 or MIT
Just recording everything would result in a license string of: License: (ASL 2.0 or MIT) and BSD and ASL 2.0 and (ASL 2.0 or Boost) and (ASL 2.0 or MIT) and BSD and MIT and (MIT or ASL 2.0) and (MIT or ASL 2.0 or zlib) and (Unlicense or MIT) and (zlib or ASL 2.0 or MIT)
This is already kind of silly, because it's stupidly long, and there are duplicates, or clauses that are identical except for the order of their contents. I would not say that this is "somewhat obvious as to what is going on", because nobody will even read this string in its entirety.
yeah, this is a more interesting example for sure and agreed, it does get a bit ridiculous looking even if still "accurate"
Now, is reordering the contents of the clauses and removing any duplicates already considered as doing an "effective license analysis"? :)
Anyhow, for this package, I have "simplified" the license string to: License: ASL 2.0 and BSD and MIT
This satisfies every clause, and I'd argue it is *much more obvious* to users what it means than the silly long string above. It doesn't give users any "choices", but any "choice" they would have made (differently than what I did when packaging this project) would have resulted in a package with *strictly more* restrictions, but never *fewer*.
I'd argue that 1) minimizing restrictions and 2) making the resulting license actually understandable for users is much more important than to preserve any "choice" that, if exercised differently, would only result in either more restrictions, more complicated licensing terms, or both.
Thanks for this, really helpful. Richard and I will discuss a bit more...
Going back to some of the original comments in this thread (or another similar one?) - is the above actual example a common scenario for Rust and Go packages? And can it get even more complex or lengthy than this example? Just trying to get a sense of the typical range of examples you all come up against, so we can be sure to try to cover those.
Thanks! Jilayne
Fabio _______________________________________________ packaging mailing list --packaging@lists.fedoraproject.org To unsubscribe send an email topackaging-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
So, in Fabio's example, you could simplify it somewhat, because under our in-progress guidelines we say or intend to say that order of license identifiers in a license expression doesn't matter: i.e., (MIT OR Apache-2.0) is the same as (Apache-2.0 OR MIT) (Jilayne, does the SPDX spec itself say this?). So you wouldn't repeat those, any more than you'd repeat multiple occurrences of "MIT" (say, a package with multiple executable binaries each determined to be under the MIT license). This is an aspect of the "simple enumeration" policy. The resulting license expression will still be pretty lengthy, I admit.
For me personally, I think experience has shown that simplification of license description is fraught with problems and it is better to attempt greater accuracy around license description. This is a major reason why I (a longtime skeptic of SPDX) got on board with the idea of Fedora using SPDX identifiers, because if used properly they provide more information than counterpart Callaway expressions. On the other hand, if the license tags don't really matter to users, why have them at all? I just don't see the point of a middle ground between no license tags and license tags that attempt accurate description, where the middle ground is going to involve value judgements and legal analysis that will differ from packager to packager.
If we were to start entertaining some rules around license expression simplification, though, I think the dual licenses would be a logical place to start.
Richard
On Wed, Jul 13, 2022 at 5:19 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
HI Fabio
On 7/13/22 3:09 PM, Fabio Valentini wrote:
On Wed, Jul 13, 2022 at 10:38 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 7/12/22 8:31 AM, Richard Fontana wrote:
On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen oturpe@iki.fi wrote:
I wonder what you think about simple cases of "effective" licenses? For example, most Rust projects are dual-licensed as "Apache-2.0 OR MIT", but some odd ones are released under "MIT"-only or "Apache-2.0"-only licenses.
So, for a binary package that contains code from both "Apache-2.0 OR MIT" and "MIT"-only projects, we usually "collapsed" that into just "MIT". Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND MIT" - would be kind of silly, in my opinion.
I wanted to follow up on this point since it does feel to me like we are stubbornly clinging to the practice of recording a FOSS dual license in the license tag, when not doing so could provide some simplification of license tag expressions.
In my mind, there were a few reasons for this practice: (1) it was what Fedora traditionally did; (2) it matches general upstream culture (the idea of passing down a FOSS license choice through a chain of distributees; (3) there's a contrary corporate culture seen in some quarters of making sure that "bad" (from their perspective) FOSS licenses in a dual license scheme are eliminated, which I think is based mostly on ignorance and copyleftphobia and so forth, which we don't want to encourage or be associated with; (4) there isn't going to be a good, consistently-applicable basis for selecting one or the other license -- this is related to (3). (4) is also related to the "effective license" problem: there isn't really any coherent effective license doctrine that can be consistently applied. I guess also (5) which is a community counterpart to (3): you would end up with licenses being selected out of a dual license based on the individual preferences of a Fedora packager. In one case, a Fedora packager might personally prefer the Apache License 2.0 over MIT, in another case the opposite. This contradicts the tradition of passing down the choice to the user.
Ha, you start out with "stubbornly clinging" and that maybe not recording the dual license in the license tag helping simply things, but then after reading your points (1) through (5), I felt even more convinced of the value in recording/retaining such info!
I must say - the scenario where someone makes the choices (point (3) by example) can be really annoying for downstream recipients or downstream of downstream. I have memories of doing source code audits and running into this and relying on some form of "tribal knowledge" that there was a choice upstream that had gotten removed and then going upstream to find it, so the choice could be made "again". Fedora, as a free and open source software distro, need not make an explicit choice between two free and open source licenses (in the way a commercial software distribution might), so the policy of passing along the original choice makes sense to me as a matter of convenience (for downstream recipients) and in keeping with the principles of Fedora being free and open more generally.
Sorry, I'm somewhat confused by these last two responses to my question.
On the other hand, you seem to be making arguments that *favor* simplification of dual licenses. But the conclusion seems to be that "just specify everything" is still better?
yeah... I think Richard and I are both sort of working through this as you all come up with additional and perhaps more complex examples :) (and trying to add to/draft guidance that will be (relative) easy to follow and captures enough actual examples as well)
Adding the full "Apache-2.0 OR MIT" choice from the first project seems to be pointless, since it actually cannot result in a choice of license - because that choice is already forced by the "MIT"-only second project. Please correct me if this analysis is wrong.
sort of, but given the above points, I don't think it hurts to capture "(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as to what is going on.
It might be accurate. But this is also a very simplified example to illustrate my point.
ok, fair enough - that was a simple example. And I have a feeling that the guidance on dual-licensed packages probably contemplated more simple scenarios, but...
Here's a more realistic one (taken from one of my packages, where I also happen to be the upstream developer).
great!
This is the list of licenses of the project itself and its dependencies, which are all statically linked together into a final binary:
# (ASL 2.0 or MIT) and BSD # ASL 2.0 # ASL 2.0 or Boost # ASL 2.0 or MIT # BSD # MIT # MIT or ASL 2.0 # MIT or ASL 2.0 or zlib # Unlicense or MIT # zlib or ASL 2.0 or MIT
Just recording everything would result in a license string of: License: (ASL 2.0 or MIT) and BSD and ASL 2.0 and (ASL 2.0 or Boost) and (ASL 2.0 or MIT) and BSD and MIT and (MIT or ASL 2.0) and (MIT or ASL 2.0 or zlib) and (Unlicense or MIT) and (zlib or ASL 2.0 or MIT)
This is already kind of silly, because it's stupidly long, and there are duplicates, or clauses that are identical except for the order of their contents. I would not say that this is "somewhat obvious as to what is going on", because nobody will even read this string in its entirety.
yeah, this is a more interesting example for sure and agreed, it does get a bit ridiculous looking even if still "accurate"
Now, is reordering the contents of the clauses and removing any duplicates already considered as doing an "effective license analysis"? :)
Anyhow, for this package, I have "simplified" the license string to: License: ASL 2.0 and BSD and MIT
This satisfies every clause, and I'd argue it is *much more obvious* to users what it means than the silly long string above. It doesn't give users any "choices", but any "choice" they would have made (differently than what I did when packaging this project) would have resulted in a package with *strictly more* restrictions, but never *fewer*.
I'd argue that 1) minimizing restrictions and 2) making the resulting license actually understandable for users is much more important than to preserve any "choice" that, if exercised differently, would only result in either more restrictions, more complicated licensing terms, or both.
Thanks for this, really helpful. Richard and I will discuss a bit more...
Going back to some of the original comments in this thread (or another similar one?) - is the above actual example a common scenario for Rust and Go packages? And can it get even more complex or lengthy than this example? Just trying to get a sense of the typical range of examples you all come up against, so we can be sure to try to cover those.
Thanks! Jilayne
Fabio _______________________________________________ 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
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
I would add, though I guess it's covered by what I said, that there are situations where it's not clear, as a matter of what's basically legal analysis, which side of a FOSS dual license is actually 'better'. A good example might be the Sun GPLv2 with Classpath Exception | CDDL case -- in the cases where that dual license applies, you can come up with arguments why one or the other license is preferable based on various factors.
- Richard
On Wed, Jul 13, 2022 at 4:37 PM Jilayne Lovejoy jlovejoy@redhat.com wrote:
On 7/12/22 8:31 AM, Richard Fontana wrote:
On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Jun 6, 2022 at 11:14 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen oturpe@iki.fi wrote:
I wonder what you think about simple cases of "effective" licenses? For example, most Rust projects are dual-licensed as "Apache-2.0 OR MIT", but some odd ones are released under "MIT"-only or "Apache-2.0"-only licenses.
So, for a binary package that contains code from both "Apache-2.0 OR MIT" and "MIT"-only projects, we usually "collapsed" that into just "MIT". Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND MIT" - would be kind of silly, in my opinion.
I wanted to follow up on this point since it does feel to me like we are stubbornly clinging to the practice of recording a FOSS dual license in the license tag, when not doing so could provide some simplification of license tag expressions.
In my mind, there were a few reasons for this practice: (1) it was what Fedora traditionally did; (2) it matches general upstream culture (the idea of passing down a FOSS license choice through a chain of distributees; (3) there's a contrary corporate culture seen in some quarters of making sure that "bad" (from their perspective) FOSS licenses in a dual license scheme are eliminated, which I think is based mostly on ignorance and copyleftphobia and so forth, which we don't want to encourage or be associated with; (4) there isn't going to be a good, consistently-applicable basis for selecting one or the other license -- this is related to (3). (4) is also related to the "effective license" problem: there isn't really any coherent effective license doctrine that can be consistently applied. I guess also (5) which is a community counterpart to (3): you would end up with licenses being selected out of a dual license based on the individual preferences of a Fedora packager. In one case, a Fedora packager might personally prefer the Apache License 2.0 over MIT, in another case the opposite. This contradicts the tradition of passing down the choice to the user.
Ha, you start out with "stubbornly clinging" and that maybe not recording the dual license in the license tag helping simply things, but then after reading your points (1) through (5), I felt even more convinced of the value in recording/retaining such info!
I must say - the scenario where someone makes the choices (point (3) by example) can be really annoying for downstream recipients or downstream of downstream. I have memories of doing source code audits and running into this and relying on some form of "tribal knowledge" that there was a choice upstream that had gotten removed and then going upstream to find it, so the choice could be made "again". Fedora, as a free and open source software distro, need not make an explicit choice between two free and open source licenses (in the way a commercial software distribution might), so the policy of passing along the original choice makes sense to me as a matter of convenience (for downstream recipients) and in keeping with the principles of Fedora being free and open more generally.
Adding the full "Apache-2.0 OR MIT" choice from the first project seems to be pointless, since it actually cannot result in a choice of license - because that choice is already forced by the "MIT"-only second project. Please correct me if this analysis is wrong.
sort of, but given the above points, I don't think it hurts to capture "(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as to what is going on.
I understand this point but the idea that the choice is forced seems to be a form of "effective license" analysis. I am not dismissive of the idea since I think there is something fundamentally unclear about what composite licensing means. However, the general problems with effective license analysis apply to this case too.
Richard _______________________________________________ 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
how did you know that is the exact past example I was thinking of that plagued me in the past!! (and hoping it's a bit less common these days... or at least not found as part of the complex scenario that Fabio just mentioned)
:)
On 7/13/22 3:14 PM, Richard Fontana wrote:
I would add, though I guess it's covered by what I said, that there are situations where it's not clear, as a matter of what's basically legal analysis, which side of a FOSS dual license is actually 'better'. A good example might be the Sun GPLv2 with Classpath Exception | CDDL case -- in the cases where that dual license applies, you can come up with arguments why one or the other license is preferable based on various factors.
- Richard
On Wed, Jul 13, 2022 at 4:37 PM Jilayne Lovejoyjlovejoy@redhat.com wrote:
On 7/12/22 8:31 AM, Richard Fontana wrote:
On Mon, Jun 6, 2022 at 5:51 PM Fabio Valentinidecathorpe@gmail.com wrote:
On Mon, Jun 6, 2022 at 11:14 PM Richard Fontanarfontana@redhat.com wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainenoturpe@iki.fi wrote:
I wonder what you think about simple cases of "effective" licenses? For example, most Rust projects are dual-licensed as "Apache-2.0 OR MIT", but some odd ones are released under "MIT"-only or "Apache-2.0"-only licenses.
So, for a binary package that contains code from both "Apache-2.0 OR MIT" and "MIT"-only projects, we usually "collapsed" that into just "MIT". Just enumerating the licenses in this case - "(Apache-2.0 OR MIT) AND MIT" - would be kind of silly, in my opinion.
I wanted to follow up on this point since it does feel to me like we are stubbornly clinging to the practice of recording a FOSS dual license in the license tag, when not doing so could provide some simplification of license tag expressions.
In my mind, there were a few reasons for this practice: (1) it was what Fedora traditionally did; (2) it matches general upstream culture (the idea of passing down a FOSS license choice through a chain of distributees; (3) there's a contrary corporate culture seen in some quarters of making sure that "bad" (from their perspective) FOSS licenses in a dual license scheme are eliminated, which I think is based mostly on ignorance and copyleftphobia and so forth, which we don't want to encourage or be associated with; (4) there isn't going to be a good, consistently-applicable basis for selecting one or the other license -- this is related to (3). (4) is also related to the "effective license" problem: there isn't really any coherent effective license doctrine that can be consistently applied. I guess also (5) which is a community counterpart to (3): you would end up with licenses being selected out of a dual license based on the individual preferences of a Fedora packager. In one case, a Fedora packager might personally prefer the Apache License 2.0 over MIT, in another case the opposite. This contradicts the tradition of passing down the choice to the user.
Ha, you start out with "stubbornly clinging" and that maybe not recording the dual license in the license tag helping simply things, but then after reading your points (1) through (5), I felt even more convinced of the value in recording/retaining such info!
I must say - the scenario where someone makes the choices (point (3) by example) can be really annoying for downstream recipients or downstream of downstream. I have memories of doing source code audits and running into this and relying on some form of "tribal knowledge" that there was a choice upstream that had gotten removed and then going upstream to find it, so the choice could be made "again". Fedora, as a free and open source software distro, need not make an explicit choice between two free and open source licenses (in the way a commercial software distribution might), so the policy of passing along the original choice makes sense to me as a matter of convenience (for downstream recipients) and in keeping with the principles of Fedora being free and open more generally.
Adding the full "Apache-2.0 OR MIT" choice from the first project seems to be pointless, since it actually cannot result in a choice of license - because that choice is already forced by the "MIT"-only second project. Please correct me if this analysis is wrong.
sort of, but given the above points, I don't think it hurts to capture "(Apache-2.0 OR MIT) AND MIT" - it's accurate and somewhat obvious as to what is going on.
I understand this point but the idea that the choice is forced seems to be a form of "effective license" analysis. I am not dismissive of the idea since I think there is something fundamentally unclear about what composite licensing means. However, the general problems with effective license analysis apply to this case too.
Richard _______________________________________________ packaging mailing list --packaging@lists.fedoraproject.org To unsubscribe send an email topackaging-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
On 6/6/22 3:13 PM, Richard Fontana wrote:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen oturpe@iki.fi wrote:
As a maintainer of modest amount of packages and occassional new package reviewer, the issues I have with the current licensing policy as linked above are:
- The "effective license" thing that is already discussed in another
thread does not appear in the policy at all, and it does not appear in Fedora Licensing page, either. The only places that mention it that I have discovered are Licensing:FAQ [1] and random discussions at mailing lists and so on. This makes it quite difficult to understand if "effective licensing" is actually part of the policy or not. It would be easier to understand its status if it was covered in the policy itself. The policy itself should be unambiguous and possible to interpret without reference to any FAQ. A FAQ should not introduce new requirements and exceptions.
That part of the FAQ will have to be revisited, if the approach I suggested today is adopted (a good example of why it isn't exactly maintaining the existing policy). Basically, the "simple enumeration" approach would mean that there is no such thing as "effective licensing".
If people think that "effective licensing" is something that is so valuable that it is worth the resulting unavoidable complexity of analysis and inconsistency across packages, that view should be voiced. I *can* imagine providing some more detailed rules about what "effective licensing" means (and at an earlier stage I was actually thinking of working on something like this). I basically gave up because it's clear no one agrees on what effective licensing means, which means it's not effective. :)
- In general, it is confusing that the policy is split between
Packaging Guidelines, Fedora Licensing main page and, apparently, also the FAQ. How can I determine if any given docs or wiki page is authorative? Would it be possible to consolidate everything that is authorative to a single page and declare it such?
Good idea.
Absolutely. We are thinking that the end result here would be the packaging guidelines[1] where the policy is stated in one sentence followed by, "When in doubt, ask." would instead say something like, "For more information, see LINK" - where the link would go to ONE (new) page in the Fedora-legal docs further explaining the policy and providing examples. This would include anything helpful or revised from the original wiki FAQ page as applicable. The idea being that we don't want to clutter up the packaging guidelines page with policy details, examples etc.
And yes, the existing examples on the packaging guidelines page will also be reviewed in light of this and updated as needed.
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline...
- Specifically related to the effective licensing question, MIT and BSD
basically *only* ask to include the license text when shipping binaries. The effective licensing thing then erases those licenses, if there is GPL somewhere in the mix. The cognitive dissonance between wanting to honor upstream licenses and not shipping them due to effective licensing is serious. Since MIT and BSD are very common licenses, and code under them is also very commonly found embedded in otherwise GPL projects, I would like the licensing policy explicitly cover this situation and explain why it is allowed to not ship the MIT/BSD license in this case. (Perhaps, it would be good to revisit the part of the policy that discussed shipping license texts and consider, why is that required: It is in order to honor upstream licenses, or for some other reason, like end user convenience?)
All the licenses are shipped in that they are found in the SRPM. Implicitly, Fedora's position is that this is compliant with those permissive licenses. I think the issue you're raising is Fedora's policy on what license texts to install in /usr/share/licenses. I don't think that issue is directly tied to how the License: field is populated. I couldn't immediately find any documentation on the /usr/share/licenses policy, but my intuition from looking at lots of Fedora and RHEL packages is that this contains any license text that seems to be "global" in some way, and in cases where there is no obvious such license, some appropriate license is selected from the source files for this purpose. We might want to separately revisit the /usr/share/licenses policy at some point if there is interest.
Richard
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
--
Richard Fontana kirjoitti 7.6.2022 klo 0.13:
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen oturpe@iki.fi wrote:
- Specifically related to the effective licensing question, MIT and BSD
basically *only* ask to include the license text when shipping binaries. The effective licensing thing then erases those licenses, if there is GPL somewhere in the mix. The cognitive dissonance between wanting to honor upstream licenses and not shipping them due to effective licensing is serious. Since MIT and BSD are very common licenses, and code under them is also very commonly found embedded in otherwise GPL projects, I would like the licensing policy explicitly cover this situation and explain why it is allowed to not ship the MIT/BSD license in this case. (Perhaps, it would be good to revisit the part of the policy that discussed shipping license texts and consider, why is that required: It is in order to honor upstream licenses, or for some other reason, like end user convenience?)
All the licenses are shipped in that they are found in the SRPM. Implicitly, Fedora's position is that this is compliant with those permissive licenses. I think the issue you're raising is Fedora's policy on what license texts to install in /usr/share/licenses. I don't think that issue is directly tied to how the License: field is populated. I couldn't immediately find any documentation on the /usr/share/licenses policy, but my intuition from looking at lots of Fedora and RHEL packages is that this contains any license text that seems to be "global" in some way, and in cases where there is no obvious such license, some appropriate license is selected from the source files for this purpose. We might want to separately revisit the /usr/share/licenses policy at some point if there is interest.
Yes, I was talking about installed license texts. I brought it up because it is part of the Licensing Guidelines, in section License Text [1]. If the purpose of the current effort is just to upgrade the License identifiers, then it is out of scope as you say.
Anyhow, the License Text section seems to imply that the only allowed method of shipping the license is to install it as part of the binary package:
" However, in situations where upstream is unresponsive, unable, or unwilling to provide proper full license text as part of the source code, and the indicated license requires that the full license text be included, Fedora Packagers must either:
* Include a copy of what they believe the license text is intended to be, as part of the Fedora package in %license, in order to remain in compliance.
* Choose not to package that software for Fedora. "
Adding the missing license as a new Source: would push it to srpm, but would violate the above rule, which is written as a MUST.
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline...
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
I personally favor the suggestion to move to a more mechanical construction of license expressions. While I appreciate the convenience of simple license expressions, I think that, with so many possible combinations of source licenses, usefully and reliably combining licenses under the “effective license” theory has required too much undocumented knowledge and/or amateur legal analysis.
I am curious whether or not this would be accompanied by any changes to the requirements for documenting the license breakdown in multiple licensing scenarios[1].
– Ben Beasley
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline...
On Mon, Jun 6, 2022, at 3:33 PM, Richard Fontana wrote:
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
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
On 6/06/2022 21:33, Richard Fontana wrote:
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.
As a relatively new packager, the License: field has always been a bit confusing to me (it doesn't help that many projects don't include the license files of libraries...). I liked the effective license approach (although it's confusing and not easy to compute) because otherwise the license field would look like a confusing mess for some packages. For example moolticute [0], with the new approach (please correct me if I'm wrong) the license field would be: "License: GPLv3+ and GPLv3 and MIT and BSD and CC-BY". This isn't representative of the license of the Moolticute project (which is GPLv3+).
I think the policy depends on what the goal of the license field is. I didn't exactly know what the goal was to be honest, but Neal described it earlier as:
The point of the License tag in Fedora is to provide good guidance on leveraging the software.
I'm not sure that listing all licenses that end up in the binary rpm accomplished this goal. But I agree that the current situation isn't ideal, and I'm not sure what the best solution is.
[0]: https://src.fedoraproject.org/rpms/moolticute/blob/rawhide/f/moolticute.spec...
V Thu, Jun 09, 2022 at 06:47:58PM +0200, Arthur Bols napsal(a):
As a relatively new packager, the License: field has always been a bit confusing to me (it doesn't help that many projects don't include the license files of libraries...). I liked the effective license approach (although it's confusing and not easy to compute) because otherwise the license field would look like a confusing mess for some packages. For example moolticute [0],
From the spec file:
# The entire source code is GPLv3+ except: # src/AnsiEscapeCodeHandler.[cpp|h] which is GPLv3, # src/QtAwesome/QtAwesome/ src/http-parser/ and src/qtcsv which are MIT, # src/QtAwesome/QtAwesome/fonts/ which is CC-BY, # src/CyoEncode/ src/SimpleCrypt/ and src/zxcvbn-c/ which are BSD.
with the new approach (please correct me if I'm wrong) the license field would be: "License: GPLv3+ and GPLv3 and MIT and BSD and CC-BY". This isn't representative of the license of the Moolticute project (which is GPLv3+).
Maybe it's not what Moolticute project claims, but it's correct. If Moolticute project bundles the font which is not GPLv3+, but CC-BY, and does not say so, then the project's claim is incorrect.
CC-BY has distinct requirements from GPLv3+. E.g. it requires you to carry a copy of the CC-BY license text, or https://creativecommons.org/licenses/by/4.0/legalcode URI. If you don't do so, you violate CC-BY.
Now to the License tag of the binary RPM package: /usr/bin/moolticute contains a copy of src/QtAwesome/QtAwesome/fonts/fontawesome-4.6.1.ttf (grep for "DDhg-iW" string). Hence you need to list a license of that font file in the License tag. RPM License tag is not about servility to upstream projects. It's about providing accurate license data. You should not copy mistakes of the upstream.
Now to the actual license of fontawesome-4.6.1.ttf. I briefely looked at it and the only information about a license I found is this text with fontforge tool on that file:
Fullname: FontAwesome Regular License URL: http://fontawesome.io/license/
A text on that License URL web page is about "Font Awesome Pro" and the license is not CC-BY. The same page also menitions a different product with a different license called "Font Awesome Free" https://fontawesome.com/license/free which claims SIL Open Font License 1.1 (OFL). But a git repository for that Free font https://github.com/FortAwesome/Font-Awesome notes that version 4 is obsolete and replaced with version 6. History of the git repository does not contain version 4.
How did you come to a conclusion that the font is CC-BY? In my opinion it could be OFL, if it were Font Awesome Free.
-- Petr
On 10/06/2022 09:19, Petr Pisar wrote:
Maybe it's not what Moolticute project claims, but it's correct. If Moolticute project bundles the font which is not GPLv3+, but CC-BY, and does not say so, then the project's claim is incorrect.
The license for QtAwesome is contained in the repo, so it is mentioned.
Now to the License tag of the binary RPM package: /usr/bin/moolticute contains a copy of src/QtAwesome/QtAwesome/fonts/fontawesome-4.6.1.ttf (grep for "DDhg-iW" string). Hence you need to list a license of that font file in the License tag. RPM License tag is not about servility to upstream projects. It's about providing accurate license data. You should not copy mistakes of the upstream.
I don't think upstream is making a mistake (except when license files for included libraries are missing). When someone creates a FOSS project, they choose a license. They should check that all libraries are compatible with that license, but I don't agree that it is a mistake that there isn't a license breakdown in the repo. The license is normally (and should be) mentioned at the top of the library files themselves, or somewhere in the library directory.
How did you come to a conclusion that the font is CC-BY? In my opinion it could be OFL, if it were Font Awesome Free.
I guess due to licensecheck, but I don't recall. The license should be OFL as mentioned in the LICENSE file [0]. I'll correct the mistake next release.
But I don't think this specific package and project is the topic of this thread. It was given as an example to explain my point of view.
[0]: https://github.com/mooltipass/moolticute/blob/master/src/QtAwesome/LICENSE.m...
V Fri, Jun 10, 2022 at 11:27:27AM +0200, Arthur Bols napsal(a):
On 10/06/2022 09:19, Petr Pisar wrote:
Maybe it's not what Moolticute project claims, but it's correct. If Moolticute project bundles the font which is not GPLv3+, but CC-BY, and does not say so, then the project's claim is incorrect.
The license for QtAwesome is contained in the repo, so it is mentioned.
It's not in the tar ball which upstream distributes to Fedora.
Now to the License tag of the binary RPM package: /usr/bin/moolticute contains a copy of src/QtAwesome/QtAwesome/fonts/fontawesome-4.6.1.ttf (grep for "DDhg-iW" string). Hence you need to list a license of that font file in the License tag. RPM License tag is not about servility to upstream projects. It's about providing accurate license data. You should not copy mistakes of the upstream.
I don't think upstream is making a mistake (except when license files for included libraries are missing). When someone creates a FOSS project, they choose a license. They should check that all libraries are compatible with that license, but I don't agree that it is a mistake that there isn't a license breakdown in the repo. The license is normally (and should be) mentioned at the top of the library files themselves, or somewhere in the library directory.
That's everything fine. (Although there are licenses which explicitly require mentioning a license disclaimer in every piece of documentation.) But this not case of v0.55.0.tar.gz. It does not contain a word about a license of the font. A recipient of the tar ball gets a wrong impression that GPLv3 agreement is the only set of requirement he needs to fulfill. And that's not true. He also needs to fullfill requirements of the the license of the font.
How did you come to a conclusion that the font is CC-BY? In my opinion it could be OFL, if it were Font Awesome Free.
I guess due to licensecheck, but I don't recall. The license should be OFL as mentioned in the LICENSE file [0]. I'll correct the mistake next release.
But I don't think this specific package and project is the topic of this thread. It was given as an example to explain my point of view.
Why isn't this LICENSE.md file in the tar ball, or Fedora dist-git? You should add it there as well as a copy of OFL. OFL has very similar requirment as CC-BY:
2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. These can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user.
This specific package is very relevant to this thread: It demonstrates the very same problem. Upstream thinks that not putting a license text into the tar ball is fine. And you think that not declaring the missing license in License tag is fine. And you argue with effective licensing.
But that's not how licensing works. If you have a file whose license requires forwarding the license text (like OFL), then simply each participant in the chain of distribution must do it. And a fact that the license is "compatible" with GPLv3 has no effect on it. Technically it isn't compatible. GPLv3 does not mandate carrying OFL text. Hence once you combine GPLv3 and OFL code, you need to forward OFL text forever. An idea that a license overlays another one is not generally true. It always depends on the specific license.
And that's the community effective licensing cult Mr. Fontana discourages and instead recommends listing all the licenses in the RPM tag. Because people does not understand it make does the effective simplification incorrectly.
-- Petr
On 10/06/2022 13:20, Petr Pisar wrote:
That's everything fine. (Although there are licenses which explicitly require mentioning a license disclaimer in every piece of documentation.) But this not case of v0.55.0.tar.gz. It does not contain a word about a license of the font.
The src/QtAwesome/LICENSE.md is contained in the v0.55.0.tar.gz which explicitly states:
The Font Awesome font is licensed under the SIL Open Font License
The OFL license itself is missing though, I will ask upstream to include it.
Why isn't this LICENSE.md file in the tar ball, or Fedora dist-git? You should add it there as well as a copy of OFL. OFL has very similar requirment as CC-BY:
2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. These can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user.
Since we're expanding on this specific package (the license documentation should be substantially improved in this regard), how would you deal with the "the above copyright notice" issue? In the Moolticute project, there are multiple libraries with different licenses and different copyright notices. Most licenses state that the copyright notice must be included. For example, src/CyoEncode and src/SimpleCrypt are both BSD (to be completely accurate: the former is 2-clause, the latter 3-clause), but they have different copyright notices. The license is included in the source itself, so upstream is correct. How should packagers deal with this? Do they have to extract the license from every file and call them for example "LICENSE.CyoEncode" and "LICENSE.SimpleCrypt" and include those in dist-git?
This specific package is very relevant to this thread: It demonstrates the very same problem. Upstream thinks that not putting a license text into the tar ball is fine. And you think that not declaring the missing license in License tag is fine. And you argue with effective licensing.
Let me be clear, I agree that licenses are important and they should be included in the rpm. I viewed the license field as something different, which is why I preferred the "effective" license. New packagers have a very steep learning curve. It doesn't help that licensing is a complicated and sensitive matter. The current documentation just isn't clear enough (at least for me) on how to deal with it. That the licenses aren't included is a mistake on my part as this was my first package. I am not arguing what is better or worse, since I feel like I don't have enough experience, I'm trying get a better understanding of what and why.
And that's the community effective licensing cult Mr. Fontana discourages and instead recommends listing all the licenses in the RPM tag. Because people does not understand it make does the effective simplification incorrectly.
I understand where you're coming from, but calling it a cult is not necessary.
V Fri, Jun 10, 2022 at 02:51:03PM +0200, Arthur Bols napsal(a):
On 10/06/2022 13:20, Petr Pisar wrote:
That's everything fine. (Although there are licenses which explicitly require mentioning a license disclaimer in every piece of documentation.) But this not case of v0.55.0.tar.gz. It does not contain a word about a license of the font.
The src/QtAwesome/LICENSE.md is contained in the v0.55.0.tar.gz which explicitly states:
The Font Awesome font is licensed under the SIL Open Font License
I see. I overlooked this file. I saw only the top-level ./LICENSE. I'm sorry.
The OFL license itself is missing though, I will ask upstream to include it.
Why isn't this LICENSE.md file in the tar ball, or Fedora dist-git? You should add it there as well as a copy of OFL. OFL has very similar requirment as CC-BY:
2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. These can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user.
Since we're expanding on this specific package (the license documentation should be substantially improved in this regard), how would you deal with the "the above copyright notice" issue? In the Moolticute project, there are multiple libraries with different licenses and different copyright notices. Most licenses state that the copyright notice must be included. For example, src/CyoEncode and src/SimpleCrypt are both BSD (to be completely accurate: the former is 2-clause, the latter 3-clause), but they have different copyright notices. The license is included in the source itself, so upstream is correct. How should packagers deal with this? Do they have to extract the license from every file and call them for example "LICENSE.CyoEncode" and "LICENSE.SimpleCrypt" and include those in dist-git?
Basically yes. You are on the right track. If a license requires for binary distributions to deliver the texts, then the packager needs to extract them (they are often called license declarations or license headers or copyright disclaimers) and store them into the binary RPM package using %license macro. You can do it manually and save them into dist-git, or you can use some kind of sed script in the spec file to collect all lines from " * Copyright (c)" to " * OF THIS SOFTWARE" lines. You can deduplicate identical pieces if you want. Of course the scripted method is prone to aging and it should be verified from time to time that it still works. Here very helps if upstream keeps the license declarations identical. Then the packager only needs to copy one, usually the top-level LICENSE file. If you have an Android phone, go to settings and somewhere deep there is a very long web page with all these license declarations.
Of course there are people who claim that it's tedious and too demanding and a user can download and unpack source RPM if he wants to see the license. But I believe the license intention is to have the texts available next to the binaries.
Therefore GPL recommends programmers to have a feature in their code to show the license declaration. This alleviates packager's life.
For the very same reason I'm not fond of writing license declarations into each source file. I prefer keeping only a single instance in LICENSE or README file.
This specific package is very relevant to this thread: It demonstrates the very same problem. Upstream thinks that not putting a license text into the tar ball is fine. And you think that not declaring the missing license in License tag is fine. And you argue with effective licensing.
Let me be clear, I agree that licenses are important and they should be included in the rpm. I viewed the license field as something different, which is why I preferred the "effective" license. New packagers have a very steep learning curve. It doesn't help that licensing is a complicated and sensitive matter. The current documentation just isn't clear enough (at least for me) on how to deal with it. That the licenses aren't included is a mistake on my part as this was my first package. I am not arguing what is better or worse, since I feel like I don't have enough experience, I'm trying get a better understanding of what and why.
No problem. I agree that the Fedora guidelines are not exact enough regarding to packaging the licenses. At the beginning of my packaging experience I also preferred the effective approach. But after years of contact with various licenses, I changed my mind. Keeping a spirit of a license is off doubts. But why a part of a license specifying what I can do with the code should be more important than another part of the license specifying what I have to do with the license text? If they are equal, then the effective simplification should not overlook the other aspect. And thus should be equally good reason why to keep the license listed in the License tag.
On the other hand, I understand that the overlong, complicated License tag is not much appeling to the users and that it is laborious for packages. That's probably the reason why the guidelines keep a silent status quo. At the end the License tag is nothing the licenses require us to maintain. It's just an additional value Fedora provides its users.
-- Petr
On Fri, Jun 10, 2022 at 04:08:08PM +0200, Petr Pisar wrote:
At the end the License tag is nothing the licenses require us to maintain. It's just an additional value Fedora provides its users.
This is an excellent way to look at the question. We should do what provides the most value -- while being reasonable for packagers as well.
packaging@lists.fedoraproject.org