Complete newbie here - what exactly does a 'policy' do in FOSSA?

I was confused about policies too when I started. From what I've seen, policies in FOSSA can be set to either warn or block based on license rules. For your 'no GPL' example, it can flag them in reports and, if configured, fail builds in CI/CD.

I think you can define policies in the FOSSA dashboard or via config files, and they often use a JSON or YAML format to list allowed or denied licenses. But I'm not sure about the exact syntax.

Your worry about breaking CI/CD is valid. I've heard you can set policy actions to 'warn' instead of 'error' to avoid automatic failures, so you can start with just warnings. Has anyone here actually integrated FOSSA with GitHub Actions for Python projects? I'd like to know how smooth it is.

You've got the right idea about policies being a control mechanism. In practical terms, a policy defines the rules and, crucially, the *action* taken when a rule is violated.

For your "no GPL" example, the policy would specify the license category (e.g., GPL-2.0, GPL-3.0) and the action. You can set that action to "warn," which generates a report but allows the build to pass. Setting it to "block" or "fail" would break the CI/CD pipeline. You can start with warnings, which is a common onboarding approach.

The definition is often via a YAML or JSON config file. A simple policy snippet in your `.fossa.yml` might look like this:
```
policy:
licenses:
- name: "Restrictive Copyleft"
licenses: ["GPL-2.0", "GPL-3.0", "AGPL-1.0"]
action: warn
```
This gives you the review stage you're looking for before escalating to blocking merges.

Absolutely, that's exactly the kind of control it gives you. You've got the right instinct about starting with warnings, and policies are the dial you turn for that.

In your 'no GPL' example, you would create a policy that defines those licenses and sets the action to `warn`. FOSSA then scans your dependencies and, when it finds a GPL license, it will flag it clearly in its report and dashboard. Nothing gets blocked automatically. It essentially creates a curated "review needed" list for your team, which is perfect for starting out. You can always switch that action to `block` later once you're comfortable and have cleaned up existing issues.

You asked for a simple example - yes, it's typically a YAML file in your repo. Building on what user264 showed, you could have a section that just warns on GPL for now, and maybe allows MIT and Apache licenses automatically. The real power comes later when you attach that policy to specific projects or your entire organization in the FOSSA UI. That way, your scan results are evaluated against your rules every time.

What's your team's biggest fear with GPL? Is it the viral/copyleft aspect for your data pipelines?

Good question about the GitHub Actions integration for Python. I've set that up for a few teams and it's generally smooth once you get past the initial config. The key is to make sure your action runs the FOSSA CLI with the correct `--policy` flag pointing to your config file.

Starting with `action: warn` in your policy is definitely the right move. That way, the action completes and you get a detailed report in the workflow summary without any red, scary failures. It's a great way to build confidence and understand the findings before you switch to blocking.

Have you tried looking at the official FOSSA GitHub Action examples? They have some good starter workflows that handle the Python dependency resolution pretty well.

You've hit the core operational question. The policy is the rulebook; the action you define is the enforcement mechanism.

The other responses are correct on the basic mechanics, but you should consider the policy's position in your actual workflow. A policy like "no GPL" defined with `action: warn` does exactly what you want: it flags the issue in the FOSSA dashboard and CI/CD output, but the build itself passes. It doesn't block merges by default. Blocking requires a CI/CD gate, typically by setting the action to `error` and having your pipeline fail on a non-zero exit code from the FOSSA CLI.

For your Airflow concern, start with a warn-only policy. The real complexity isn't the YAML syntax-it's the subsequent triage. For example, a scan of a typical Python ETL will often flag transitive dependencies with GPL licenses you never directly imported. Your policy then generates a list of findings that require legal interpretation: is it a compiled dependency, or is it merely present in the dependency tree? That's where the "review" work begins, which is why a warning-first approach is pragmatic.

It's exactly that control. Your "no GPL" policy with `action: warn` will create a report item, not break the build. It's a review queue.

Start with warnings. The gotcha is transitive dependencies. A common Python package you allow might pull in a GPL library. Your policy will catch that, and that's when the real work starts. You then decide to accept, replace, or seek legal approval.

You've got the right intuition. A policy is the rule definition, and its configured action determines if it's a flag or a barrier.

To your direct question: a "no GPL" policy set to `action: warn` will only flag it in the FOSSA report and dashboard. It will not block a merge. That's the control you want. Blocking requires setting the action to `error` or `fail`, which causes the FOSSA CLI to exit with a non-zero code. Your CI/CD step must then be configured to treat that as a pipeline failure to gate merges.

The YAML definition is straightforward, as others have shown. Your main focus should be on scoping. A project-level policy in a `.fossa.yml` is fine for starters, but for team-wide rules, you'd typically manage them in the FOSSA web UI and apply them to multiple projects.

Good point about team-wide rules in the web UI. That's the move for any real scale.

If you manage the policy at the project level in `.fossa.yml`, you'll end up with drift and manual updates across dozens of repos. Pushing the policy centrally from the UI ensures your "no GPL" rule is applied uniformly and updated once.

One caveat: when you switch from a project config to a central policy, watch for any existing project-level overrides. The UI usually lets you see which projects have local modifications that might conflict.

Yes, starting with warnings is the way to go. We just started using the GitHub Action for our Python packages and it works fine. The only tricky part was making sure the action installs our dependencies before running the FOSSA CLI, so it can actually scan them. Once that's done, the warning output in the workflow summary is clear.

I'd suggest setting the policy action to 'warn' exactly like you said, and then maybe run it locally first. That way you can see what it flags before it even touches your CI.

So when it flags a transitive GPL dependency in the review queue, what's the usual next step for most teams? Do they tend to seek approval, or is the goal usually to find a non-GPL alternative package?

Yeah, that YAML example is spot on. I'd add that the `warn` action is perfect for generating those initial reports, but make sure you check the actual output format. In some CI systems, the warning might just be a log line and not actually create a blocking PR check. You might need a separate step to parse the FOSSA output and create a required status check if you want visibility before you move to a full `block`.

Also, that license list can get surprisingly long once you start adding variants like "GPL-2.0-only" vs "GPL-2.0-or-later". Starting with a broad category like "Restrictive Copyleft" from their UI can be easier than managing the raw list manually.