Allowed licenses standard

Whether your organization already has a detailed license policy or needs to set one up, the Tidelift Subscription can help you implement and enforce it. By choosing to use the license compliance standard, Allowed licenses, Tidelift ensures that all package releases in your catalog only use a license from your approved list of licenses.

image (5).png

How do I set up license compliance?

You can begin enforcing license compliance by doing the following:

  1. Go to Standards 
  2. Find the Allowed licenses standard
  3. Select Configure standard
  4. By default, you will have a restrictive license policy based on the Mobile App/Hardware template.
  5. If your organization already has an approved license list, you can edit the list of licenses directly. To change the status of a license, click the Edit button for a license. You can choose to set the policy for the license to Allowed or Denied, and you can also create a task to review the license if it is discovered in your dependencies.
  6. Tidelift provides a number of default policies, based on the type of software you are building. You can choose a different pre-built template by clicking on pre-built licensing policy templates. Learn more about the license templates below

Note about Identified LIcenses standard

It is essential to turn on the identified licenses standard if turning on the “licenses must comply with policy” standard. Packages with no valid license are NOT compared to the policy.

image (6).png

Managing overrides

You may want to allow something that the license standard has not allowed. For example, this could be in an internal application that is not relevant to the license's specific requirements.

To do so, see Creating Overrides.

About Tidelift's pre-built license policies

Tidelift comes with a number of pre-built license policies suitable for many organizations, based on the software that your organization builds.


The default policy template applied is the Mobile app/Hardware template. Depending on your organization's needs, a less-restrictive policy can be selected, or no template can be applied to create a licensing policy from scratch.

The templates are based in part on the work of the Blue Oak Council, a group of top open source attorneys (including our co-founder, Luis Villa) that analyzes and groups open source licenses. In particular, it maintains two lists of licenses:

  • a Permissive list. Permissive licenses generally carry minimal restrictions on how software can be used, modified, and redistributed. Permissive licenses are categorized by drafting quality, ranking from “gold” (good) to “lead” (problematic)
  • a Copyleft list. Copyleft licenses can impose restrictions on software that uses copyleft software as dependencies, or on modifications made to the software itself. Copyleft licenses are categorized by when and to what the copyleft provisions apply.

The following templates are available:

SaaS frontend

Use case: For code distributed to users as part of a web interface, typically JavaScript or similar languages that are compiled to obfuscated JavaScript or WASM.
Risk profile: Distributing code to the public as part of a web frontend can trigger license obligations. However, scrutiny of these tends to be lower, for various reasons, including cultural (web-frontend communities tend to be strongly anti-copyleft) and technical (copyleft JavaScript code without code for the server is typically not very useful, so less attractive to license enforcers).
License types (not a complete list): License types (not a complete list): includes licenses on the Permissive List; excludes all licenses on the Copyleft List.

SaaS server

Use case: For code used in cloud-hosted services.
Risk profile: Making code available to the public only via an API or through another front-end (such as an app or web page) rarely triggers obligations, except for the strongest copyleft licenses.
License types (not a complete list): includes all licenses on the Permissive List (including “lead”) and Copyleft List “weak” and “strong”; excludes Copyleft List “network”, “maximal”

B2B Distributed application

Use case: For code that is distributed to corporate customers.
Risk profile: Distributing code to other businesses can trigger obligations, but tends to attract less scrutiny because it is between sophisticated parties and may be semi-private.
License types (not a complete list): includes licenses on the Permissive List except the lowest-quality drafting (“lead”); excludes Copyleft List “strong”, “network”, “maximal”

Mobile App/Hardware

Use case: For code that is distributed to consumers, particularly over mobile or as part of an embedded device.
Risk profile: Distributing code to the public can trigger complex obligations in certain licenses, may interact with other legal obligations (like App Store requirements), and also attracts the most scrutiny.
License types (not a complete list): includes licenses on the Permissive List except the lowest-quality drafting (“lead”); excludes all licenses on the Copyleft List.


Was this article helpful?
0 out of 0 found this helpful



Article is closed for comments.

Articles in this section

See more