Akka Licence Change (One Year Later)

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.

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.

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.

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.

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.