SkillVaultskills Browse all 500 skills

Compliance · Version 1.0.0 · Reviewed 2026-08-02

Open Source License Reviewer

Make a defensible decision about obligation identification and copyleft reach with evidence, explicit trade-offs, and a verification plan.

4 method steps 5 documented failure modes 4 diagnostic checks 7 quality gates

Reviews dependency licenses for distribution obligations, copyleft reach, and attribution requirements.

₹149 one-time

Get this skill archive

What this skill helps you do

  • Obligation identification
  • Copyleft reach
  • Attribution compliance

How Open Source License Reviewer works

You provide

Requirements, data inventory, and evidence of current controls

It inspects

Requirement type and real implementation for obligation identification

It decides

A copyleft reach gap list with owners and severity

You verify

One obligation traced end to end to its enforcing system

What it checks first

Open Source License Reviewer reviews dependency licenses for distribution obligations, copyleft reach, and attribution requirements. Use it when the work involves Obligation identification, Copyleft reach, Attribution compliance.

  1. Whether an obligation is a legal requirement, a contractual commitment, or internal policy.
  2. Whether a documented control is actually implemented in the system it claims to govern.
  3. Every downstream copy of regulated data, including backups, logs, and analytics.
  4. Who is accountable for each control, since an unowned control is not a control.

Failure modes it recognizes

  • Deletion implemented in the primary store while copies persist in backups, exports, and warehouses.
  • A control described in policy with no implementation, discovered during audit.
  • A subprocessor added without an agreement or the customer notification the contract requires.
  • Retention defined but never enforced by an automated job.
  • Consent collected for one purpose and reused for another without a valid basis.

Answers it will reject

  • Treating a certification report as evidence that a specific control functions.
  • Providing a definitive legal conclusion rather than a structured analysis for qualified review.
  • Relying on contract language to mitigate a risk that is technically preventable.

Decision rules it applies

  • Map every obligation to an implemented control and its evidence, or record it explicitly as a gap.
  • Prefer technical enforcement over documented intent, because intent is not a control.
  • Escalate anything constituting legal advice to qualified counsel and say so plainly.

Evidence it asks for

  • Build a data inventory covering category, purpose, basis, location, retention, and downstream copies.
  • Trace one real request or record end to end through the control being claimed.
  • Record the artifact an auditor would accept as evidence for each control.

The method inside

  1. Map the artifact, actors, boundaries, and invariants relevant to obligation identification.
  2. Trace concrete failure or abuse paths for copyleft reach; do not report checklist items without a mechanism.
  3. Prioritize attribution compliance findings by impact, likelihood, confidence, and cost of correction.
  4. Recommend the smallest defensible change, then define how an independent reviewer can verify it.

Deliverables

  • Obligation identification assessment
  • Copyleft reach decision and action plan
  • Attribution compliance verification checklist

Evidence requirements

  • Functional and quality requirements
  • Scale, latency, consistency, cost, and compliance constraints
  • Current topology and alternatives considered

Quality gates

  • Every material claim traces to supplied evidence or is labeled as a hypothesis.
  • The response follows the declared deliverable contract.
  • No execution, access, measurement, or verification is invented.
  • Secrets and personal data are redacted rather than repeated.
  • The user receives a concrete independent verification step.
  • The relevant failure modes in this domain were considered rather than only the reported symptom.
  • No listed anti-pattern was recommended as a solution.

Example task

Input

Our legal team flagged a GPL dependency in our SaaS product. Does that actually create an obligation for us?

Expected output

For a hosted service, plain GPL generally does not trigger distribution obligations, but AGPL does, and that distinction is where teams get caught. Confirm the exact license variant and how the dependency is linked before treating this as a blocker or a non-issue...

Boundaries and compatibility

Ideal for

  • Obligation identification: produce a decision or artifact grounded in supplied evidence.
  • Copyleft reach: produce a decision or artifact grounded in supplied evidence.
  • Attribution compliance: produce a decision or artifact grounded in supplied evidence.

Out of scope

  • Producing a generic reference architecture without requirements
  • Hiding material trade-offs behind best-practice language

Agent compatibility

  • GitHub Copilot custom agents
  • Claude Agent Skills / SKILL.md
  • Any instruction-following chat model

Tool policy: Advisory by default. No tools are assumed. If the host provides tools, use read-only evidence gathering unless the user explicitly approves a scoped write or execution action.