eclipse-license-check

Files (11)

• SKILL.md
• evals.json · evals/
• .gitignore · evals/files/
• go.mod · evals/files/fastbelt-go/
• go.sum · evals/files/fastbelt-go/
• package-lock.json · evals/files/langium-npm/
• package.json · evals/files/langium-npm/
• package.json · evals/files/sprotty-yarn/
• yarn.lock · evals/files/sprotty-yarn/
• dash-license-tool.md · references/
• intellectual-property.md · references/

SKILL.md (first lines)

# Eclipse Dependency License Check

Vet the project's third-party dependencies with the [Eclipse Dash License Tool](https://github.com/eclipse-dash/dash-licenses). The **`restricted`** list in the summary CSV is the deliverable — what still needs IP Team attention before a formal release.

Load references only when a pointer below fires:

- `references/intellectual-property.md` — scope questions ("do I need to vet X?", platform boundary, test/build exemptions, manual IPLab issue format).
- `references/dash-license-tool.md` — before invoking the tool (install, flags, per-ecosystem recipes, errors, CI).

## Optional inputs

1. **A local clone of `eclipse-dash/dash-licenses`** — use it when given; otherwise download the released CLI jar per `references/dash-license-tool.md`.
2. **An IPLab access token** — a `gitlab.eclipse.org` personal access token with `api` scope. Needed only to file IPLab review requests automatically. Treat the token as a secret; see "Handling the IPLab token" below.

If neither was mentioned, proceed with the released jar and without filing reviews — do not prompt.

## Preflight: preparing a local Dash License Tool clone

If the user provided a clone path, prepare it before any check runs. The user may have work in progress, so **do not modify unfamiliar state**.

1. Inspect: `git -C <path> status --porcelain` and `git -C <path> rev-parse --abbrev-ref HEAD`.
2. **Clean tree on `master`**: if `shaded/target/org.eclipse.dash.licenses-*.jar` already exists, use it directly. Otherwise `git -C <path> pull --ff-only`, then `mvn -f <path> -DskipTests clean install`. The `install` goal places both the CLI jar and the Maven plugin into `~/.m2` so later invocations resolve them locally. Drop `-DskipTests` only to validate the tool itself — the suite hits external services and adds minutes.
3. **Only IDE/OS noise dirty** (e.g. `.DS_Store`, modifications under `.settings/` which Eclipse IDE auto-edits on project open, `.idea/`): none of this is real WIP. Offer to discard those paths and continue as in step 2; don't act unilaterally.
4. **Anything else** (modified source/build files, untracked code, other branch, detached HEAD): report what was observed and ask how to proceed.

After a successful build, use the **shaded** jar at `shaded/target/org.eclipse.dash.licenses-<version>.jar` (read `<version>` from the build output — typically `<x.y.z>-SNAPSHOT` on a master clone). The thin jar in `core/target/` is `...licenses.core-<version>.jar` and lacks transitive deps, so it fails at runtime with `NoClassDefFoundError`. Alternatively invoke the now-installed Maven plugin as `org.eclipse.dash:license-tool-plugin:license-check`.

**Done when** a runnable jar or installed Maven plugin is confirmed; otherwise stop and report.

## Handling the IPLab token

The Dash License Tool only accepts the token as a CLI argument — there is no env-var or stdin path — so the token value must reach the command line. The agent's handling of the value is the security boundary.

**If the user pastes the token directly into the prompt** — stop before running anything. The token is now in the conversation transcript, which may be persisted, logged, or replayed. Tell the user to:

1. Revoke that token at https://gitlab.eclipse.org/-/user_settings/personal_access_tokens.
2. Mint a new one and provide it via the harness's secret-handling mechanism if one exists, or otherwise via an environment variable (e.g., `export IPLAB_TOKEN=...` in the shell that launches the agent).

Do not proceed using the pasted value.

**Otherwise**, expect the token to live in an environment variable — default to the name `IPLAB_TOKEN` unless the user named a different one — and reference it by name on the command line, never substituting in the value:

- CLI: `-token "$IPLAB_TOKEN"`
- Maven plugin: `-Ddash.iplab.token="$IPLAB_TOKEN"`

If the agent harness has a built-in secret/credential mechanism (an injected env var, a secret-resolution step, etc.), prefer that over a plain shell variable.

Before running, confirm the variable is set in the same shell that will run the tool (`[ -n "$IPLAB_TOKEN" ]` — do not print the value). A token exported in another terminal won't be visible here. Never echo, log, write to a file, or commit the token. Do not include it in the summary reported back to the user.

## IPLab review filing

The `-review` flow files real GitLab issues against `eclipsefdn/emo-team/iplab` that the Eclipse IP Team acts on — a public, irreversible action. Choose based on explicit user intent (see `references/dash-license-tool.md` § Filing automatic IP review requests):

- **User wants reviews AND provided a token** → enable filing (flags below).
- **User has said no reviews** → never pass `-review`. Restricted content still appears in the summary.
- **Intent unclear** → ask before running. Do not silently default.

The Eclipse project ID (e.g., `technology.dash`, `ecd.theia`) is required for `-review`. Ask if not supplied — do not guess from directory or repo names.

**When filing is enabled**, append to every invocation:

- CLI: `-review -token "$IPLAB_TOKEN" -project <project-id>` (and `-repo <url>` when known)
- Maven plugin: `-Ddash.iplab.token="$IPLAB_TOKEN" -Ddash.projectId=<project-id>` (and `-Ddash.repo=<url>` when known)

Derive `-repo` / `-Ddash.repo` from `git remote get-url origin`, converting SSH forms like `git@github.com:org/repo.git` to `https://github.com/org/repo`. See "Handling the IPLab token" for how the token value reaches the command. For CLI runs, capture stdout — IPLab issue URLs print there, not in the CSV. At most five issues are filed per invocation; re-run if more `restricted` entries remain (see `references/dash-license-tool.md` § Filing).

## Running the check

Each **dependency graph** gets its own run and summary CSV — root manifest first, then any nested graphs the root run didn't cover.

1. **Root** — identify the ecosystem from manifest files at the project root and follow the matching subsection below. Run from that directory (or pass absolute paths).
2. **Nested graphs** — Open source repos often ship more than one ecosystem (Go library + VS Code extension, Java core + npm website). After the root run, find additional lockfiles not yet checked:
   ```bash
   find . \( -name package-lock.json -o -name yarn.lock -o -name pnpm-lock.yaml -o -name go.sum -o -name Cargo.lock \) \
     -not -path '*/node_modules/*' -not -path '*/vendor/*' -not -path '*/.git/*'
   ```
   Skip the lockfile already fed in step 1. Run each remaining lockfile from its directory with a distinct `-summary` name (e.g. `DEPENDENCIES-vscode`), using the matching ecosystem subsection below.

Always pass `-summary <path>`; pick a name that won't collide with tracked files (some Eclipse projects commit a `DEPENDENCIES` file). When IPLab filing is enabled, append flags per "IPLab review filing" above.

**Done when** a summary CSV exists for every discovered dependency graph. Non-zero exit code equals the restricted count (capped at 126) — that is success with findings, not a tool failure. Continue to "Reporting findings".

### TypeScript / JavaScript (npm, yarn, pnpm)

**Trigger**: a `package.json` in the directory being checked (root or nested).

The tool parses `package-lock.json`, `yarn.lock`, and `pnpm-lock.yaml` natively — feed the lock file directly:

```bash
java -jar <dash-jar> -summary DEPENDENCIES package-lock.json
# or yarn.lock, or pnpm-lock.yaml
```

**No lock file**: dependencies aren't pinned, so a meaningful check isn't possible. Ask the user to run `npm install` / `yarn install` / `pnpm install` first. Don't run against `package.json` alone.

**Multiple lock files**: a misconfiguration. Ask which package manager is authoritative — running both double-counts.

**Lock file freshness**: assume up to date. Only regenerate if the user says it's stale.

**Yarn parser caveat**: the native `yarn.lock` parser is fragile (the format is undocumented). If the run errors, returns suspiciously few entries, or the user reports a recent yarn version, fall back to the `yarn info -R --name-only` pipeline in `references/dash-license-tool.md` § Yarn (when the lockfile parser fails).

**Workspace coverage**: only deps reachable from the lock file you pass are checked. In a monorepo, the root lock file covers every package listed in `workspaces` (or `pnpm-workspace.yaml`); sibling packages outside that list keep their own graphs and need separate runs. Workspace members linked via `file:` or `workspace:` are not registry coordinates — they won't appear in the summary; only published third-party deps are vetted.

**Triaging restricted entries**: lock files mix runtime, dev, and transitive deps without preserving that context, so the tool vets them all. When a restricted entry surfaces, recover the context the user needs to act on it:

- Parse the CSV identifier to a package name: `npm/npmjs/-/name/version` → `name`; `npm/npmjs/@scope/name/version` → `@scope/name`.
- Run `yarn why <pkg>` (or `npm ls <pkg>` / `pnpm why <pkg>`) to trace the chain — the entry may be transitive and absent from any `package.json`.
- For direct entries, grep the root `package.json` plus every workspace package's `package.json` to find which key (`dependencies` / `devDependencies`) declares it.

Surface both in the report. The Eclipse exemption hinges on whether the content is **distributed** via an `eclipse.org` property — not on the JSON key alone (see `references/intellectual-property.md` § Test and build dependencies). A `devDependency` used only at build time qualifies; so does a `dependency` of an example or demo the project never publishes. Conversely, a `devDependency` that ends up bundled into a shipped artifact does need review.

**Upstream-project content**: when a `restricted` entry is from the same organization as the repo under review, or from another Eclipse Foundation project — npm packages like `langium`, `theia`, `sprotty`, or a sibling module like `typefox.dev/lsp` in a TypeFox repo — the cause is usually a missing Dash Database entry for that exact coordinate, not a real licensing problem. The tool has no org-ownership lookup for npm or Go (Maven projects sidestep Eclipse deps with `-DexcludeGroupIds=org.eclipse`; npm has no such prefix convention). Let `-review` file the IPLab issue anyway and explain in the report that the IP Team typically closes these as already-vetted under the upstream project's own IP review; that resolution itself adds the coordinate to the Dash Database, so future runs return `approved`.

**Extension publish tooling**: `@vscode/vsce-sign-*` platform packages at the same version are signing binaries for `vsce package` — a single cohort, usually build-only. Same for `@azure/msal-*` and `@textlint/*` cohorts pulled in transitively by `vsce` / `ovsx`.

### Java (Maven, p2 / Tycho)

**Trigger**: a `pom.xml` at the project root.

From TypeFox/agent-skills, MIT.

More from TypeFox/agent-skills