I’m aware that pyproject-rpm-macros can handle license files in many cases[1]:
%pyproject_save_files can automatically mark license files with %license macro and language (*.mo) files with %lang macro and appropriate language code. Only license files declared via PEP 639 License-Field field are detected. PEP 639 is still a draft and can be changed in the future.
(I also know that there are some packages where no license file is marked, or where additional license files are needed, and it’s best to verify with “rpm -qL -p …” before relying on this feature. That’s not at issue here.)
In a package review, it was suggested that, even when pyproject_files includes a license file installed in the dist-info directory and marked with %license, an explicit installation of the license file with a relative path, such as
%license LICENSE.txt
might still be needed—under the theory that the license file is supposed to be installed in /usr/share/licenses.
The Licensing Guidelines simply say that %license must be used, and don’t mention /usr/share/licenses[2].
I’m wondering if this question has come up before and if anyone has insight into whether or not pyproject-rpm-macros’s license file support is intended to replace manual license file handling.
– Ben Beasley
[1] https://src.fedoraproject.org/rpms/pyproject-rpm-macros [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuideline...
On 24. 12. 21 1:57, Ben Beasley wrote:
I’m aware that pyproject-rpm-macros can handle license files in many cases[1]:
%pyproject_save_files can automatically mark license files with %license macro and language (*.mo) files with %lang macro and appropriate language code. Only license files declared via PEP 639 License-Field field are detected. PEP 639 is still a draft and can be changed in the future.
(I also know that there are some packages where no license file is marked, or where additional license files are needed, and it’s best to verify with “rpm -qL -p …” before relying on this feature. That’s not at issue here.)
In a package review, it was suggested that, even when pyproject_files includes a license file installed in the dist-info directory and marked with %license, an explicit installation of the license file with a relative path, such as
%license LICENSE.txt
might still be needed—under the theory that the license file is supposed to be installed in /usr/share/licenses.
This assumption is not true. I even recall asking somewhere wrt Python's license file:
https://src.fedoraproject.org/rpms/python3.9/c/ff90d23b8f5d2b721aa55289d69cf...
But I don't recall where. Might have been this list or legal.
The Licensing Guidelines simply say that %license must be used, and don’t mention /usr/share/licenses[2].
I’m wondering if this question has come up before and if anyone has insight into whether or not pyproject-rpm-macros’s license file support is intended to replace manual license file handling.
It is intended to replace manual license file handling but the result is only as good as the upstream metadata.
On 24. 12. 21 10:05, Miro Hrončok wrote:
On 24. 12. 21 1:57, Ben Beasley wrote:
I’m aware that pyproject-rpm-macros can handle license files in many cases[1]:
%pyproject_save_files can automatically mark license files with %license macro and language (*.mo) files with %lang macro and appropriate language code. Only license files declared via PEP 639 License-Field field are detected. PEP 639 is still a draft and can be changed in the future.
(I also know that there are some packages where no license file is marked, or where additional license files are needed, and it’s best to verify with “rpm -qL -p …” before relying on this feature. That’s not at issue here.)
In a package review, it was suggested that, even when pyproject_files includes a license file installed in the dist-info directory and marked with %license, an explicit installation of the license file with a relative path, such as
> %license LICENSE.txt
might still be needed—under the theory that the license file is supposed to be installed in /usr/share/licenses.
This assumption is not true. I even recall asking somewhere wrt Python's license file:
https://src.fedoraproject.org/rpms/python3.9/c/ff90d23b8f5d2b721aa55289d69cf...
But I don't recall where. Might have been this list or legal.
Here:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
On Fri, Dec 24, 2021 at 10:05:26AM +0100, Miro Hrončok wrote:
%license LICENSE.txt
might still be needed—under the theory that the license file is supposed to be installed in /usr/share/licenses.
This assumption is not true. I even recall asking somewhere wrt Python's license file:
[...]
The Licensing Guidelines simply say that %license must be used, and don’t mention /usr/share/licenses[2].
Since the license tag is My Fault™, and it was a long time ago, some background just for the sake of keeping our collective memory refreshed, the main purpose of the %license tag as distinct from %doc is to make sure that when packages are installed without docs (possibly in containers or other minimal-footprint situations), the license is still included, as many of them require that.
As a bonus, we could theoretically change the behavior to de-dupe, or even do complicated things like only install the license files which require it when nodoc is used. That's not generally been worth bothering, but I do notice that /usr/share/license takes up 44MB on my desktop system, so... there's room to shrink. (Using jdupes, I found this is 13.32MiB "exclusive" with btrfs.)
For reference: https://pagure.io/packaging-committee/issue/411
On Fri, Dec 24, 2021 at 12:31 PM Matthew Miller mattdm@fedoraproject.org wrote:
As a bonus, we could theoretically change the behavior to de-dupe, or even do complicated things like only install the license files which require it when nodoc is used. That's not generally been worth bothering, but I do notice that /usr/share/license takes up 44MB on my desktop system, so... there's room to shrink. (Using jdupes, I found this is 13.32MiB "exclusive" with btrfs.)
For reference: https://pagure.io/packaging-committee/issue/411
I assume that the comments there about hardlinking are still accurate. A long time ago I suggested that Fedora consider adopting what I understand the Debian convention to be, which is to have a single copy of several widely used license files in a directory called /usr/share/common-licenses, referenced as needed from a per-package debian/copyright file. From a license compliance standpoint the Debian approach has some merit.
Richard
On Fri, Dec 24, 2021 at 02:33:49PM -0500, Richard Fontana wrote:
For reference: https://pagure.io/packaging-committee/issue/411
I assume that the comments there about hardlinking are still accurate.
That we could do it but aren't? Yes.
A long time ago I suggested that Fedora consider adopting what I understand the Debian convention to be, which is to have a single copy of several widely used license files in a directory called /usr/share/common-licenses, referenced as needed from a per-package debian/copyright file. From a license compliance standpoint the Debian approach has some merit.
Perhaps the SPDX effort provides a good point to look at that idea again.
Hi,
Matthew Miller mattdm@fedoraproject.org writes:
On Fri, Dec 24, 2021 at 02:33:49PM -0500, Richard Fontana wrote:
For reference: https://pagure.io/packaging-committee/issue/411
I assume that the comments there about hardlinking are still accurate.
That we could do it but aren't? Yes.
A long time ago I suggested that Fedora consider adopting what I understand the Debian convention to be, which is to have a single copy of several widely used license files in a directory called /usr/share/common-licenses, referenced as needed from a per-package debian/copyright file. From a license compliance standpoint the Debian approach has some merit.
Perhaps the SPDX effort provides a good point to look at that idea again.
Why are we not using the SPDX license identifiers in our spec files, this would simplify deduplicating licenses tremendously?
Hi,
Matthew Miller mattdm@fedoraproject.org writes:
On Fri, Dec 24, 2021 at 02:33:49PM -0500, Richard Fontana wrote:
For reference: https://pagure.io/packaging-committee/issue/411
I assume that the comments there about hardlinking are still accurate.
That we could do it but aren't? Yes.
A long time ago I suggested that Fedora consider adopting what I understand the Debian convention to be, which is to have a single copy of several widely used license files in a directory called /usr/share/common-licenses, referenced as needed from a per-package debian/copyright file. From a license compliance standpoint the Debian approach has some merit.
Perhaps the SPDX effort provides a good point to look at that idea again.
Why are we not using the SPDX license identifiers in our spec files, this would simplify deduplicating licenses tremendously?
On Sun, Dec 26, 2021 at 06:31:41AM +0100, Dan Čermák wrote:
Perhaps the SPDX effort provides a good point to look at that idea again.
Why are we not using the SPDX license identifiers in our spec files, this would simplify deduplicating licenses tremendously?
This is indeed planned. Work in progress here:
https://pagure.io/packaging-committee/pull-request/1142
Dne 24. 12. 21 v 20:33 Richard Fontana napsal(a):
On Fri, Dec 24, 2021 at 12:31 PM Matthew Miller mattdm@fedoraproject.org wrote:
As a bonus, we could theoretically change the behavior to de-dupe, or even do complicated things like only install the license files which require it when nodoc is used. That's not generally been worth bothering, but I do notice that /usr/share/license takes up 44MB on my desktop system, so... there's room to shrink. (Using jdupes, I found this is 13.32MiB "exclusive" with btrfs.)
For reference: https://pagure.io/packaging-committee/issue/411
I assume that the comments there about hardlinking are still accurate. A long time ago I suggested that Fedora consider adopting what I understand the Debian convention to be, which is to have a single copy of several widely used license files in a directory called /usr/share/common-licenses, referenced as needed from a per-package debian/copyright file. From a license compliance standpoint the Debian approach has some merit.
Richard
Actually, why not start with such package today and have (over the time) all approved (or even unapproved) licenses there? Certainly, if question about some license pops up today, it could be added to such package right away and later some BRP script could deduplicate such license files (or fail the build if there is unapproved license identified). This could be done gradually, as time permits or as new/old licenses are reviewed.
Vít
packaging@lists.fedoraproject.org