Open Source License Compliance Gate Prompt

This prompt is designed for developers, legal engineers, and compliance teams who need a structured, reviewable assessment of license obligations, compatibility conflicts, and attribution requirements before a new dependency is merged. The primary job-to-be-done is to act as a compliance gate: it takes a proposed component, its declared license, and your product's context, and returns a machine-readable decision—pass, blocked, or needs-review—along with a detailed rationale. Use this prompt when a new open-source library, model, or dataset is proposed in a pull request, during a CI/CD pipeline check, or as part of a standard due diligence workflow for a new vendor or upstream dependency. It is not a replacement for legal advice, and it should never be the final word on complex copyleft interactions or patent grant interpretations.

The prompt is most effective when it has access to the full license text, not just the SPDX identifier. A license's practical obligations—such as notice requirements, source-distribution triggers, and attribution formats—are often in the fine print. You should wire this prompt into an application harness that retrieves the LICENSE file from the repository or package metadata and injects it into the [LICENSE_TEXT] placeholder. The prompt also requires your product's context: its distribution model (SaaS, on-prem, embedded), its own license, and any existing obligations from the dependency tree. Without this context, the model cannot assess compatibility or propagation risk. A common failure mode is feeding the prompt only a license name like "MIT" and expecting a deep analysis; the output will be shallow and unreliable. Always provide the full text.

Do not use this prompt for one-off, informal code snippets copied from forums or gists where no license is declared. In those cases, the prompt will correctly flag the absence of a license as a blocking condition, but the real-world resolution is a human decision about risk tolerance, not a prompt output. Similarly, do not use this prompt to evaluate the patent landscape or to make fair-use determinations for proprietary code; those require qualified legal analysis. The next step after reading this section is to review the prompt template, adapt the placeholders to your dependency-ingestion pipeline, and set up the evaluation checks described later in this playbook to catch copyleft propagation errors and hallucinated license terms.

This prompt template implements a compliance gate for open-source license evaluation. It is designed to be integrated into a CI/CD pipeline, a dependency review workflow, or an AI-assisted legal review queue. The prompt instructs the model to act as a compliance analyst, comparing a proposed use case against the text of a specific open-source license. The output is a strict JSON object containing a decision, a risk_level, and a structured list of obligations and conflicts. This allows your application to automatically block non-compliant actions, route ambiguous cases for human review, and log an auditable compliance record.

textCopy
You are an open-source license compliance analyst. Your task is to evaluate whether a proposed use of open-source software or AI model weights complies with the provided license text. You must be conservative. If the license terms are ambiguous or the proposed use is not clearly permitted, flag it for human review.

## INPUT
[LICENSE_TEXT]
[PROPOSED_USE_CASE]
[CONTEXT]

## CONSTRAINTS
- Base your analysis strictly on the provided [LICENSE_TEXT]. Do not infer permissions from common practice or other licenses.
- If the [PROPOSED_USE_CASE] involves distribution, modification, or integration into a proprietary product, pay special attention to copyleft clauses (e.g., GPL, AGPL) and attribution requirements.
- If the [LICENSE_TEXT] is missing, unclear, or appears to be a non-standard variant, set the decision to "NEEDS_REVIEW".
- Do not provide legal advice. Your output is a preliminary compliance assessment for a human reviewer or an automated gate.

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "decision": "COMPLIANT" | "NON_COMPLIANT" | "NEEDS_REVIEW",
  "risk_level": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
  "summary": "A one-sentence summary of the assessment.",
  "obligations": [
    {
      "type": "ATTRIBUTION" | "SOURCE_DISCLOSURE" | "LICENSE_INCLUSION" | "STATE_CHANGES" | "PATENT_GRANT" | "OTHER",
      "description": "Specific action required by the license.",
      "compliant": true | false
    }
  ],
  "conflicts": [
    {
      "clause": "The specific license clause causing the conflict.",
      "reason": "Why the proposed use violates this clause."
    }
  ],
  "human_review_required": true | false,
  "review_reason": "Explanation if human review is required, otherwise null."
}

## RISK_LEVEL
- LOW: All obligations can be met with standard tooling (e.g., adding a NOTICE file).
- MEDIUM: A copyleft license is involved, but the proposed use may not trigger its core conditions.
- HIGH: A copyleft license is involved, and the proposed use likely triggers source-disclosure obligations.
- CRITICAL: The proposed use clearly violates the license terms, or the license is incompatible with the project's overall licensing.

To adapt this prompt, replace the [LICENSE_TEXT] placeholder with the full text of the license in question, extracted directly from the repository's LICENSE file or the SPDX standard text. The [PROPOSED_USE_CASE] should be a detailed, factual description of how the software will be used, including whether it will be modified, distributed, or linked. The optional [CONTEXT] field can include the project's own license and any relevant company policy. After pasting the prompt, validate that the model's JSON output conforms to the schema before your application acts on the decision field. For high-risk use cases, always route NEEDS_REVIEW and HIGH/CRITICAL risk decisions to a human legal reviewer.

This prompt is designed to be called from a script, microservice, or workflow orchestrator that can parse the structured JSON output and act on the gate_decision field. The integration point is a simple request-response pattern: your application sends the prompt with the required inputs and receives a compliance assessment. The critical work happens after the model responds. You must treat the model's output as a signal that requires deterministic handling, not as a final decision that can be passed directly to the next step in your pipeline without verification.

Implement a JSON schema validator that checks the model's response against the expected output structure before any decision logic runs. The validator should confirm the presence and type of gate_decision (enum: pass, blocked, needs-review), license_obligations (array), compatibility_conflicts (array), and attribution_requirements (array). If validation fails, retry the prompt once with a temperature of 0.1 to reduce output variance while preserving enough flexibility to escape the malformed generation path. If the second attempt also fails validation, escalate immediately: store the malformed output, create a ticket in the legal review queue with the raw response attached, and halt the pipeline. Never attempt more than two automated retries for a compliance gate—silent failures here create regulatory exposure.

On a pass decision, log the full assessment—including the raw model response and the parsed gate decision—to your audit store with a timestamp, the input context hash, and the model version. Allow the workflow to continue. On a needs-review decision, create a ticket in the legal review queue with the complete prompt output, the input context, and a priority flag. The ticket should contain enough context for a human reviewer to make a decision without re-running the analysis from scratch. On a blocked decision, halt the pipeline immediately, notify the compliance team via your incident channel, and store the blocking rationale with the same audit traceability as a pass. The blocked path should never be silently logged; it requires active human attention. Always store the raw model response and the parsed gate decision together—never discard the raw output after parsing, as it is your evidence for audit and debugging.

For model selection, use a model with strong instruction-following and structured output capabilities. The prompt relies on the model correctly interpreting legal text and producing consistent JSON, so prefer models with proven performance on legal reasoning benchmarks. If you are using a self-hosted or open-weight model, run additional eval checks on your specific license types before trusting the gate in production. Implement a dead-letter queue for any response that cannot be parsed after retries, and monitor the rate of needs-review and blocked decisions as a leading indicator of policy drift or model behavior changes. The most common production failure mode is not a wrong decision but a malformed output that your parser silently treats as a pass—your schema validation and retry logic are your primary defenses against this.