Akka actor runtime licensing shift at 2.8 boundary affects production upgrade path

Direct answer

Running a self-hosted Akka 2.8+ cluster for internal services is not automatically permitted under BSL 1.1; internal-only use does not by itself make production use free. Offering the application as a managed service to external customers is a scenario BSL commonly restricts, so a Lightbend commercial license is more likely, but the exact trigger depends on the license text and any Additional Use Grant. Staying on Akka 2.6 LTS indefinitely is not a safe option: the LTS support window ends, after which vendor security patches stop and a migration or licensing decision is required.

Confirmed facts and likely explanation

Confirmed facts

• Akka 2.6 LTS ships the Classic and Typed actor runtime under Apache 2.0.
• Akka 2.8 and later ship the same runtime artifacts under Business Source License 1.1.
• BSL 1.1 converts to Apache 2.0 only at the BSL change date, not at the download date.
• BSL 1.1 is source-available but not OSI-approved open source; production use may be restricted before the change date.
• Transitive dependencies keep their own licenses; only Akka runtime artifacts cross the boundary.

Likely explanation

The upgrade constraint is legal, not technical. Akka 2.6 Classic code is not binary or API compatible with 2.8+ Typed artifacts by default, so code changes and regression testing are separate from the licensing question.

Steps for this case

1. List the Akka artifacts in your build and inspect the LICENSE and NOTICE files inside each artifact JAR to confirm the license for the exact version you plan to deploy.
2. Read Lightbend's BSL 1.1 license text and Additional Use Grant to identify whether your deployment model—self-hosted internal cluster or managed external service—is restricted before the BSL change date.
3. Confirm the Akka 2.6 LTS end-of-support date and security-patch policy directly from Lightbend support documentation; do not assume indefinite patching.
4. If you proceed with 2.8 or later, validate Classic-to-Typed migration in a staging cluster before production.

Verification command

find ~/.m2/repository -path '*akka*' -name '*.jar' -maxdepth 5 | sort

Inspect each matching JAR for META-INF/LICENSE or META-INF/NOTICE files.

Missing diagnostic detail

Do you have a Lightbend commercial subscription or Additional Use Grant that covers your organization and deployment model? This determines whether the 2.8+ upgrade can proceed without renegotiating terms.

Assumptions and uncertainty

Version assumption: this applies to Akka 2.6 LTS and Akka 2.8+ artifacts published by Lightbend. Legal determination: BSL scope is a legal question; have counsel review the license text before upgrading production clusters. The BSL change date is future-dated, so using 2.8+ before that date remains under BSL restrictions.