Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require EULA/TOS acceptance before download starts. #200

Closed
daegalus opened this issue May 19, 2020 · 7 comments · Fixed by #1347
Closed

Require EULA/TOS acceptance before download starts. #200

daegalus opened this issue May 19, 2020 · 7 comments · Fixed by #1347
Assignees
Labels
Area-Manifest This may require a change to the manifest Issue-Feature This is a feature request for the Windows Package Manager client.
Milestone

Comments

@daegalus
Copy link

daegalus commented May 19, 2020

Description of the new feature/enhancement

Some packages require a EULA to be accepted before commencing the download of the product. But I have noticed no such functionality is present. There should be an option to provide a EULA/TOS source url or file that will be presented before the download of the file begins that will be accepted by the end user.

Proposed technical implementation details (optional)

My thoughts would be that we can have something like a "EULAUrl" or "TermsURL" that will point to the products EULA or Terms, that will be shown in some kind of pager inside the terminal that will allow accepting or declining. If you accept, download commences and process continues as normal. If declined, just exit.

Also maybe a flag to auto-accept the EULA for purposes of automation.

@daegalus daegalus added the Issue-Feature This is a feature request for the Windows Package Manager client. label May 19, 2020
@utybo
Copy link

utybo commented May 19, 2020

Wouldn't this be problematic when running winget as part of a script? You're not guaranteed to have an interactive shell

@krism142
Copy link

It would only be problematic if the package you are trying to script against uses the flag, in which case you probably were not scripting that before this anyway no? since it would imply that the package required users to agree to the EULA/Terms before download anyway

@utybo
Copy link

utybo commented May 19, 2020

I might have accepted the EULA before creating my script, but if I give my script to a friend who has not accepted the EULA, then that might be a problem 😕 .

Another solution might be to add a --accept-licenses flag which auto-accepts the EULAs and prints something like By using the --accept-licenses flag, you agree to the following terms and conditions followed by links to the relevant EULAs. This isn't perfect but would solve the interactivity-in-non-interactive-use-cases issue.

@daegalus
Copy link
Author

daegalus commented May 19, 2020

It's kind of what I meant with my last sentence of having a flag for automation.

With proper messaging like krism suggested, it could work well enough. Similar to how Oracle JDK works on Linux even. You have to accept licenses to use it but has a flag for automation to auto accept.

This is mostly to distribute software that requires it, its optional and doesn't need to be used for everything.

@denelon
Copy link
Contributor

denelon commented May 22, 2020

This is something we have been discussing internally. I do not believe I managed to create an issue for it already. I'm interested in the discussion here. So far it's similar to early thoughts the team had.

If there were a flag in the manifest, the user experience could be improved either with some form of "strict" mechanism requiring user interaction, and / or prioritizing the EULA prompts for download on package set (<- current conceptual name for a collection of packages) initiation. If one were to specify the entire set needed to be 100% unattended, we could fail on manifests that have a EULA required for download.

We have observed EULA prompts prior to download, at install time, and on first launch. Our goals are not to prescribe how software publishers handle their EULAs. We want to focus on providing the best user experience with the client given the various options.

@denelon denelon added this to the Package Manager Backlog milestone May 23, 2020
@denelon
Copy link
Contributor

denelon commented Jun 22, 2021

Description of the new feature/enhancement

Some packages require users accept an End User License Agreement (EULA).

Proposed technical implementation details (optional)

When a EULA is included in a manifest, the user must accept the EULA in order to install the package.
A "EULA" key should be added to the manifest schema.
A "EULAUrl" key should be added to the manifest schema.

We're going with a somewhat flexible system so verified publishers can customize the fields and to a minor extent, the display behaviors. We would bold the "AgreementLabel". These fields will be part of the locale files so they can be localized.

Agreement:
  - AgreementLabel: string
    Agreement: string
    AgreementUrl: URL

Validation logic should also look for URLs in text fields to make sure users aren't slipping "bad" URLs by us.
When a user executes show, install, upgrade, or import, the fields should be displayed if they are included in the manifest.

If a EULA field is present, the user must accept the EULA to continue with install, upgrade, or import.

The user may pass an argument to accept the EULA to eliminate required user interaction, but the EULA fields must still be displayed.

-a, --accept-agreements

@denelon denelon added the Area-Manifest This may require a change to the manifest label Jun 22, 2021
@denelon denelon modified the milestones: Backlog - Windows Package Manager, v1.1 - Windows Package Manager Jun 22, 2021
@denelon denelon linked a pull request Aug 6, 2021 that will close this issue
2 tasks
@github-account1111
Copy link

github-account1111 commented Mar 11, 2022

The user may pass an argument to accept the EULA to eliminate required user interaction, but the EULA fields must still be displayed.

-a, --accept-agreements

--accept-agreements throws an error:

PS C:\Users\user\Desktop> winget install --id 9N97ZCKPD60Q --source msstore --accept-agreements
Windows Package Manager (Preview) v1.3.431-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Argument name was not recognized for the current command : '--accept-agreements'

Edit: --accept-eula from #1144 doesn't work either.

Edit 2: --accept-package-agreements did the trick!
Should've checked with -? before posting :D

ryfu-msft added a commit to ryfu-msft/winget-cli that referenced this issue Jul 24, 2024
6ab78af6 Bump curl from 8.4.0 to 8.8.0 (microsoft#205)
14b2b422 Tool: adding a way to save output to a json file (microsoft#204)
84a6567e Forcing faster timeout on timeout test (microsoft#202)
3cbd0170 Dependabot: ignoring patch updates for pip dependencies (microsoft#200)
d03c887f Bump clang-format from 18.1.4 to 18.1.5 (microsoft#198)

git-subtree-dir: src/SfsClient/sfs-client
git-subtree-split: 6ab78af61bc859461ea8298786d87f24b49e3ec2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Manifest This may require a change to the manifest Issue-Feature This is a feature request for the Windows Package Manager client.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants