Sustainable open source is a vexing problem, and I hope Lightbend find success in the new model for Akka and continues the proud tradition of innovation.
I propose that a release-2.6 branch is maintained under the Apache 2.0 License for critical bugfixes and security patches only until September 2023. The Lightbend Support Terminology states:
Lightbend commits to providing 1 year advance notice before ending support for any Supported component, so an EOL announcement will include the date on which a product is EOL. A product remains Supported until the EOL date. Once the EOL date passes, Lightbend will no longer support the product.
The definition of supported (emphasis mine):
Applies to any product for which Lightbend will provide fixes and patches to subscribers on request.
The policy justifiably promises nothing to non-subscribers, but I believe a traditional Akka EOL cycle is still advantageous to Lightbend.
Enterprise procurement is a grueling process. As a staff engineer, I can’t produce a check today, but I have to answer security questions every day. Today I could only shrug.
Some will realize the value in the product and subscribe. Others will have time to make a responsible migration. Either way, predictable EOL cycles preserve Lightbend’s brand as a dependable business partner in future consideration.
There is still incentive to subscribe ASAP and enjoy the innovations that 2.7 will bring.
The burden is hopefully low. There were only five releases of 2.5.x in the year after 2.6.0, and the bar might be higher for the wind down of 2.6.x.
I hope the patch policy is reconsidered as Akka transitions to its new business model. This change would makes the pivot just as definite, but much less jarring.
Thanks for your suggestion. We have had a fair amount of conversations about this internally, and we unanimously agreed that your suggestion is a good one.
To that end, we will be addressing critical security updates and critical bugs in Akka v2.6.x under the current Apache 2 license until September 2023. Please give us a little bit of time to update our documentation to reflect this change.
I cannot speak for others, but the time I invested in helping Akka HTTP work for Scala 3 was done to help the overall Scala 3 migration effort, which is likely to be hampered if no Apache-licensed release of Akka HTTP is ever released.
The idea is thay there will be a separate branch in each akka project that maintains the latest Apache 2 version. Lightbend is also free to cherry pick any additional commits on that Apache branch into yheir BSL id they want.
If #playframework is affected by the decision of #lightbend 's akka licencing in future, I can ensure #Scala will be nothing but a dead language. Even I am thinking of not to use Scala in any of my next projects.
You can keep them away from new license
@jboner Thanks for reviewing the community proposals and engaging with them. I wish Lightbend every success in the future with Akka and your other products.
There is a feeling among some members of the OSS community, that it would be good for us to create a community supported fork of Akka. If this did proceed, we would do everything to respect the Lightbend trademarks and license terms of Lightbend code.
It has been suggested that the Apache Software Foundation would be a good place to take the forked project. One of the requirements for an ASF podling is that the initial code that gets imported to ASF repos is covered by a Software Grant Agreement or a Corporate Contributor License Agreement .
It is early days and I’m not looking for any action from Lightbend at this stage but would you consider the possibility of signing such an agreement if there was some progress towards creating an ASF podling for an as yet unnamed Akka fork?