How to Stay on the Last Version Before a License Change

When an open source project relicenses under source-available terms, it cannot retroactively revoke licenses for previously released binaries and source code. Under copyright law, releases published under permissive or copyleft licenses (BSD, Apache 2.0, MPL 2.0) remain open source indefinitely.

To insulate their systems from commercial and legal risk, many engineering teams adopt a version-pinning strategy—freezing their dependencies on the last open source release prior to the license transition. This guide explains what the version boundary means, provides concrete version-pinning examples, and outlines the long-term security trade-offs.

1. Defining the Version Boundary

The version boundary marks the exact release where the project first shipped under its new, restrictive license:

• Versions Below the Boundary (Before Boundary): Fully governed by the original open source license. Safe from source-available commercial restrictions.
• Versions At or Above the Boundary (After Boundary): Governed by source-available terms (e.g., SSPL-1.0, BUSL-1.1), carrying restrictions against commercial service hosting.

2. Implementation: How to Pin Versions in Production

To prevent automated CI/CD runners or package managers from pulling post-boundary versions, specify exact release tags in configuration files:

1) Docker Container Pinning

Avoid floating tags like :latest or major release tags (:7):

# Risky: May pull post-boundary releases automatically
FROM redis:latest
FROM hashicorp/terraform:light

# Safe: Explicitly pinned to the last verified open source tag
FROM redis:7.2.4-alpine
FROM hashicorp/terraform:1.5.5

2) Kubernetes & Helm Manifests

# Helm values.yaml
image:
  repository: redis
  tag: "7.2.4-alpine"
  pullPolicy: IfNotPresent

3. Risks of Staying on Legacy Pre-Change Versions

While pinning offers immediate legal compliance, it is rarely sustainable long-term due to:

• Security Patch Termination (EOL): Upstream vendors only backport critical CVE fixes to their actively supported, source-available branch. Older versions become vulnerable to unpatched security exploits.
• Ecosystem Incompatibility: Modern cloud providers, container orchestration tools, and third-party libraries gradually deprecate support for legacy protocols and API endpoints.

4. The Long-Term Solution: Migrating to Community Forks

To maintain both continuous security updates and permanent open source guarantees, organizations typically migrate to neutral foundation forks:

• Redis 7.2.4 → Valkey (Linux Foundation, BSD-3-Clause)
• Terraform 1.5.5 → OpenTofu (Linux Foundation, MPL-2.0)
• Elasticsearch 7.10.2 → OpenSearch (Apache-2.0)

See our Community Fork Migration Checklist for step-by-step guidance.