# Build a monthly open source license compliance register

> On the first of every month, get a reviewed list of every risky open source license in your code, with plain English notes on what each one obliges you to do.

- Workflow type: agent
- Services: Snyk, Google Sheets, Slack
- Categories: Operations, Engineering
- Published: 2026-08-09

## What it does

- Takes a full inventory of every open source package your projects rely on, along with the license attached to each one.
- Flags the licenses that can create real obligations for a commercial product, such as GPL, AGPL, and LGPL, the family often called copyleft because they can require you to share your own code back.
- Explains in plain English why each flagged package matters, including whether it ships to customers or only runs on your own machines, so counsel gets a prioritized list instead of a wall of license names.
- Adds one row per flagged package to a spreadsheet register and posts a Slack summary of what changed since last month.

## What you'll need

- A Snyk account with your projects already connected and being scanned
- A Google Sheets spreadsheet to hold the register
- A Slack workspace, and a channel where legal and engineering can both see the summary

## Prompt

On the first day of every month at 7am, build an open source license compliance register for our codebase, so that legal is never caught out during a customer security review or funding diligence.

Start in Snyk. Use List dependencies (v1) to inventory every package across our projects along with the license attached to each one. That is the org wide inventory view with filters and sorting, so it is the right starting point for a complete register. Where you need deeper detail for a particular project, pull Get a project's SBOM document for that project, which carries license metadata per component. Use List all Projects for an Org first if you need the project IDs.

Flag every dependency carrying a copyleft or otherwise restrictive license. That means the GPL family, AGPL, and LGPL, plus comparable licenses such as SSPL, MPL, EPL, CDDL, and any source available license with commercial restrictions. For each flagged dependency, record the package name and version, the license, which project pulls it in, and whether it arrived as a direct dependency we chose or a transitive dependency pulled in by something else.

The real work here is the reasoning, not the label. For every flag, write two or three sentences of plain English explaining whether this license combined with the way we actually use the package creates an obligation for a commercial product, and why. Weigh things like: whether the package ships inside software we distribute to customers or only runs on our own servers; whether it is a development, test, or build time dependency that never reaches a customer; whether AGPL network use terms are triggered because we offer the software as a hosted service; whether LGPL is dynamically linked, which is usually fine, or statically linked, which is far more likely to create obligations; and whether the real exposure is source disclosure or merely an attribution and notice requirement. Say plainly when a flag is low risk and why it is low risk. Do not simply print the license name and leave counsel to work it out, and do not present any of this as legal advice. The register exists to give counsel a prioritized, explained list to review.

Before writing anything, read the existing register with Get Values so you know what was already recorded. Compare this month against last month so you can tell what is newly introduced, what disappeared because a dependency was removed or upgraded to a differently licensed version, and what is carried over unchanged.

Append one row per flagged dependency to the register in Google Sheets using Append Values. Each row should carry the run date, package name and version, license, the Snyk project it appears in, direct or transitive, the plain English reasoning, a risk level of high, medium, or low, whether it is new since last month, and a suggested next step such as review before the next release, replace with a permissively licensed alternative, or no action needed.

Finish by sending a Slack message with Send a Message to the channel legal and engineering share. Summarize what changed since last month in a few lines: how many flagged dependencies are in the register now, what is newly introduced, and what has cleared. Call out any newly introduced restrictive license by name, with one line on why it matters and which project it landed in, and lead with anything genuinely high risk. If nothing changed, say so in a single line rather than repeating the whole register, and link to the spreadsheet so anyone can open the detail.

## How to customize

- Change the schedule if you would rather run this quarterly, or on demand ahead of a funding round or a customer security review.
- Adjust which licenses count as restrictive. Some teams also track permissive licenses that still require an attribution notice in the product.
- Pick who gets the Slack summary, or route the high risk findings to a separate channel so they are not missed.

## FAQ

### Does this replace a lawyer?

No. It gives your legal team a prioritized, explained list to review, so their time goes to the handful of packages that actually matter rather than to reading thousands of license names. Think of it as the prep work, not the legal opinion.

### What does copyleft actually mean?

Copyleft licenses, like the GPL and AGPL families, generally say that if you distribute software built on top of them, you have to make your own source code available under similar terms. That is harmless for many internal uses and a serious problem for others, which is exactly why every flag comes with an explanation rather than just a license name.

### Will it catch packages we never chose ourselves?

Yes, and those are usually the risky ones. Most surprising licenses arrive inside packages that came bundled with something else your team installed. The register notes for each one whether you picked it directly or it came along for the ride.

### What do I need in Snyk for this to work?

An account with your projects connected and scanned. The license information comes from the same dependency scan Snyk already runs, so if you can see your projects listed in Snyk today, you have what you need.

### What happens in a month when nothing changed?

The Slack summary says so in a single line instead of repeating the whole register, and the spreadsheet still keeps a dated record you can hand to an auditor or an investor later.

Use this prompt in General Input: https://www.generalinput.com/prompts/build-a-monthly-open-source-license-compliance-register