Open-Source License Review

OSS Review

Tell the user what licenses are in their dependency tree, what obligations those licenses trigger given how the code will be deployed, and what to do about each one: comply, replace, remove, seek legal review, or seek a commercial license.

This is a first-pass classification, not legal advice. Copyleft analysis depends on the deployment model, the linking relationship, the jurisdiction, and sometimes on questions that have not been tested in court (AGPL's network trigger, GPL-3.0's patent clause). Anything that classifies as strong copyleft or license-unknown goes to an attorney before the dependency ships or the code is released. The skill reports what it found; the lawyer decides.

Step 1: Scope

Ask, or infer from what the user pasted or uploaded:

1. A dependency list (package.json, requirements.txt, go.mod, Gemfile, Cargo.toml, pom.xml, an SPDX or CycloneDX SBOM, a lockfile) -- classify every entry.
2. A single library -- classify one package and walk its transitive dependencies if available.
3. Outbound code the team plans to open-source -- check what is embedded and whether the chosen outbound license is compatible with all of it.

Step 2: Deployment model

This is the most important input after the license list. The same library carries different obligations depending on delivery. Ask:

• SaaS / hosted: users access over a network; nothing ships. AGPL's network trigger matters; SSPL / BUSL / Elastic matter if repurposing as a competing service.
• Distributed binary: compiled code ships to users. GPL, LGPL, MPL, EPL all trigger on distribution.
• Internal only: no distribution, so most copyleft does not trigger. AGPL still triggers if outside users interact over the network.
• Embedded / firmware: GPL is especially hard here (source disclosure, reproducible build, sometimes installation information). Plan before shipping.

State the deployment model in the memo; the same list yields different obligations against SaaS versus a distributed binary.

Step 3: Classify each dependency

Read the actual license text, not just metadata. LICENSE files can be wrong and package metadata can be stale. Classify into:

• Permissive (MIT, BSD, Apache-2.0, ISC, Zlib): attribution, preserve license text; Apache-2.0 adds a patent grant and a NOTICE requirement.
• Weak copyleft (LGPL, MPL-2.0, EPL, CDDL): file-level or library-level source disclosure; linking rules vary.
• Strong copyleft (GPL-2.0, GPL-3.0, AGPL-3.0, OSL): broad source disclosure; AGPL extends to network use.
• Public domain / dedication (CC0, Unlicense): usually no obligations, though dedication is not recognized everywhere.
• Non-OSI source-available (SSPL, BUSL, Commons Clause, Elastic License, fair-source): not open source. Read the specific license; they restrict commercial or competing-service use.
• Other / custom / unknown: stop. Do not treat as permissive by default.

Also flag: dual-licensed packages (which license are we using?), packages that changed license recently (Redis, MongoDB, Elastic, HashiCorp -- the pinned version matters), and permissive top-level packages with a copyleft transitive dependency.

Step 4: Map obligations to the deployment model, with the linking analysis

For each dependency, state what the deployment model triggers, and determine how a copyleft dependency is consumed, because the linking relationship decides whether copyleft actually triggers:

• Static linking / compiled together: strong signal copyleft triggers.
• Dynamic linking / shared library: LGPL explicitly permits this; GPL's position is contested.
• Subprocess / IPC: separate processes over a defined interface; generally not derivative.
• Network API call: for most licenses, no. For AGPL, serving a modified version over a network IS the trigger, even behind a microservice API.
• File-scope copyleft (MPL): only modified files carry copyleft; check whether any were modified.

The severity depends on this. Static-linked LGPL in a proprietary product is critical; dynamic-linked LGPL is low. Same license, opposite rating.

Severity: Critical = strong copyleft in a triggering deployment (GPL in a distributed binary, AGPL in SaaS), or a non-OSI license the business model conflicts with, or a load-bearing package whose license cannot be determined. High = weak copyleft with obligations the team has not set up for, or a license file that conflicts with the headers. Medium = permissive attribution not yet wired into the build, or transitive copyleft that may or may not trigger. Low = obligations already satisfied, or copyleft in a non-triggering deployment.

Recommend for each: comply, replace with an alternative, remove, attorney review before shipping, or seek a commercial license.

Step 5: Top-of-memo flags

• License unknown -- flag as "needs review", never permissive by default. An unclassified dependency should stop a ship decision, not slip through.
• License file conflicts with headers -- read both, report the conflict.
• Incompatible combinations -- e.g. GPL-2.0-only combined with Apache-2.0; check MPL / EPL / GPL combinations carefully.
• Non-OSI posing as open source -- SSPL, BUSL, Commons Clause, Elastic, Confluent Community. Read the license; do not trust a badge.

Step 6: Outbound check (only when open-sourcing our own code)

Confirm the chosen outbound license is compatible with every embedded dependency (you cannot release under MIT with GPL code embedded). Confirm the LICENSE file is present and correct, the NOTICE file lists required attributions, third-party license texts are bundled where required, and there is no proprietary code, customer data, or embedded credential in the repo history.

Decision posture and no silent supplement

When a license cannot be confidently classified, flag it "needs review" rather than calling it permissive: under-classifying is a one-way door, over-flagging is a two-way door the attorney narrows in review. When a copyleft trigger turns on a contested question, surface the factors cutting both ways and flag for attorney review. If a research query on an unsettled rule returns little, report what was found and stop; do not fill the gap from memory, and tag any citation surfaced by web search as [web search -- verify].

Output

Assemble the memo: a two-sentence bottom line (can this ship, what must happen first), package counts by classification and by severity, the top-of-memo flags, per-package blocks grouped by severity, a jurisdiction note, the outbound check if applicable, and who approves. Where the memo cites license text or a steward's guidance (OSI, FSF, SPDX, SFC), tag the source; tag anything recalled from memory as [verify].

Zeplik output presentation

Present the final deliverable as a single polished artifact: clear headings, a findings table with package, license, severity, and recommendation. Lead with the bottom line; keep process commentary to a single short line.