Update (by @anangaur on 1/8/2019) - Useful links:

• Feature announcement: Packaging Icon, License and Documentation within the nupkg
• Deprecation announcement for licenseUrl: 'licenseUrl' as package metadata is now deprecated, use 'license' instead
• Spec wiki: Packaging License within the nupkg
• Discussion issue: Self-Contained NuGet Packages – License #4628
• Documentation for license metadata in nuspec: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license
• Documentation for license metadata using MSBuild properties in project file: https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#packing-a-license-expression-or-a-license-file

Right now, every package can link to a license by providing the licenseUrl property in the metadata. This is awesome, but also not-so-awesome. Allow me to explain my line of thinking.

Every package owner can attach a license to every version of their package. So far, so good, as it allows switching license between versions. So far, so good.

Now imagine utilizing a NuGet package. For impact, let's take Newtonsoft.Json, a very popular OSS package with a permissive license. One day, the author decides to update the HTML contents at the referred license URL. That's... problematic!

Which license applies? The one I read (and agreed with) at package install time? Or the current one that is now displayed on the license URL?

There is no way to figure out the license changed between install and consuming the package, no way to prove it was permissive at time of first install.

Please consider enforcing embedding license info into the package, as the package itself is considered immutable.