Re: SPDX Statistics - Dvořák Edition
Dne 27. 09. 24 v 4:27 odp. Karolina Surma napsal(a): I second Ben's findings, all of my packages have been migrated with a commit message saying "Review the License tag according to the SPDX standard" and with an added "# SPDX" comment if there was no change of the string. The automation should not report any of those. I run the script over night. It removed lots of reported package with lines warning: valid as old and new and no changelong entry, please check I git-pushed it. You can check it again. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Dvořák Edition
Dne 27. 09. 24 v 4:01 odp. Ben Beasley napsal(a): The list of packages without SPDX, packages-without-spdx-final-maintainers.txt, seems suspicious. It has quite a few packages I maintain that seem perfectly fine to me. NiaAML-GUI has: # SPDX License: MIT and a commit/changelog in its history entitled “Clarify that License is SPDX MIT”. The reasons are in the first file: https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt for NiaAML-GUI it states: |> NiaAML-GUI warning: valid as old and new and no changelong entry, please check hmm... you are right, I had a error in my script in detection of dist-git changelog. Next time it will not be reported. | -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Dvořák Edition
> > NiaAML-GUI warning: valid as old and new and no changelong entry, please > > check python-funcparserlib was probably still showing up for the same reason, I just went through a review again and this time added a changelog entry. Dridi -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Dvořák Edition
I second Ben's findings, all of my packages have been migrated with a commit message saying "Review the License tag according to the SPDX standard" and with an added "# SPDX" comment if there was no change of the string. The automation should not report any of those. Karolina On 9/27/24 16:01, Ben Beasley wrote: The list of packages without SPDX, packages-without-spdx-final-maintainers.txt, seems suspicious. It has quite a few packages I maintain that seem perfectly fine to me. NiaAML-GUI has: # SPDX License: MIT and a commit/changelog in its history entitled “Clarify that License is SPDX MIT”. atomic-queue has: # SPDX License: MIT and a commit/changelog in its history entitled “Confirm that License is SPDX MIT (no License field change)”. The situation for all of the following packages is the same in every detail as for NiaAML-GUI and atomic-queue: c4fs, c4log, e00compr, earcut-hpp, eot-utils, gulrak-filesystem, hatch, jello, libdeflate, pipx, pre-commit, pyshp, python-Rtree, python-docx, python-editables, python-email-validator except for slight differences in the commit/changelog messages – and that earcut-hpp is ISC instead of MIT, eot-utils is W3C, python-cyipopt is EPL-2.0, and python-email-validator is Unlicense. Is it possible that your tools are reporting every package that has a SPDX license expression that is also valid in the old Callaway system as not converted? That’s something all of these packages seem to have in common. On the other hand, I found at least one package that did not fit this pattern: python-cmake-build-extension has: License: MIT AND BSD-3-Clause I gave up checking after python-email-validator, alphabetically speaking. There were too many false positives in the list for me to check them all. On 9/27/24 5:49 AM, Miroslav Suchý wrote: Hot news: - I am going through "neither Callaway nor SPDX" license formulas. I submitted dozens PR for your packages. And beside obvious typos or partial conversion I see cases where maintainers use SPDX id of license. This is not enough the license id must have SPDX id **and** must be on fedora-license-data list. If you do not see the license on https://docs.fedoraproject.org/en-US/legal/all-allowed/ (or it does not pass `license-validate` test) then please open issue against fedora-license-data at https://gitlab.com/fedora/legal/fedora-license-data - when your package has in license string LicenseRef-Callaway-* then rpmlint and rpminspect will complain about it. While reverting the string silence these linter (for now) the correct way is to correctly identify SPDX id. Best way is to $ sudo dnf install scancode-toolkit $ fedpkg clone $PACKAGE $ cd $PACKAGE $ fedpkg prep $ cd $ARCHIVEDIR $ scancode --license --license-references --html /tmp/scan.html -n8 . && firefox /tmp/scan.html - We had a meeting with Garry O'Neal from SPDX who introduced to variety of tools he is using for license scanning. We would love to deploy fossology in Fedora infrastructure to ease your license scanning. Two weeks ago we had: * 24376spec files in Fedora * 31002license tags in all spec files * 5970 tags have not been converted to SPDX yet * 188 tags can be trivially converted using `license-fedora2spdx` * Progress: 81,24% ██100% ELN subset: 142 out of 2322 packages are not converted yet (progress 93.88%) Today we have: * 24426spec files in Fedora * 31052license tags in all spec files * 5918 tags have not been converted to SPDX yet * 181 tags can be trivially converted using `license-fedora2spdx` * Progress: 81,11% ██100% ELN subset: 140 out of 2325 packages are not converted yet (progress 93.98%) Graph of these data with the burndown chart: https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing The list of packages needed to be converted is here: https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt List by package maintainers is here https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt Packages that are neither in SPDX nor in Callaway format (highest priority for now): https://pagure.io/copr/license-validate/blob/main/f/neither-nor-remaining-packagers.txt New version of fedora-license-data has been released. With: 5 new licenses 7 licenses are waiting to be reviewed by SPDX.org (and then to be added to fedora-license-data) https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B%5D=SPDX%3A%3Ablocked Legal docs and especially https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ was updated too. New projection when we will be finished is 2025-03-27 (+17 days from last report). Pure linear approximation. If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license tag ma
Re: SPDX Statistics - Dvořák Edition
The list of packages without SPDX, packages-without-spdx-final-maintainers.txt, seems suspicious. It has quite a few packages I maintain that seem perfectly fine to me. NiaAML-GUI has: # SPDX License: MIT and a commit/changelog in its history entitled “Clarify that License is SPDX MIT”. atomic-queue has: # SPDX License: MIT and a commit/changelog in its history entitled “Confirm that License is SPDX MIT (no License field change)”. The situation for all of the following packages is the same in every detail as for NiaAML-GUI and atomic-queue: c4fs, c4log, e00compr, earcut-hpp, eot-utils, gulrak-filesystem, hatch, jello, libdeflate, pipx, pre-commit, pyshp, python-Rtree, python-docx, python-editables, python-email-validator except for slight differences in the commit/changelog messages – and that earcut-hpp is ISC instead of MIT, eot-utils is W3C, python-cyipopt is EPL-2.0, and python-email-validator is Unlicense. Is it possible that your tools are reporting every package that has a SPDX license expression that is also valid in the old Callaway system as not converted? That’s something all of these packages seem to have in common. On the other hand, I found at least one package that did not fit this pattern: python-cmake-build-extension has: License: MIT AND BSD-3-Clause I gave up checking after python-email-validator, alphabetically speaking. There were too many false positives in the list for me to check them all. On 9/27/24 5:49 AM, Miroslav Suchý wrote: Hot news: - I am going through "neither Callaway nor SPDX" license formulas. I submitted dozens PR for your packages. And beside obvious typos or partial conversion I see cases where maintainers use SPDX id of license. This is not enough the license id must have SPDX id **and** must be on fedora-license-data list. If you do not see the license on https://docs.fedoraproject.org/en-US/legal/all-allowed/ (or it does not pass `license-validate` test) then please open issue against fedora-license-data at https://gitlab.com/fedora/legal/fedora-license-data - when your package has in license string LicenseRef-Callaway-* then rpmlint and rpminspect will complain about it. While reverting the string silence these linter (for now) the correct way is to correctly identify SPDX id. Best way is to $ sudo dnf install scancode-toolkit $ fedpkg clone $PACKAGE $ cd $PACKAGE $ fedpkg prep $ cd $ARCHIVEDIR $ scancode --license --license-references --html /tmp/scan.html -n8 . && firefox /tmp/scan.html - We had a meeting with Garry O'Neal from SPDX who introduced to variety of tools he is using for license scanning. We would love to deploy fossology in Fedora infrastructure to ease your license scanning. Two weeks ago we had: * 24376spec files in Fedora * 31002license tags in all spec files * 5970 tags have not been converted to SPDX yet * 188 tags can be trivially converted using `license-fedora2spdx` * Progress: 81,24% ██100% ELN subset: 142 out of 2322 packages are not converted yet (progress 93.88%) Today we have: * 24426spec files in Fedora * 31052license tags in all spec files * 5918 tags have not been converted to SPDX yet * 181 tags can be trivially converted using `license-fedora2spdx` * Progress: 81,11% ██100% ELN subset: 140 out of 2325 packages are not converted yet (progress 93.98%) Graph of these data with the burndown chart: https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing The list of packages needed to be converted is here: https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt List by package maintainers is here https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt Packages that are neither in SPDX nor in Callaway format (highest priority for now): https://pagure.io/copr/license-validate/blob/main/f/neither-nor-remaining-packagers.txt New version of fedora-license-data has been released. With: 5 new licenses 7 licenses are waiting to be reviewed by SPDX.org (and then to be added to fedora-license-data) https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B%5D=SPDX%3A%3Ablocked Legal docs and especially https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ was updated too. New projection when we will be finished is 2025-03-27 (+17 days from last report). Pure linear approximation. If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license tag matches SPDX formula, you can put your package on ignore list https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt Either pull-request or direct email to me is fine. Why Dvořák edition? Because on today's date at 1892 Czech composer Antonín Dvořák arrived on steam boat to New York per request of Je
