Cloudsmith provides the ability for all Raw format files, if enabled, to require End-User License Agreement (EULA) when a user attempts to download it.
To create a EULA, click "EULA Enforcement" on the left-hand menu in a repository, and then click the green "Create Revision" button:
You will then presented with the Create EULA Revision form, where you can add the content/terms that you wish to display to the user before they can download the file:
You then click the green "Create Revision" button to create the EULA. You can repeat this process if you need to create subsequent revisions of the EULA.
The first time a user attempts to download a raw package using a download link, they will instead see the EULA:
Once the user has clicked the "Yes, I Agree + Download File" button, the download will start.
If a user wishes to accept the EULA without visiting the HTML page,
?accept_eula=1 can be suffixed onto the URL link for the raw package (which would otherwise display the EULA) to accept it. The number appended to the
accept_eula parameter specifies the revision of the EULA that is being accepted:
|Your Cloudsmith Entitlement Token (see Entitlements for more details)
|Your Cloudsmith account name or organisation name (namespace)
|Your Cloudsmith Repository name (also called "slug")
|The name of the raw file
EULA for Entitlement Tokens is currently in Early Access. If you'd like to be included in early access to this feature please contact us.
You can specify that a EULA must be accepted before an Entitlement Token can be used. This will allow you to enforce EULA acceptance for any package format, as Entitlement Tokens are used to provide controlled, read-only access to any artifact in a repository.
To require EULA acceptance for an Entitlement Token, you need to select the option when editing an Entitlement Token:
If checked, then a client will be compelled to go to the token-based URL for EULA acceptance, before they are able to use the token to download files. Note that this also requires EULA enforcement to be enabled on the repository.
You can see them in "Download Logs" within a repository. These are processed asynchronously so they don't appear immediately after a download happens, but within a short-time (usually within 5 minutes). If EULA enforcement is enabled, then each Raw package file has gone through the EULA acceptance before download. In other words, it's not possible to download without accepting the latest revision of the EULA.
Hovering over the EULA icon provides detail on which revision was accepted for it, and clicking it brings you to the EULA overview. It will show the name of the entitlement token you've created for that specific customer (or group of customers). E.g. "Microsoft (Token)" if a customer at Microsoft had downloaded it. In summary, we show which customer downloaded which file, when, and having accepted what EULA revision to do so.
Once a EULA has been created, you (a person with privileges) has exactly one hour to make modifications, then it gets locked. Afterwards you'll no longer be able to edit the EULA revision again. It's only possible to edit the most recent EULA revision within this one hour window. Any previous EULA revisions are never editable.
Any EULAs are covered by the same strong guarantees for data sanctity as the rest of the system; as described in our Security Policy. You cannot directly delete a EULA revision.
Permanently until the repository or account is deleted; this can only be done by Admin of a repository, or an Owner of the account. See RBAC question later.
If you want to export your data out of the system, we are happy to help with that. We don't believe in vendor lock-in or restricting the portability of customers. :)
Only users (or users in a team) with Admin access on a repository, or Owner access on the account, can modify EULA revisions. As mentioned previously, they can't edit or delete earlier EULA revisions. What they can do: Add a new EULA revision, enable/disable EULA enforcement for that repository.
As above, EULA are restricted to specific roles already, but it's possible to define your own roles (as such) by creating Teams with the appropriate privileges. For example, you could create a team of users that specifically has Admin access to the repositories (to manage the repository), and then another one that has Write access (for adding new packages). Our recommendation would be to ensure that only appropriate employees have the Admin access, and to greatly restrict who has Owner access on the account itself.
Updated 18 days ago