Configuring Conditional Policy Rules

Policy rules can be tailored with specific conditions to ensure that FOSSA flags issues only when necessary.

There are currently three types of conditions that can be customized to ensure that policy rules are applied appropriately and in a way that best suits your organization's requirements.

License location

This condition allows you to filter licenses based on whether they are found within your own codebase or within a third-party dependency. This is particularly useful for licenses such as the Mozilla Public License (MPL), which only impose obligations if you modify the licensed code. If you do not make any manual modifications to your dependencies, it is generally safe to permit code that is licensed under MPL.

Dependency name

This condition enables you to filter projects by checking whether their names contain a specific substring. This can be especially beneficial if your organization follows a structured naming convention for internal packages, such as acme- or @acme/, as it allows you to distinguish your own code from external dependencies. By using this filter, you can permit the use of licenses that you would typically disallow, but only for code that belongs to your organization.

Linking type

This condition allows you to filter dependencies based on how they are linked to your project. This is particularly relevant for licenses such as the Lesser General Public License (LGPL), where the method of linking—whether static or dynamic—can have legal and compliance implications. At present, we infer linkage based on the programming language and build system in use, and we are actively working on improving this by extracting linking data from full project builds.

By customizing these conditions, you can refine how FOSSA identifies and flags potential license issues, ensuring that your compliance processes are both thorough and appropriate for your organization's needs.