Feature Request: Provide third party / OSS bill of material and license / copyright list on build

[markusschaber]

(I'm posting this feature request here for discussion, as recommended on the DotNetEvolution Discord.)

My feature request is some mechanism to automatically provide a third party / OSS bill of materials and license / copyright list when building a .NET application. With growing number of dependencies, it's not easy to keep such a list up to date manually. Such mechanisms exist on other platforms, for example, we use https://www.npmjs.com/package/license-webpack-plugin with Angular.

Reasons why this feature is useful:

1. Such a bill of materials is the base for license compliance. Developers and compliance departments need a reliable way to see which licenses are applicable (including indirect dependencies), so they can make sure the licenses are followed (or dependencies with unacceptable licenses are removed/replaced).
2. Such a bill of materials is also security relevant - those packages need to be monitored for CVEs to see which version is affected, and whether a security update is necessary.
3. Some jurisdictions (e. G. German copyright law) require that the Authors / Copyright holders are declared when a product is redistributed (except when they explicitly waive).

This is especially important for scenarios <PublishSingleFile> or client side Blazor: For example, the Apache License states "a) You must give any other recipients of the Work or Derivative Works a copy of this License;" - According to the Lawyers at OSADL (https://www.osadl.org/), the word "give" means that the text including the license must be downloaded to the browser when the web application is downloaded. It is not sufficient to just provide a link to the license text, or download it on demand when the user clicks on a "show licenses" link/button in the web application, or just copy-paste it somewhere in the documentation (this has been sufficient back then when the software and documentation were physically shipped together).

IANAL, but as far as I understood, it's ok for a web app when the licenses are in a separate file, and that the license is only actually displayed when the user clicks on the button, but it must be downloaded (into the browsers' memory) each time the application is downloaded. Their detailed analysis is members only: https://www.osadl.org/?id=3543.

I cannot see this feature being easily implemented as an add-on NuGet tool. As far as I can see, this feature needs to be provided by the tool chain (NuGet, MSBuild, Linker...) playing together, as

1. The resulting list needs to be included within the deliverable, which might be especially difficult with <PublishSingleFile>.
2. We need to avoid false positives (e. G. NuGet Packages which are not actually used, or just provide build tools / analyzers, or where the references are dropped by the linker as the referencing code itself is dropped).
3. On the other hand, when using single file publishing, or client side Blazor, (parts of) the framework and runtime are included within the final product, so they also must be included in the List.
4. Also, there should be some mechanism to manually "inject" additional license files, when code is included via other mechanisms (e. G. copy-paste, git submodules, ...).

There is https://github.com/tomchavakis/nuget-license, but as far as I can see, it does not take linking into account, and misses the framework/runtime itself (which is not referenced as NuGet). And I could not find an easy way to get the generated list included within the compiled application.

[kartheekp-ms]

@markusschaber - NuGet team received a proposal to list all package licenses here #10852. Can you please look at that proposal and see it covers all the scenarios listed above as per https://github.com/NuGet/Home/wiki/Submitting-Bugs-and-Suggestions#suggestions-and-feature-requests?

//cc @JonDouglas @chgill-MSFT

[markusschaber]

Hi, @kartheekp-ms,
the proposal #10852 goes beyond my feature request in one aspect, as it allows for some blacklisting/whitelisting of allowed licenses and forcing the build when non-allowed licenses are used, and goes into details of how to actually find the valid license for a NuGet package (which seems to be more difficult than it should be).

But on the other hand, as far as I can see, it falls short in the following requirements of my proposal:

1. Considering the non-NuGet references, e. G. parts of the Framework / runtime which are linked with <PublishSingleFile> or client side Blazor.
2. Respecting the results of the linker, thus only listing those packages which parts are actually linked into the product, instead of just following all NuGet references, whether they're actually used in the project, or unused, or "just" build tools.
3. Including the copyright notices per package, it concentrates with the licenses and deduplicates them over the packages.
4. Injecting the result into the binary, so we can be sure it will be "given" to the receipient of the compiled application (and displayed in the UI).

Those shortcomings are one reason why I filed it as a different proposal. The other one is that I doubt this can be solved by NuGet alone, and the proposal #10852 explicitly concentrates with NuGet.

However, I now asked the author of #10852 whether we could extend his proposal to include the uncovered requirements.

[zkat]

@JonDouglas Can you take this into account for discussions in #10852 and see if there's ways to make these work together?

/cc @anangaur

[markusschaber]

See #10852 (comment) for an explanation of @aaronpowell why he thinks that the issues should not be merged. I tend to agree.
I think those features somehow complement each other.