How to treat UNMAPPED_DECLARED_LICENSE?

[jens-erdmann]

Hi team,

I am facing an issue in one of our projects regarding a NuGet dependency. The project depends on a package named CommandLineParser which itself has its license being an URL referring to a the actual license.
We tried to cure this with the following curation:

    curations:
      packages:
      - id: "NuGet::CommandLineParser:2.9.1"
        curations:
          comment: "A copyright statement was used to declare the license."
          concluded_license: "MIT"
          declared_license_mapping:
            https://www.nuget.org/packages/CommandLineParser/2.9.1/license: "MIT"

This is directly from the analyzer result YAML file.

Unfortunately the result still is declared unmapped. The result snippet:

  result:
    projects:
        ...
    packages:
    - id: "NuGet::CommandLineParser:2.9.1"
      purl: "pkg:nuget/CommandLineParser@2.9.1"
      authors:
      - "gsscoder,nemec,ericnewton76,moh-hassan"
      declared_licenses:
      - "https://www.nuget.org/packages/CommandLineParser/2.9.1/license"
      declared_licenses_processed:
        unmapped:
        - "https://www.nuget.org/packages/CommandLineParser/2.9.1/license"
      description: "Terse syntax C# command line parser for .NET.  For FSharp support\
        \ see CommandLineParser.FSharp.  The Command Line Parser Library offers to\
        \ CLR applications a clean and concise API for manipulating command line arguments\
        \ and related tasks."
      homepage_url: "https://github.com/commandlineparser/commandline"
      binary_artifact:
        url: "https://api.nuget.org/v3-flatcontainer/commandlineparser/2.9.1/commandlineparser.2.9.1.nupkg"
        hash:
          value: "4f364e45c9668c7e7cc6a922b488f3fa523033c20d7a432694f0a6af05ce528ea0481d8375e2f4f1032c6990347b4803ce9a0e48068c6fe15ec46fb1254f085d"
          algorithm: "SHA-512"

Just for completeness we also have a package configuration to fix some additional issues. Snippet:

    - id: "NuGet::CommandLineParser:2.9.1"
      vcs:
        type: "Git"
        url: "https://github.com/commandlineparser/commandline.git"
        revision: "b0b0ec9f5470bacc0823c013a599ba3b4e115900"
      license_finding_curations:
      ...

I think our curation is according to the documentation. Is there something we can do to get more insights on this?

[pepper-jk]

I have also opened issue #10759 on this topic.

[sschuberth]

which itself has its license being an URL referring to a the actual license.

This is, BTW, unfortunately a common thing for NuGet packages, also see the old idea in #5259.

[jens-erdmann]

I am not concerned about the validity of the data in itself. I agree, that this is not a good way of assigning the license. But that is a discussion to be had with the owners or the NuGet maintainers.

It certainly looks like a bug on the surface to me, but I also cannot rule out any configuration mistake right now.

Ok, so you acknowledge that our exception is correct and the curation should have cured the issue. So it is on us now to find a way to rule out our own config being the reason for the mapping not to work.

[sschuberth]

So it is on us now to find a way to rule out our own config being the reason for the mapping not to work.

In parallel, what would help to get this debugged more easily, is a public Git repo with a minimal reproducer incl. a .ort.yml file with the curation.

[jens-erdmann]

I have created this project that is as stripped down as possible but I am still able to reproduce the issue:
https://github.com/jens-erdmann/NuGet-Test-Subject

[sschuberth]

Thanks, I was able to reproduce the problem with this. So we should probably continue the discussion in the issue report as it's actually a bug, and not a matter of configuring the license mapping.

[jens-erdmann]

Thanks, I was able to reproduce the problem with this. So we should probably continue the discussion in the issue report as it's actually a bug, and not a matter of configuring the license mapping.

Oh you beat me to it. Thank you for confirming. I am fine with moving this discussion into the issue.