Licensing Policies

Overview

A licensing policy controls which licenses and dependencies FOSSA approves, flags for review, or denies across every project you scan. FOSSA ships three builtin templates tuned to different distribution models. Use one as-is or customize its rules. Once configured, a policy can be set as your organization default or applied to individual projects.

How licensing policies work

A licensing policy is a collection of rules. Each rule assigns an action (Deny, Flag for Review, or Approve) to a specific license or dependency. On every analysis run, FOSSA evaluates each detected license and dependency against the active policy and raises issues accordingly.

The three builtin templates

Each template is tuned to a different distribution model. They differ mainly in how they treat copyleft licenses, which scales with how much the distribution model exposes you to copyleft obligations.

Standard Bundle Distribution

The general-purpose default, and the template FOSSA applies to new projects unless you choose another. Best for traditional software distributed to end users:

• Desktop applications, CLI tools, and installers
• Software libraries, SDKs, and plugins built for redistribution
• Commercial products with a standard "users install and run it locally" model

It balances compliance with development flexibility: most GPL licenses are flagged for review rather than denied, giving teams room to evaluate copyleft dependencies case by case.

Website/Hosted Service

Best for code that runs server-side and is never delivered to end users:

• SaaS applications, web services, and APIs
• Backend microservices and cloud-native components
• Internal tools and services used only within your organization

This is the most permissive template toward copyleft. Because server-side execution generally does not trigger distribution obligations, it denies AGPL but only flags most GPL and LGPL licenses, maximizing flexibility for backend development.

Single-Binary Distribution

Best for software shipped as a single self-contained artifact, where all dependencies are bundled together:

• Mobile applications (iOS, Android)
• Embedded systems, IoT devices, and firmware
• Statically-linked executable binaries

This is the strictest template. It denies the full GPL and AGPL families to minimize copyleft obligations in scenarios where source-code disclosure would be problematic.

Creating a policy

Navigate to Policies in the top navigation, then open the Licensing tab. You'll see any existing policies alongside the option to create a new one.

1. 1

   Open the Create New Policy dialog

   Click Create New Policy.

   Expand

2. 2

   Set the policy type

   From the Type dropdown, select Licensing.

3. 3

   Name and describe the policy

   Give the policy a Title and a Description that provides context for your team, for example, the distribution scenario it covers.

   Expand

4. 4

   Choose a starting point (optional)

   Select a FOSSA template or an existing policy from your organization to use as a skeleton.

   Expand

   The three available templates are described in The three builtin templates above.

5. 5

   Submit

   Click Submit to create the policy. It now appears in your Policies list and can be assigned to projects.

Configuring policy rules

A new policy inherits its template's rules. Add, remove, or adjust rules to match your organization's standards.

Expand

Adding a rule

Open the policy you want to edit from the Policies page, then add rules to the Deny, Flag for Review, or Approve panel.

1. 1

   Click Add Rule

   In the policy editor, click Add Rule above the panel you want to add the rule to, Deny, Flag for Review, or Approve.

2. 2

   Choose the rule target

   Select whether the rule applies to a license or a dependency (project), then search for and select the specific license or dependency.

   Expand

3. 3

   Add conditions (optional)

   Narrow when the rule fires by enabling one or more conditions. See Rule conditions below.

4. 4

   Save

   Click Submit to add the rule to the policy. Changes take effect on the next scan.

Rule conditions

Conditions let you restrict a rule to specific circumstances so it only fires when relevant. Each rule supports up to three independent conditions.

Setting a default for uncategorized licenses

When FOSSA encounters a license that has no explicit rule in the policy, it falls back to the policy's default action. By default this is Uncategorized, which takes no action.

1. 1

   Open the rule action menu

   In the policy editor, find the panel (Deny, Flag for Review, or Approve) you want to make the default. Open the action menu for that panel.

   Expand

2. 2

   Set as default

   Select Make this the default category. The panel is now marked as the default, any license with no explicit rule will be treated as if it matched this action.

The four possible defaults and their behavior:

Choosing defaults across your organization

Set one builtin template as your organization-wide default, then override at the project level wherever a project's distribution model differs.

For organizations with mixed project types, a common approach is:

1. Set Standard Bundle Distribution as the org-wide default for maximum flexibility.
2. Override at the project level for specific distribution scenarios, for example, mobile and embedded projects → Single-Binary Distribution; backend services and internal tools → Website/Hosted Service.

For more specialized organizations, match the default to your dominant distribution model and override the exceptions:

Setting the organization default

Once you've created a policy, assign it as the organization default so it applies automatically to every new project imported going forward.

1. 1

   Open organization project settings

   Click your username in the top-right corner and select Settings, then navigate to Projects → Issue Policies → Licensing.

   Expand

2. 2

   Select the policy

   Under the Licensing section, use the policy dropdown to select your newly created policy.

   Expand

3. 3

   Save

   Click Save to apply the policy to all future projects.

4. 4

   Propagate to existing projects (optional)

   To apply the change to projects already in FOSSA, click Propagate and select which settings you want to push to existing projects.

Applying a policy to a project

Override the organization default on any individual project whose distribution model differs.

1. 1

   Open project settings

   Navigate to the project in FOSSA and open its Settings.

2. 2

   Go to Issue Policies

   Select Issue Policies from the settings sidebar.

   Expand

3. 3

   Select the policy

   Choose the appropriate policy for each issue type (Licensing, Security, Quality).

4. 4

   Save

   Save your changes. The new policy applies on the next scan.

Rolling out a policy

When introducing policy enforcement for the first time:

1. Start with the most restrictive policy that fits your distribution model, so you surface compliance risk early.
2. Run an initial scan across your projects to understand your current license landscape before enforcing.
3. Resolve denied licenses before turning enforcement on, then relax restrictions only once you understand the implications.
4. Begin from a builtin template rather than building a policy from scratch, and document any customizations along with the business reasons behind them.
5. Align your team on the difference between Approve, Flag for Review, and Deny, and establish a clear escalation path for flagged-license decisions.

Migrating between policies

From no policy to a builtin template: start with Standard Bundle Distribution, run comprehensive scans across all projects, address any denied licenses, then gradually apply project-specific policies based on each project's distribution model.

Between builtin templates: understand the license differences first (see the comparison table above), test the change on a few representative projects, communicate the change to development teams in advance, and provide a timeline for addressing any newly-denied licenses.

The key is matching your policy choice to your actual distribution model and risk tolerance. Start conservatively, then adjust as you learn your organization's specific needs.

What's next

• Reviewing Licensing Issues: Resolve dependencies flagged or denied by your licensing policy.
• Security Policy: Define vulnerability handling policies to complement your licensing rules.
• Fail CI/CD Checks: Enforce your policies in CI/CD to block non-compliant builds.