Skip to main content
Skip table of contents

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:

  1. Nuget packages hosted on Nuget

  2. 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.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.