github-legal · diff
git:20260509.b2d3e98 to git:20260921.a2e8de7
92 added, 213 removed. Audit A to A.
---
name: github-legal
- description: GitHub legal compliance — generate LICENSE, SECURITY.md, CITATION.cff, NOTICE; handle fork attribution and dependency compatibility.
+ description: Review repository licenses, provenance, upstream notices, dependency licensing questions, security reporting, and optional citation metadata. Prepare scoped changes without declaring legal clearance.
---
- # GitHub Legal -- License, Compliance, and Security Policy
-
- ## Deterministic Entrypoint
-
- For API agents and non-interactive runs, use the deterministic legal runner:
-
- ```bash
- python3 scripts/run_headless.py legal --path /path/to/repo
- python3 scripts/run_headless.py legal --path /path/to/repo --write-files
- python3 scripts/run_headless.py legal --path /path/to/repo --write-files --license MIT
- ```
-
- This writes:
-
- - `.github-audit/legal-data.json`
- - `.github-audit/output/<repo>-<timestamp>/LEGAL-REPORT.md`
- - `.github-audit/output/<repo>-<timestamp>/LEGAL-PLAN.md`
- - `.github-audit/output/<repo>-<timestamp>/LEGAL-SUMMARY.json`
-
- By default this is a plan-only pass. `--write-files` is the explicit approval
- gate for writing `LICENSE`, `SECURITY.md`, `CITATION.cff`, and `NOTICE`.
- Complex or ambiguous legal situations must be flagged for human review instead
- of being guessed.
-
- ## Disclaimer -- ALWAYS Include in Output
-
- This tool provides best-effort compliance assistance for common open source licensing
- scenarios on GitHub. **It is NOT legal advice.** The output of this skill does not
- constitute a legal opinion and should not be relied upon as such.
-
- Users are responsible for their own due diligence. For complex licensing situations
- (dual licensing, contributor license agreements, patent disputes, commercial use of
- copyleft code, trademark issues), consult a qualified attorney.
-
- **Include this disclaimer at the top of every output:**
- ```
- > This analysis is automated compliance assistance, not legal advice.
- > Always verify licensing decisions with your own due diligence.
- > For complex or high-stakes situations, consult a qualified attorney.
- ```
-
- ## Process (GARE Pattern)
-
- ### 1. Gather
-
- **Step 0 -- Check shared data cache:**
- Before gathering, check `.github-audit/` for cached data from other skills.
- Reference: `github/references/shared-data-cache.md` for schemas.
-
- - `repo-context.json` (optional) -- repo type, intent, is_fork flag. If missing,
- gather yourself via `gh repo view`.
-
- - Read existing LICENSE file (if any)
- - **Fork and upstream detection (two checks):**
- 1. GitHub fork flag: `gh repo view --json isFork,parent`
- 2. **Upstream project scan** -- even if GitHub says `isFork: false`, scan the
- README and repo description for upstream signals:
- - "powered by [project]", "built on [project]", "based on [project]"
- - "fork of [project]", "[project] distribution", "[project]-powered"
- - "wrapper around [project]", "extends [project]"
- - Config files that reference another project (e.g., wezterm.lua in a
- terminal project means WezTerm is upstream)
- If upstream is detected, treat it like a fork for compliance purposes:
- fetch the upstream repo's LICENSE and check obligations.
- **This catches projects like BenjaminTerm (WezTerm distro) that aren't
- GitHub "forks" but still have upstream license obligations.**
- - If fork or upstream detected, read upstream LICENSE and NOTICE files
- - Scan dependency manifests for license compatibility:
- - package.json, setup.py, pyproject.toml, Cargo.toml, go.mod, requirements.txt,
- Gemfile, pom.xml, build.gradle, composer.json, Package.swift, *.csproj
- - If no manifest files exist, scan the README for dependency mentions (e.g.,
- `pip install X`, import statements, "requires X") and note their licenses
- - Check for existing SECURITY.md, CITATION.cff, NOTICE
- - Check for vendored/copied code: look for third-party directories (vendor/,
- third_party/, lib/external/) and check if they have their own LICENSE files
- - Get user intent from orchestrator context
-
- ### 2. Analyze
-
- - Is the current license appropriate for the user's intent?
- - **Fork/upstream compliance (both GitHub forks AND detected upstream projects):**
- - Does the current license comply with upstream?
- - Is the upstream copyright preserved?
- - Are there NOTICE file obligations?
- - For non-fork upstream projects: is the relationship acknowledged in LICENSE
- or README? (e.g., "Based on WezTerm, licensed under MIT")
- - Are there dependency license conflicts?
- - Is SECURITY.md present and adequate?
- - Is CITATION.cff present? **CITATION.cff is a default deliverable** -- generate it
- for every repo unless the user explicitly declines. It costs nothing, takes 10 seconds
- to generate, and enables GitHub's "Cite this repository" button. Academic intent is not
- required -- any project benefits from a machine-readable citation file. The audit scores
- it, so skipping it leaves free points on the table.
- - **Vendored code check:** Do any third_party/vendor directories have their own
- licenses that conflict with the project license?
- - **Edge case flags** -- flag these for the user's attention (do not attempt to
- resolve them, recommend consulting an attorney):
- - Dual licensing situations
- - CLA (Contributor License Agreement) requirements from upstream
- - Trademark usage (e.g., using upstream project's name in your project name)
- - AGPL/network copyleft implications for SaaS deployment
- - License header requirements in individual source files (GPL, Apache)
-
- ### 3. Recommend
+ # GitHub licensing, provenance, and security policy
- **Start every recommendation output with the disclaimer block (see above).**
+ Collect verifiable facts and prepare appropriate repository files. This workflow
+ provides licensing assistance, not a legal opinion. Explain specific unresolved
+ legal questions and seek qualified review where they materially affect a decision.
- Every recommendation must cite its source:
- - "Based on your intent (open source community), MIT is recommended for maximum adoption"
- - "Based on upstream license (Apache 2.0), you must maintain the NOTICE file"
- - "Based on dependency analysis, your GPL dependency requires your project to be GPL-compatible"
- - "Upstream project detected: [project] is licensed under [license] -- your project
- must comply with those terms"
+ ## Runtime and scope
- Reference: Read `github/references/license-guide.md` for compatibility matrix and fork obligations.
+ Resolve **GITHUB_HOME** from this skill directory: `../../github` in source,
+ `../github` when installed. Verify `scripts/run_headless.py` exists and read
+ `GITHUB_HOME/references/portable-workflows.md`. Resolve **TARGET** separately.
- **When edge cases are detected, flag them clearly:**
- ```
- > REQUIRES HUMAN REVIEW: [description of the edge case]
- > This situation is beyond automated analysis. Consult a qualified attorney.
+ ```text
+ python "<GITHUB_HOME>/scripts/run_headless.py" legal --help
+ python "<GITHUB_HOME>/scripts/run_headless.py" legal --path "<TARGET>"
+ python "<GITHUB_HOME>/scripts/run_headless.py" legal --path "<TARGET>" --write-files --license MIT
```
- Do NOT attempt to resolve ambiguous or complex legal questions. Flag them, explain
- why they're complex, and recommend professional review. Better to say "I don't know,
- get a lawyer" than to give wrong advice.
+ The final example is appropriate only when MIT is the established license choice;
+ it is not a recommendation for every repository. The planning command writes
+ `legal-data.json`, `LEGAL-REPORT.md`, `LEGAL-PLAN.md`, and `LEGAL-SUMMARY.json`.
+ Review planned files before `--write-files`; use targeted edits when a plan
+ would select an unapproved license or add unwanted citation/security files.
- ### 4. Execute (with user approval)
+ ## Gather provenance before conclusions
- **Confirmation gate -- STOP and present before writing any files:**
- After completing the Recommend step, present the user with:
- 1. A summary table of files that will be created or modified
- 2. The specific changes (e.g., "Add modification copyright to LICENSE")
- 3. Any placeholders they'll need to fill in
+ - Read complete existing LICENSE/COPYING/NOTICE files and relevant source headers.
+ Preserve both original and modification notices; do not replace an upstream
+ copyright holder with the current repository owner.
+ - Inspect fork/parent metadata and Git remotes when available. Also inspect
+ README credits, vendored directories, copied templates, assets, and source
+ headers. A repository may reuse upstream material without being a GitHub fork.
+ - Distinguish a runtime dependency, linked library, wrapper, vendored copy,
+ modified derivative, and independently implemented integration. A README
+ saying "powered by" is a provenance lead, not proof of a particular obligation.
+ - Read manifests and lockfiles without executing package setup scripts. Resolve
+ licensing for actual package versions and vendored source where practical;
+ missing metadata means **unavailable**, not "compatible" or "unlicensed".
+ - Identify distribution context and the owner's existing license policy. Private
+ use, source distribution, binaries, hosted services, data, docs, models, and
+ artwork can raise different questions. Do not impose one license across all
+ material without checking the applicable rights.
+ - Inspect effective SECURITY.md and CITATION.cff locations and inherited policies.
+ Gather maintained support versions and verified contact channels.
- Wait for the user to confirm before proceeding. If running inside the
- orchestrator (`github` or `github-audit`), skip the confirmation gate
- and proceed -- the orchestrator has already obtained user consent.
+ ## Analyze narrowly and cite sources
- **Author info for CITATION.cff:** Pull the author name from `git config user.name`
- first. If not set, use the GitHub username from `gh api user --jq .name`. If neither
- is available, use the repo owner's login as a fallback and note it as a placeholder.
+ | Question | Evidence needed | Avoid |
+ |---|---|---|
+ | Does the stated license match the files? | Exact license text, manifest SPDX expression, README links | Treating GitHub detection as legal clearance |
+ | Are notices preserved? | Actual upstream terms and supplied NOTICE/header text | Assuming every dependency needs the same notice |
+ | Can a new license be selected? | Ownership, contributor/upstream terms, intended policy | Inferring consent from repo control or git author config |
+ | Is a dependency a conflict? | Version, license expression, use/linking/distribution context | Declaring incompatibility from a package name alone |
+ | Is vulnerability reporting usable? | Confirmed private channel, supported versions, policy | Invented email addresses or response guarantees |
+ | Is citation metadata useful and accurate? | Research/user need, verified authors/version/date | Generating it for checklist points |
- **Write to shared data cache** after generating legal files:
- ```bash
- mkdir -p .github-audit
- grep -qxF '.github-audit/' .gitignore 2>/dev/null || echo '.github-audit/' >> .gitignore
- ```
- Write `.github-audit/legal-data.json` with: timestamp, license_type, license_file_exists,
- license_file_path, security_md_exists, security_md_path, citation_cff_exists,
- notice_file_exists, is_fork, fork_compliant, dependency_conflicts array.
- Reference: `github/references/shared-data-cache.md` for exact schema.
+ Consult `GITHUB_HOME/references/license-guide.md` for topics to inspect, and verify
+ any consequential interpretation against the actual license text and current
+ primary sources. Historical compatibility tables are not definitive. Preserve
+ SPDX alternatives/conjunctions rather than collapsing them to one guessed license.
- - Generate LICENSE file with correct year and copyright holder
- - Generate SECURITY.md with supported versions and reporting process
- - **Generate CITATION.cff by default** -- always include in the deliverables table.
- Only skip if the user explicitly says they don't want it. Do not skip silently.
- If the user hasn't mentioned it, generate it and include it in the confirmation gate.
- Pull version from latest git tag or `gh release list`. Pull date from today's date.
- Pull author from `git config user.name` or `gh api user --jq .name`.
- - Generate NOTICE file if Apache 2.0
- - Fix fork attribution if needed
+ Flag material uncertainty around relicensing, missing permissions, patent or
+ trademark terms, contributor agreements, mixed licenses, and copyleft scope.
+ Describe the unresolved fact and affected action. Continue independent notice or
+ documentation repairs instead of blocking the entire task.
- ## License Selection by Intent
+ Do not choose a license from a generic "business means Apache" or "hobby means
+ MIT" table. If license selection is requested and unspecified, explain relevant
+ tradeoffs and obtain the owner's decision before applying it. An existing,
+ explicitly requested license correction does not need another approval.
- | Intent | Default | Reasoning |
- |--------|---------|-----------|
- | Open Source Community | MIT | Maximum adoption, minimal friction |
- | Professional Portfolio | MIT | Simple, universally understood |
- | Business / Brand | Apache 2.0 | Patent protection for enterprise users |
- | Internal to Public | Apache 2.0 | Patent grant protects company and users |
- | Academic / Research | MIT or BSD-3 | Academic tradition, simple attribution |
- | Hobby / Learning | MIT | Simplest option |
- | Keep forks open | GPL v3 | Copyleft ensures derivatives stay open |
- | SaaS / Server app | AGPL v3 | Copyleft covers network use (prevents closed SaaS forks) |
- | Library used by proprietary code | LGPL v3 | Linking exception lets proprietary apps use it |
- | Balanced copyleft | MPL 2.0 | File-level copyleft (modified files stay open, new files can be anything) |
- | Public domain / no restrictions | Unlicense or CC0 | Maximum freedom, zero obligations |
- | Documentation / data | CC BY 4.0 or CC0 | Creative Commons designed for non-code content |
- | Source-available commercial | BSL 1.1 | Visible source but not free to compete with; converts to open after delay |
+ ## Prepare useful files
- **When upstream exists:** The upstream license constrains your options. You cannot
- choose a less permissive license than what the upstream allows. Examples:
- - Upstream is MIT → you can use MIT, Apache, GPL, AGPL, or anything else
- - Upstream is GPL v3 → you MUST use GPL v3 (or later). You cannot use MIT or Apache.
- - Upstream is Apache 2.0 → you can use Apache 2.0, GPL v3, or AGPL v3 (not MIT,
- because Apache has patent grant terms that MIT doesn't preserve)
+ ### License and notices
- ## Fork and Upstream Compliance Checklist
+ Use the approved license's canonical text and verified holder information.
+ Retain upstream text and obligations; add modification credit only when accurate.
+ Preserve third-party notices in their appropriate locations. A README credit is
+ not automatically a substitute for notices required by the applicable terms.
- When the repo is a fork OR has a detected upstream project:
- - [ ] Original license preserved in LICENSE file
- - [ ] Original copyright notice preserved
- - [ ] Your copyright added below original (format: "Copyright (c) YEAR NAME (modifications)")
- - [ ] NOTICE file preserved (if Apache 2.0)
- - [ ] Changes documented (if required by license -- GPL and Apache require this)
- - [ ] License compatibility verified with any new dependencies
- - [ ] Upstream relationship acknowledged in README (for non-fork upstream projects)
- - [ ] Your chosen license is compatible with the upstream license (see matrix above)
+ ### SECURITY.md
- ## SECURITY.md Template
+ Document a confirmed reporting channel, information reporters should supply,
+ actual supported versions, and the maintainer's stated disclosure policy. Avoid
+ asking for public vulnerability details when a private channel exists. Do not
+ publish personal contact data inferred from commits, invent SLAs, or label all
+ historical releases supported without evidence.
- Generate based on:
- - Current release versions (from `gh release list`)
- - Project contact info (from git config or user input)
- - Severity-based response timelines
+ ### CITATION.cff
- ## CITATION.cff Template
+ Create or update it when citation serves the project or the user requests it.
+ Use verified author/project-entity information; the local committer need not be
+ the author. Use actual release dates, not today's date as a substitute. Omit
+ optional unknown fields and list essential unknowns in a draft.
```yaml
cff-version: 1.2.0
- message: "If you use this software, please cite it as below."
+ message: "If you use this software, please cite it using these metadata."
type: software
- title: "[Project Name]"
- version: "[version]"
- date-released: "[YYYY-MM-DD]"
+ title: "Verified project title"
authors:
- - family-names: "[Last]"
- given-names: "[First]"
- orcid: "https://orcid.org/XXXX-XXXX-XXXX-XXXX" # optional
- url: "https://github.com/[owner]/[repo]"
- license: "[SPDX-ID]"
+ - name: "Verified project team"
```
- ## Output
-
- - Files generated/updated (with diff preview)
- - Compliance status: PASS / FAIL with specific issues
- - Fork compliance: PASS / FAIL / N/A
- - Dependency license conflicts: list any found
-
- ### Next Step
+ This is an illustrative draft, not ready-to-publish metadata. Add verified URL,
+ version, date, SPDX expression, DOI, or ORCID only when appropriate. Validate
+ against the current CFF schema when generating a real file.
- After completing legal fixes, always end with this handoff:
+ ## Apply, verify, and report
- ```
- Legal fixes complete. Next recommended step:
- github-community -- set up community health files and templates
- ```
+ Apply requested local changes after reviewing the diff/plan. Do not add a second
+ confirmation merely because the skill is invoked directly. Keep unresolved
+ license choices out of applied changes.
- If running as part of the audit SOP (the user ran `github-audit` first and is
- following the Recommended Next Steps table), reference the step number:
- "Step 1 complete. Next skill: `github-community`"
+ Verify notices were retained, license links resolve, SPDX metadata matches the
+ actual files, citation syntax/schema is valid, and reporting channels are real.
+ A successful generated-file write is not a compliance determination.
+ Report changed paths, confirmed facts and sources, **observed** results,
+ **unavailable** evidence, **not_applicable** checks, and specific questions left
+ for the owner or legal reviewer. Preserve runtime cache contracts; place extra
+ analysis in the report instead of falsifying a PASS/FAIL scalar.