• Bug#1102363: licensecheck: Exclusivly check for SPDX fields / Ignore ev

    From Christian Buhtz@21:1/5 to All on Tue Apr 8 11:10:01 2025
    Package: licensecheck
    Severity: wishlist

    Hello,

    if covering/parsing SPDX meta data is implemented (#960665) please make sure to ignore all other licenses strings.

    Let me provide you some real world problem where this would be important and also save resources of Debian package maintainers.

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960665

    The "problem" here is that the whole project does offer SPDX meta data and "reuse lint" is green on all files, which means the project is SPDX conform.

    But one file "serviceHelper.py" does have comments about the license
    history of that file. Some other licenses are named just of historical
    reasons. License checker does consider that strings, too. That is the problem.

    This is a follow-up from: <https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=960665#36>

    Regards,
    Christian Buhtz


    -- System Information:
    Debian Release: trixie/sid
    APT prefers testing
    APT policy: (500, 'testing')
    Architecture: arm64 (aarch64)

    Kernel: Linux 6.12.20-arm64 (SMP w/4 CPU threads)
    Kernel taint flags: TAINT_CRAP
    Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
    Shell: /bin/sh linked to /usr/bin/dash
    Init: systemd (via /run/systemd/system)
    LSM: AppArmor: enabled

    Versions of packages licensecheck depends on:
    pn libfeature-compat-class-perl <none>
    pn libfeature-compat-try-perl <none>
    pn libio-interactive-perl <none>
    pn liblog-any-adapter-screen-perl <none>
    pn liblog-any-perl <none>
    pn libnamespace-clean-perl <none>
    pn libpath-iterator-rule-perl <none>
    pn libpath-tiny-perl <none>
    pn libpod-constants-perl <none>
    pn libstring-copyright-perl <none>
    pn libstring-escape-perl <none>
    pn libstring-license-perl <none>
    ii perl 5.40.1-2

    Versions of packages licensecheck recommends:
    pn libregexp-pattern-license-perl <none>

    Versions of packages licensecheck suggests:
    pn bash-completion <none>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonas Smedegaard@21:1/5 to All on Tue Apr 8 12:50:01 2025
    Quoting Christian Buhtz (2025-04-08 10:59:33)
    if covering/parsing SPDX meta data is implemented (#960665) please make sure to
    ignore all other licenses strings.

    Let me provide you some real world problem where this would be important and also save resources of Debian package maintainers.

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960665

    The "problem" here is that the whole project does offer SPDX meta data and "reuse lint" is green on all files, which means the project is SPDX conform.

    But one file "serviceHelper.py" does have comments about the license
    history of that file. Some other licenses are named just of historical reasons. License checker does consider that strings, too. That is the problem.

    Thanks for your bugreport. I have reframed it as an option (rather than
    a default goal):

    support excluding formats e.g. to only check for SPDX fields

    Do you agree that this covers the point of this issue?

    Kind regards,

    - Jonas

    --
    * Jonas Smedegaard - idealist & Internet-arkitekt
    * Tlf.: +45 40843136 Website: http://dr.jones.dk/
    * Sponsorship: https://ko-fi.com/drjones

    [x] quote me freely [ ] ask before reusing [ ] keep private

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From c.buhtz@posteo.jp@21:1/5 to All on Tue Apr 8 13:40:01 2025
    Hello Jonas,

    thanks for asking back.

    Am 08.04.2025 12:44 schrieb Jonas Smedegaard:
    I have reframed it as an option (rather than
    a default goal):

    support excluding formats e.g. to only check for SPDX fields

    Do you agree that this covers the point of this issue?

    Kind of. Yes. ;)

    But I would still argument that it should be default behavior of
    licensecheck, to not looking for other formats if SPDX is provided.
    Checking for SPDX and other formats at the same time/file would
    contradict the goal of SPDX.

    If authors using SPDX and extra license information on purpose they are
    using SPDX the wrong way.

    So doing it my way would be a more pedagogical and train/force the
    authors to learn how to use SPDX the right way.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonas Smedegaard@21:1/5 to All on Tue Apr 8 14:10:01 2025
    Quoting c.buhtz@posteo.jp (2025-04-08 13:36:54)
    Am 08.04.2025 12:44 schrieb Jonas Smedegaard:
    I have reframed it as an option (rather than
    a default goal):

    support excluding formats e.g. to only check for SPDX fields

    Do you agree that this covers the point of this issue?

    Kind of. Yes. ;)

    But I would still argument that it should be default behavior of licensecheck, to not looking for other formats if SPDX is provided.
    Checking for SPDX and other formats at the same time/file would
    contradict the goal of SPDX.

    If authors using SPDX and extra license information on purpose they are using SPDX the wrong way.

    So doing it my way would be a more pedagogical and train/force the
    authors to learn how to use SPDX the right way.

    If(!) licensecheck had SPDX and REUSE as its ultimate goals (which is
    plural: REUSE is only one use case of SPDX), then I might agree with
    your reasoning.

    Licensecheck has a wider aim than SPDX and REUSE, however, beginning
    with the fact that Debian work on systematic license naming in [DEP5]
    predates SPDX and they are still not fully aligned nor do they cover
    the same needs: Where SPDX and REUSE are arguably mainly for _authors_
    of code who know deterministically the facts about their own licensing,
    Debian needs are mainly about _redistribution_ of code where facts are sometimes quite fuzzy. Licensecheck is ideally usable both for
    validating and for approximating a fuzzy reality, but emerged from the
    needs of latter.

    Please see bug#960695 about usage profiles. Certainly sounds like you
    are describing one such profile, and elaborating on that might be
    helpful at that bugreport (rather than here).

    - Jonas

    [DEP5]: https://dep-team.pages.debian.net/deps/dep5/

    --
    * Jonas Smedegaard - idealist & Internet-arkitekt
    * Tlf.: +45 40843136 Website: http://dr.jones.dk/
    * Sponsorship: https://ko-fi.com/drjones

    [x] quote me freely [ ] ask before reusing [ ] keep private --==============776878043413727081=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    wsG7BAABCgBvBYJn9Q+JCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmciX7iTyzzM4hbOkyZu7UownZTl7VdTGjY3Bg+2/p6+ MBYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAAC6Ow/9HEiD0g/xRevM3OAkZz5EslHj d4p+Qq5dheVp76gJ1cKIQrebz6N0p6w0DFgH9CtCRltCqOz1jtyhOWf/BtCRB/c6 eL4e8xEXx09aVrApwuBQXqZMCBkBKaOCafqxEU1hwDHUs5AU0n/mYEtt5J8f8CKG 6qSC2BejbBwWVumLwkiCsAwgLKdh7ohYe9k/oM9uBx4PAmOoL1F3orZufck7xENR zitouDkra6rvSv2HcTpUu6pEz4cBEIsiAoLbTWUnd1lAaWKRsCUQZJAZWaVMqkpj HDV0fotsWTD+Hkb2wGf+tdJJjzINUozYLxmB0ymx10fsK7/BGo1UlbYofGXhVoQJ Z4u0fGBQk/7GnzpWBIlOTdUmn/xaIUGCtFetolRO