Official website

Akka Licence Change (One Year Later)

27 Oct 2023

min read

Update 2023-11-14: Since the time of writing, the Play Framework maintainers have released a version 3.0 that is based on Pekko rather than Akka. Play 2.9 is thus the last version that is based on Akka. See Introducing Apache Pekko and Play 3.0. This is an important development for the scenario described below of those organisations that have applications built with the Play Framework and who have been considering the impact of the Akka Licence Change.

In September 2022, the CEO and Founder of Lightbend, Jonas Bonér, announced, in a blog post, a change in the licencing of Akka. Instead of an Apache 2.0 Licence, all future releases of Akka would be covered by a new Business Source Licence (BSL) v1.1. The announcement was made one day after the 2.6.20 patch release of Akka Core and other modules and this release would turn out to be the last one under the Apache 2.0 Licence.

At the time, the announcement generated a lot of reaction, including the decision by a part of the open-source community to create a fork of Akka. The forked project, called Apache Pekko, announced its first major release (v1.0.0) in July 2023.

Recently at Lunatech, at the request of many of our clients, we have decided to revisit this topic, specifically with an objective to help our clients manage their exposure to the new BSL licence and, if necessary, to help them eliminate this exposure entirely. We have decided to share some of our thoughts on the topic in case they are valuable to a wider audience.

Some key points about the licence change

To better understand the implications of the licence change, it is worth starting on the Lightbend webpage that tries to summarise the licence change in the form of an FAQ. Here are some points that stand out:

  • Any organisation wanting to use Akka in production need to obtain a commercial licence. However, for organisations with less than 25M USD in annual revenue, the licence will be granted free of charge

  • Lightbend pledged to continue providing critical patches to the open source version for another year after the initial announcement of the licence change (so scheduled to have finished September 2023)

  • They have included a special exemption (a so-called Additional Use Grant) for Play users so that the "usage of certain parts of Akka required by Play" are exempt from the licence change.

  • Play users that directly use Akka components in their own code are not covered by the Additional Use Grant and so must have a licence to cover this direct usage of Akka.

  • Every release of Akka under the new BSL will revert back to an Apache 2.0 Licence after 3 years

The Play Framework exemption

Many of our clients have a lot of production software that is built with the Play framework. So, the fact that there is an Additional Use Grant for Play in the new BSL is welcome news for them. However, as the FAQ page indicates, only the "usage of certain parts of Akka required by Play" is exempt. To understand better, we have to look at the Akka BSL licence itself, and specifically the "Additional Use Grant" clause:

"If you develop an application using a version of Play Framework that utilizes binary versions of akka-streams and its dependencies, you may use such binary versions of akka-streams and its dependencies in the development of your application only as they are incorporated into Play Framework and solely to implement the functionality provided by Play Framework; provided that, they are only used in the following way: Connecting to a Play Framework websocket and/or Play Framework request/response bodies for server and play-ws client."

That last phrase “Connecting to a Play Framework websocket and/or Play Framework request/response bodies for server and play-ws client” suggests that Additional Use Grant is actually quite limited. To get a better sense of what are the limitations, it is worth going through the Play documentation to see what patterns of usage are likely allowed, likely disallowed, and those that are not clear.

Play Framework sticking with Akka pre-BSL version for immediate future

We see that the “Play exemption” does not cover all uses of Akka inside a Play application. For our clients, one of the challenges will be to audit their applications to determine when there is code in our Play applications that falls outside the "Additional Use Grant".

However, there is one thing that will mean that there is less risk of falling foul of the BSL, even for uses that are not covered by the Additional Use Grant. That is the fact that both the current version of Play (2.8) and the planned next release (2.9) will stick with the pre-BSL version of Akka. From the current draft of the unreleased Play 2.9 migration guide:

Play 2.9.0 is using akka 2.6 and upgrades akka-http from 10.1 to 10.2. Play 2.9 will stick with those versions and not upgrade beyond them. That is because akka 2.6 and akka-http 10.2 are the last versions still using the Apache License, newer akka releases use the BSL, which Play avoids using.

Apache Pekko as a possible exit ramp

Given that for the moment Play will continue to be based on Akka pre-BSL version (and so that is likely to be the version that is used transitively if a Play application uses Akka in a way that is theoretically not covered by the Additional Use Grant), this suggests that the main risk for our clients is the fact that after September 2023, Lightbend will no longer back-port critical security fixes to Akka 2.6.x.

Note that since the licence change there has been 1 critical back-port (Release v2.6.21 · akka/akka), which, incidentally has also been picked up by the Apache Pekko project (include critical TLS fix from Akka 2.6.21 (pekko-stream TLSActor) · Issue #442 · apache/incubator-pekko)

Apache Pekko is proposed as a potential solution to mitigate the risk of either being on a version of Akka that will no longer receive critical security updates or of inadvertently depending on BSL code.

It is worth noting, however, that a possible migration to Pekko is not without its own risks (and I don’t just mean the general risks of migrating or rewriting software). By migrating to Pekko, one would be betting that the Apache Pekko project will be able to continue maintaining and evolving the framework - including security and bug fixes, and new functionality.

On the positive side, at least from a technical perspective, migrating from an Akka 2.6.x project to Apache Pekko seems relatively mechanical if we have a look at the Apache Pekko Migration Guide. However, at the time of writing, not all Apache Pekko modules have been officially released.

Akka module Pekko module Pekko module released?

Akka (core)

Pekko (core)



Pekko HTTP


Akka gRPC

Pekko gRPC


Akka Cluster

Pekko Cluster


Akka Cluster Sharding

Pekko Cluster Sharding


Akka Management

Pekko Management


Akka Streams

Pekko Stream


Alpakka Kafka

Pekko Connectors Kafka



Pekko Connectors


Akka Persistence

Pekko Persistence


Akka Persistence R2DBC

Pekko Persistence R2DBC


Akka Persistence JDBC

Pekko Persistence JDBC


Akka Persistence Cassandra

Pekko Persistence Cassandra


Akka Persistence DynamoDB

Pekko Persistence DynamoDB


Akka Projections

Pekko Projection


Some recommendations

Here we offer some recommendations. Note that these only apply to those cases where the organisation is earning more or is likely in the near future to be earning more than the 25M USD cap. For those earning less than the cap, as mentioned above, the commercial licence is granted at zero cost so they can continue using Akka and its modules in production.

Paying for the licence is a valid option

Paying for continued Akka use and future features is probably reasonable for complex applications that rely on the advanced distributed computing platform that Akka offers.

In that case, the first thing you should do is speak to Lightbend to see how much it is actually going to cost you to stick with Akka and not have to make any changes at all. If it turns out to be more cost-effective to come to a negotiated agreement with Lightbend for a commercial licence rather than paying the development costs to migrate away from Akka to an alternative solution, then paying for the licence is indeed a valid option. This is especially the case for those with complex distributed computing problems that rely on the proven features of Akka and would benefit from continued evolution of the framework.

Be clear about the tradeoffs if migrating

For those organisations that have decided that migrating away from Akka is a better choice than paying for a commercial licence, it is worth asking "Is your Akka system being actively developed? Are you adding new features or is it in maintenance mode?"

For applications that are in maintenance mode or where there are only the occasional evolutions and new features, migrating from Akka to Apache Pekko is likely to be the smoothest option. Of course, there will still be a need to put resources into the initial migration, but consulting the Apache Pekko Migration Guide we see that it is largely a 'Find/Replace' operation. However, the tradeoff for a relatively smooth initial migration might be that, given that Apache Pekko is a newly formed community, the pace of evolution and bringing new features might be slower than with Akka or other frameworks with more established communities and roadmaps.

Migrating from Akka to Apache Pekko might also be a good first step to BEFORE a subsequent refactoring. The reality is that there are a lot of applications that don’t need Akka for anything in particular, that don’t have complex distributed computing problems, but do simple stuff and yet still use Akka because it was a popular choice at the time also for simple things. For such applications, the organisation is probably better off migrating to Pekko as a first step (and losing out on future features that they wouldn’t need anyway), and then move away from this type of framework altogether as a second step.

For applications being actively developed AND with more of a capacity to absorb this kind of migration work AND that have complex distributed computing problems AND that would benefit from a mature framework with an established community, there is more of a case for migrating to a different ecosystem like ZIO or Cats-Effect.

For Play applications, update to the latest available version of Play Framework

As a general rule, we advise our clients to try to keep project dependencies up to date to the latest official release. In this particular case, it is especially important to use the latest version of Play Framework because in the case of a possible migration from Akka to Apache Pekko, the Apache Pekko Migration Guide recommends that your project first be using version 2.6.x of Akka. At the time of writing, the latest available version of Play Framework is version 2.8.x. As mentioned above, version 2.8.x of Play Framework uses version 2.6.x of Akka.

So keeping up to date now will likely improve your options for the future.

Use tooling to help detect disallowed licences

This is a general recommendation not limited to the particular case of a change in the Akka licence. However, the Akka licence change has raised awareness among project teams in many companies that perhaps not enough attention is paid to the licences that different dependencies embark in their projects and the potential legal and commercial implications.

Here is where automated tooling can help reduce the risk. For example, projects can use build tool plugins like sbt-licence-report to verify and fail the build if a dependency uses a disallowed licence. (Similar plugins exist for other build tools like Maven and Gradle). Some of our clients with the most mature processes include the generation of licence reports as part of a regular audit trail.