https://bugzilla.redhat.com/show_bug.cgi?id=1985620 --- Comment #6 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- > I'd prefer to have this specific package compatible with EPEL8. I think %python_provide is acceptable for this reason, although since it has slightly different semantics and “SHOULD NOT” be used in Fedora (https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/), I think surrounding it with version conditionals (%if %{?el8}/%endif or similar) is ideal. (However, Fedora is full of packages that still use %python_provide, and it certainly isn’t causing any problems that I know of.) > I think it is fine for the time being… Esp. if upstream is not very responsive. > As far as I know, this is not correct. It's not up the packager to just "guess" which license text is applicable. This is not what the guidelines say for licenses that require the text to be included, of which ASL 2.0 is one. My summary applies to this situation, and not to the general case; e.g. for missing license text in a GPLv2+ package, reporting it upstream and moving on would be adequate under the same guidelines. I’ve quoted the relevant section below. https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text > In cases where the upstream has chosen a license that requires that a copy of the license text be distributed along with the binaries and/or source code, but does not provide a copy of the license text (in the source tree, or in some rare cases, anywhere), the packager should do their best to point out this confusion to upstream. This sometimes occurs when an upstream project’s only reference to a license is in a README (where they simply say "licensed under the FOO license"), on their website, or when they simply do not check a copy of the license into their Source tree. Common licenses that require including their texts with all derivative works include ASL 2.0, EPL, BSD and MIT. Packagers should point out to upstream that by not including a proper full license text, they are making it difficult or impossible for anyone to comply with their desired license terms. > > 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. It is worth noting that this may place some additional risk on the packager, however, Fedora believes that this risk is minimized by the fact that if the upstream disagrees with what we have distributed as the full license text, they can easily remedy this by making full license text available in the source code. Packagers who choose to do this should ensure that they have exhausted all attempts to work with upstream to include the license text as part of the source code, or at least, to confirm the full license text explicitly with the upstream, as this minimizes the risk on the packager. Packagers should also take copies of license texts from reliable and canonical sources (such as the Fedora Software Licenses page, the FSF licenses page, or the OSI license list), whenever possible. > • Choose not to package that software for Fedora. > > It is important to reiterate that in situations where the indicated license does not imply a requirement that the license be distributed along with the source/binaries, Fedora packagers are NOT required to manually include the full license text when it is absent from the source code. but are still encouraged to point out this issue to upstream and encourage them to remedy it. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
