Dependency Review

OpenSSF Scorecard

Scanned Files

• .github/workflows/release.yml

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces significant updates to the project's licensing strategy, aiming to balance open access with sustainable development. It refines the Business Source License (BSL) 1.1's 'Additional Use Grant' to be more permissive for smaller, non-competing organizations, while simultaneously implementing a Contributor License Agreement (CLA) to enable dual-licensing. These changes are supported by extensive new documentation and automated processes for managing license terms and contributor agreements.

Highlights

• BSL Additional Use Grant: The BSL 1.1 Additional Use Grant has been narrowed to permit free production use for non-competing organizations with fewer than 500 employees. Larger organizations or competing uses now require a commercial license, which may be granted at no cost.
• Contributor License Agreement (CLA): A new Apache ICLA-based Contributor License Agreement has been added, enabling dual-licensing (BSL + commercial). Automated enforcement is implemented via contributor-assistant/github-action, with signatures stored in-repo.
• Licensing Documentation: A comprehensive docs/licensing.md page has been added, providing a full rationale for the BSL choice, detailing permitted uses, explaining the 500-employee threshold, automatic Apache 2.0 conversion, CLA explanation, and an FAQ.
• Landing Page Updates: A new 'License & Usage' section has been added to the landing page, featuring a 3-column visual breakdown (Always Free / Free in Production / Commercial License) with links to discussions and the new licensing documentation.
• Automated BSL Change Date: The Release Please workflow now automatically updates the LICENSE Change Date to three years ahead within each release PR, ensuring it goes through the normal review flow.
• License Reference Updates: All existing license references across the README, CLAUDE.md, docs/index.md, CONTRIBUTING.md, and the landing page footer have been updated to reflect the new licensing terms.

sequenceDiagram
    actor Contributor
    participant GitHub as GitHub (PR)
    participant Workflow as CLA Workflow
    participant Assistant as CLA Assistant
    participant Repo as Repository

    Contributor->>GitHub: Open pull request
    GitHub->>Workflow: Trigger pull_request_target
    Workflow->>Assistant: Run with CLA.md & .github/cla-signatures.json
    Assistant->>Repo: Check `.github/cla-signatures.json` for signature

    alt Signature not found
        Assistant->>GitHub: Post signing instructions comment
        Contributor->>GitHub: Reply with exact CLA sign text
        GitHub->>Workflow: Trigger issue_comment
        Workflow->>Assistant: Run on comment match
        Assistant->>Repo: Record signature in `.github/cla-signatures.json`
        Assistant->>GitHub: Post success message
    else Signature found
        Assistant->>GitHub: Post success message
    end

    Workflow->>GitHub: Set CLA check status for PR

sequenceDiagram
    participant DevOps as Release Process
    participant Actions as GitHub Actions
    participant ReleaseBot as release-please
    participant Git as Git Repository
    participant License as LICENSE file

    DevOps->>Actions: Trigger release workflow
    Actions->>ReleaseBot: run release-please (id: release)
    ReleaseBot->>Git: Create/update release PR

    alt Release PR exists
        Actions->>Git: Checkout release PR branch
        Actions->>Actions: Compute new BSL Change Date (now + 3 years)
        Actions->>License: Update Change Date line in LICENSE
        Actions->>Git: Commit & push changes to release PR branch
    end

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Greptile Summary

This PR narrows the BSL 1.1 Additional Use Grant to a targeted free-use grant (non-competing organizations with <500 employees), adds an Apache ICLA-based CLA with automated bot enforcement, introduces a docs/licensing.md rationale page, updates the landing page and all license references, and wires the Release Please workflow to auto-roll the Change Date 3 years ahead on each release. There are no code changes; all changes are to license text, documentation, and CI workflows.

Key findings:

• CLA bot will fire on Release Please PRs — the cla.yml job condition excludes only dependabot[bot]. Release Please opens PRs under RELEASE_PLEASE_TOKEN (a PAT or GitHub App token), so every release PR will trigger the CLA check and potentially generate a spurious "please sign" comment. The contributor-assistant/github-action provides an allowlist parameter for exactly this case; it should include at least github-actions[bot] and the repo owner.
• LICENSE Change Date vs. "3 years per release" policy mismatch — all updated documentation states the Change Date is "3 years after each release," but the LICENSE still carries the old February 27, 2030 date (~4 years from now). The release.yml automation will correct this on the next release PR, but the current release ships with a visible inconsistency between the license file and its own documentation.
• The pull_request_target security risk in cla.yml is properly mitigated (ref: main checkout, persist-credentials: false) and is correctly suppressed in .zizmor.yml with justification.
• The sed guard (grep -q … || exit 1) in release.yml addresses the previously identified silent-false-positive concern.
• CLA.md is well-structured; Section 2's sublicense grant and Section 4's outbound licensing clause correctly enable dual-licensing.

Confidence Score: 3/5

• Safe to merge with one actionable fix — the missing bot allowlist in cla.yml will cause noise on every release PR until addressed.
• No code changes and the legal/documentation content is well-crafted. The two issues — missing bot allowlist and the transient LICENSE date inconsistency — are both workflow/documentation concerns rather than correctness blockers, but the CLA bot firing on Release Please PRs is a real operational nuisance that will require a follow-up fix shortly after merge.
• .github/workflows/cla.yml (missing allowlist for bots/owner) and LICENSE (Change Date predates the new 3-year policy).

Important Files Changed

This is a comment left during a code review.
Path: .github/workflows/cla.yml
Line: 16

Comment:
**Missing bot/owner allowlist — CLA bot will fire on Release Please PRs**

The only excluded actor is `dependabot[bot]`, but Release Please also opens PRs to `main` — under `RELEASE_PLEASE_TOKEN`. If that token is a PAT, the CLA action will run against the PAT owner's GitHub account, prompting them (via bot comment) to sign the CLA on every release PR. If it is a GitHub App token, the action will attempt to check the app identity, which cannot sign.

`contributor-assistant/github-action` exposes an `allowlist` parameter for exactly this purpose. It accepts a comma-separated list of GitHub usernames (and supports wildcard `*bot*` patterns). Without it, every Release Please PR, plus any PR opened by the repo owner, generates an unnecessary CLA-unsigned comment.

```suggestion
    if: |
      (github.event_name == 'pull_request_target' &&
       github.event.pull_request.user.login != 'dependabot[bot]' &&
       !endsWith(github.event.pull_request.user.login, '[bot]')) ||
      (github.event_name == 'issue_comment' && github.event.issue.pull_request && github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA')
```

Or, preferably, pass an `allowlist` to the action itself so the logic lives in one place:
```yaml
        with:
          # …existing params…
          allowlist: Aureliolo,github-actions[bot],release-please[bot]
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: LICENSE
Line: 354

Comment:
**Change Date inconsistent with new "3 years per release" policy**

The current `Change Date: February 27, 2030` was set under the old policy and is roughly 4 years from the project's initial release date. The new policy (documented in `docs/licensing.md`, `README.md`, and `CLAUDE.md`) states the Change Date is "3 years after each release."

For `v0.1.4` (released 2026-03-14), a 3-year Change Date would be approximately **March 14, 2029**, not February 27, 2030. The `release.yml` automation will roll this date forward on the *next* Release Please PR, so the current release will ship with a license date that does not match the stated policy.

Consider triggering the date update as part of this PR itself (or noting explicitly in `docs/licensing.md` that the 3-year policy takes effect from the *next* release), so users reading the LICENSE today are not confused by the discrepancy between what the file says and what all the documentation promises.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 8f53b02}