Licence Changes and Protestware

Fortify

Explanation

Put a licence gate on every dependency change, slow down upgrades enough for the community to spot sabotage, and choose components and runtimes whose terms you control.

Insight

An allowlist ages better than a denylist. New source-available licences keep appearing, and an allowlist fails safe on all of them.

Practical

• Add GitHub's dependency review to pull requests with allow-licenses. The deny-licenses input still works but is deprecated.

name: Dependency review
on: [pull_request]
permissions:
    contents: read
    pull-requests: write
jobs:
    review:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v6
            - uses: actions/dependency-review-action@v5
              with:
                  allow-licenses: Apache-2.0, MIT, BSD-2-Clause, BSD-3-Clause, ISC, EPL-2.0
                  comment-summary-in-pr: on-failure

Pin both actions to a full commit SHA in practice.

• Run ORT or ScanCode on a schedule for the full tree, since dependency review only sees what a PR changes.
• Add a release-age delay so sabotaged releases are usually caught and pulled before you take them:

{
    "minimumReleaseAge": "3 days",
    "packageRules": [
        {
            "matchUpdateTypes": ["major"],
            "automerge": false
        }
    ]
}

• In pnpm, set minimumReleaseAge in pnpm-workspace.yaml for the same effect at install time.
• Standardise on an OpenJDK distribution with terms you have read, such as Eclipse Temurin, and pin it in Dockerfiles and toolchain configuration.
• When a key dependency relicenses, pin the last acceptable version and plan a move to the fork or an alternative.

Tools/Techniques

• dependency-review-action.
• Renovate minimumReleaseAge, pnpm minimumReleaseAge.
• ORT policy rules, ScanCode.

Metrics/Signal

• Dependency PRs that ran a licence gate, as a percentage of all dependency PRs.
• Exceptions granted to the licence allowlist, each with an owner and an expiry date.