Legacy Mend UI - Why are DLLs often Missing License Information?
This article explains why DLLs often appear with “Requires Review” under License even when the same Project with the same DLL is scanned.
Unlike traditional libraries, DLLs do not have a package manager. That is why there is no official page that can assist us in automating the license identification process. In addition, DLL itself never contains any information about its license. At best, when it is extracted, it contains copyright information only. With that said, DLL's license is determined based on algorithms for the sources it is downloaded from.
Currently, Mend imports DLLs from two hosts:
Nuget packages hosted on Nuget
Microsoft's official website (for .NET Core DLLs)
Nuget packages hosted on Nuget
Process: When the Nuget packages are imported to our database, the package is extracted and every DLL inside the package is added to our database. When the DLL is added from a Nuget package, the importer calculates a score (a number between 0-1) which stands for the likelihood that this DLL is a "core" DLL of that Nuget. This score is calculated based on the factors below:
DLL's name vs. Nuget package's name
DLL's version vs. Nuget package's version
If this score is high enough (>=0.7) the DLL will get the same license as the Nuget package it was imported from.
Example of an ideal scenario: DLL with the name "Newtonsoft.Json-13.0.1.25517.dll" which comes from "newtonsoft.json.13.0.1.nupkg" will get the Nuget package's license MIT, as this is a core DLL of that Nuget (same name and same version, thus high severity score) and we can rely on the information located inside the Nuget package.
Example of a good scenario: DLL with the name "Newtonsoft.Json-13.0.1.25517.dll" which comes from "log4net.2.0.13.nupkg" will not get the wrong log4net's Apache 2.0 license as this DLL acts as a 3rd party library. It will be marked as Requires Review.
Example of a bad scenario: DLL with the name "System.Xml.ReaderWriter-4.8.0.27.dll" which comes from "Microsoft.NETCore.Platforms-6.0.0" is less likely to get the Nuget's license, even if it's a correct license and will remain Requires Review.
Difficulties:
Not every DLL has a parent Nuget package
Some DLLs are contained in Nuget packages as a 3rd party library
Not every "core" DLL will be with the same name/version as the Nuget package
Limitation:
Mend cannot lower the DLL’s score as it will assign wrong licenses to 3rd party DLLs.
Microsoft's official website
Process: .NET Core DLLs are imported to our database from Microsoft's official website. This allows us to associate .NET Core DLLs with the vulnerabilities, but the licensing issue still exists with some of the imported DLLs.
Difficulties:
Multiple licenses (with 3rd party licenses) in the same zip
The license file is located deeper in folders hierarchy than the DLL. If the license file is deeper in folders hierarchy, the DLL appears as Requires Review, as it is unsafe to assume that this license is a 100% guaranteed license of that DLL
.NET Core vs. .NET Framework. Both are .NET C# development frameworks. And it is important to distinguish between them. .NET Core is a cross-platform, an open-source framework, while the .NET Framework is windows-only proprietary software. "Proprietary" license is not assigned automatically, as currently Mend supports only Open-Source software. The complexity here is that both have the same named DLLs. For example "System.Xml.Writer.dll" might be used for .NET Framework and .NET Core but with different SHA1s.