Organization-wide issues & conditional policies

In September, we introduced Component Search to give organization decision makers a bird’s eye view of compliance across all of their projects. Since then, we’ve been doubling down on building organization-level features and improving the user experience in general.

One common piece of feedback we’ve heard is that the organization-level view has a lot of noise. FOSSA was originally built to work on a per-project basis, so some actions that occur logically at the organization level required repetitive work at the project level. Here are some examples:

Organizations that owned code using denied licenses (usually GPL or LGPL) would need to manually mark internal dependencies as their own.
Licenses that only had obligations under specific conditions (e.g. MPL) were being flagged by conservative default project policies.
Common issues that were resolved in one project (e.g. allowing a specific logging library) would need to be repeatedly resolved across all projects.

No longer! This week, we’re rolling out new features to help reduce toil and false positives.

Organization-level Issues

FOSSA now recognizes when issues occur across multiple projects within an organization. This means that resolving an issue across an organization no longer requires resolving it in every individual project of the organization.

Issues that occur in the same dependency across many projects are grouped together.

Since some of our customers have hundreds of projects, this is a huge reduction in manual work. If you have an issue that is specific to a project, you can still resolve issues at the project level.

By default, issues are now resolved at the organization level, with the option of the project level.

Conditional Policy Rules

Policy rules may now have conditions associated with them which determine when they apply.

Rules can now specify conditions under which they are applied.

We’re starting out with 3 types of conditions:

Code location. Filter licenses by whether they’re in your own code or in a dependency. This is useful for licenses like MPL, which only apply if you modify the code — if you don’t manually edit your dependencies, it’s safe to allow MPL-licensed code.
Project name. Filter projects by whether their names contain a substring. This is useful if your organization has a naming convention for internal packages (e.g. acme-* or @acme/*) so you can allow code that you own to use licenses you would normally disallow.
Linking type. Filter dependencies by how they’re linked to your project. This is useful for licenses like LGPL, where linkage matters. We currently infer linkage on a language and build system basis, and we’re working on pulling linking data from full builds.

New organizations will also have an updated set of default policies, which should dramatically reduce the number of false positives for new integrations. We’ll be reaching out to current customers to optionally migrate their current policies to use conditional rules. Please contact support@fossa.io if you’dlike help doing so.

Many licenses that would originally be denied can now safely be flagged using conditional rules.

Improved Organization Settings

In addition to specifying conditional rules, organizations will now be able to match internal dependencies by substring. This means that internal dependencies will no longer show up as unlicensed (although we will still analyze the dependencies of internal dependencies, and correctly flag issues in those).

Organizations can specify internal dependencies to ignore when scanning.

TL;DR

FOSSA’s workflow for medium to large organizations should get a lot smoother.

Conditional policies and better settings means fewer false positives.
Organization-level issues mean faster resolution for real issues.

We expect these improvements to eliminate roughly 90% of false positives and provide a much smoother setup for new integrations.

Questions?

Suggestions on how we can improve your workflow? Let us know at support@fossa.com.

More on FOSSA

FOSSA helps team stay on top of their open source code. 85% of your code today is from open source dependencies, each with their own licensing terms. We help teams reduce risk without slowing down development by integrating automated license compliance scanning with your CI/CD workflow.

If you’d like to try FOSSA in the cloud today or learn more about our on-prem solution, contact support@fossa.com with a bit of detail about your company’s goals. To stay in the loop with e-mail updates, sign up below.

FOSSA was built by the team behind TLDRLegal and is working with some great lawyers like Heather Meeker (author of MPL and Mozilla ToS).