Require Licence Acceptance when installing tools

[edvilme]

No description provided.

[KalleOlaviNiemitalo]

If not --interactive, then it should not prompt; instead it should just fail unless there is evidence that the license has already been accepted.

Could have an --accept-license option for noninteractive scenarios. This option could take the license expression or a hash of the license text (shown in interactive mode) as an argument, and verify that the license of the package being installed matches what has been preapproved.

$ dotnet tool install --local package@version
The package package@version has the following license:
[license text goes here]
Do you accept this license [y/n]? y
In future installs, you can use --accept-license=sha256:a9cc4894e5f879b14d79c80e5355dfda5c5f292a2ef684bc596902c6f653d232 to indicate acceptance of this license.

or when there is a license expression:

$ dotnet tool install --local package@version
The package package@version has the "AGPL-3.0-or-later" license:
https://licenses.nuget.org/AGPL-3.0-or-later
Do you accept this license [y/n]? y
In future installs, you can use --accept-license=AGPL-3.0-or-later to indicate acceptance of this license.

although, if the license expression has spaces or parentheses in it, then it would have to be quoted in the --accept-license option.

[KalleOlaviNiemitalo]

I do not think .dotnet tool install --local should automatically record anywhere in ~/.dotnet that a specific license has been accepted. The acceptance may be based on criteria that do not apply to all projects. For example, if the license allows noncommercial use only, then a user could use the package in a noncommercial project, but would want to be prompted again before using it in a commercial project.

It would be okay to let the user add a list of approved licenses to NuGet.Config as that can be scoped by project.

[KalleOlaviNiemitalo]

Noninteractive mode:

$ dotnet tool install --local package@version
The package package@version requires acceptance of the following license:
[license text goes here]
If you accept this license, add the --accept-license=sha256:a9cc4894e5f879b14d79c80e5355dfda5c5f292a2ef684bc596902c6f653d232 option.

[baronfel]

We should talk with @OliaG about what UX should be here. I would expect

• prompting to only work when --interactive is set
• an explicit --accept-license flag to allow accepting licenses in noninteractive flows
• the kind of license should be shown to the user, as well as a link to the full license content
  • if the package provides an SPDX license expression we should link to the matching entry in https://spdx.org/licenses/
  • if the package provides an explicit license URL we should link to that URL
  • if the package provides an included license file we should link to a file:// URI for that file

We should aim to share license-acceptance UX across package add and tool install/use workflows - templates too.

[KalleOlaviNiemitalo]

• if the package provides an included license file we should link to a file:// URI for that file

Such a link might not be usable if the developer is using .NET SDK over SSH. Clicking the link would probably attempt to open the file in the SSH client machine, not in the SSH server machine where .NET SDK extracted it.

[KalleOlaviNiemitalo]

• if the package provides an SPDX license expression we should link to the matching entry in https://spdx.org/licenses/

Consider the example at https://learn.microsoft.com/en-us/nuget/reference/nuspec#license

<license type="expression">BSD-2-Clause OR MIT</license>

If the terminal supports hyperlinks, I suppose that could be formatted like "BSD-2-Clause OR MIT". Wouldn't need a full parser for that, just generate links for all 1*(ALPHA / DIGIT / "-" / "." ) words except AND OR WITH.

If the terminal does not support hyperlinks, I think .NET SDK should show first the license expression as is, and then each related URL as separate lines. No need to specifically indicate which URLs correspond to which parts of the license expression.

[KalleOlaviNiemitalo]

Presumably intended to fix #48272

[edvilme]

Triage: See the discussion above. We believe that this should be driven by NuGet and not by us and at the moment, it appears the path forward for NuGet is to deprecate that field rather than honoring it so we will close this for now. If NuGet changes their mind and adopts this support, we will revisit.
#48273 (comment)