Build a monthly open source license compliance register

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.