Crawler incorrectly adds Microsoft Copyright to NuGet Packages

[seantleonard]

Suggestion: The ClearlyDefined crawler should not attempt to discover copyright information from the aka.ms/deprecateLicenseUrl link stamped into the deprecated licenseUrl NuGet package metadata field.

Background:
When a NuGet package's build configuration or nuget.config does not explicitly set a value for the deprecated NuGet package metadata field licenseUrl​ per NuSpec Referece, the field is populated with the link (https://aka.ms/deprecateLicenseUrl ) by default. In the past, this link may have pointed to a Microsoft Docs page with a deprecation notice at one point in time. The linked doc page doesn't have the deprecation notice anymore and should be updated.

This causes an issue where ClearlyDefined crawler attempts to gather license data for a package and thinks that following the aka link in the deprecated field will provide copyright information for the package. This results in the crawler scraping a Microsoft copyright from the Microsoft docs page and stamping it into a NuGet package. This incorrectly attributes a packages copyright to Microsoft which to me seems erroneous as Microsoft doesn't have copyright over all NuGet packages.

• Example package NuGet metadata JSON: https://api.nuget.org/v3/catalog0/data/2023.02.24.17.52.10/hotchocolate.12.18.0.json
• Example of ClearlyDefined harvested erroneous Microsoft copyright: https://clearlydefined.io/definitions/nuget/nuget/-/HotChocolate/12.18.0
• Only workaround: I have to maintain a script in my build process which manually strips out this erroneous copyright information, and a script overriding license info compiled by ClearlyDefined is prone to error.

In my opinion, expecting package authors to manually set that deprecated field to replace the URL https://aka.ms/deprecateLicenseUrl​ is not a viable solution because setting the licenseUrl​ property in the per package .nuspec​ config file used for NuGet package creation will result in a package build warning NuGet Error NU5125 | Microsoft Learn.

• A negative anecdotal experience I found is that projects may treat build warnings as errors. In that situation, a maintainer would need to refactor their package publishing process to not fail when that warning/error is emitted. Suppress NuGet licenseUrl deprecation warning by stakx · Pull Request #481 · castleproject/Windsor (github.com)

This isn't a one package's specific problem as seen when Google searching that aka.ms link and observing many packages' metadata files containing that URL as default when publishing packages to NuGet.

[seantleonard]

Possible follow-up on #213