Just to make sure it's clear - releasing packages in the akka.* namespace
is not off the table; however the project can choose to not do that. It can
then choose situationally to consider that in the future; for example if
the situation I'm concerned about occurs (Pekko not ready for release,
critical security issue next September, and Lightbend refuse to update the
open source version).

Avoid making door-closing legal interpretation statements without getting
legal interpretation :)

Hen

On Tue, Nov 8, 2022 at 11:51 PM Jean-Luc Deprez <[email protected]>
wrote:

> Lead up to the discussion to be found here btw:
> https://github.com/mdedetrich/akka-apache-project/discussions/8
>
> Anyhow, sticking with the akka package name is considered a legal swamp by
> most involved. ASL 2 doesn't grant trademarks but you still have the
> matching contract argument (as exist for java.* and the many distributions
> of java), but that means that you need to make every effort to stay 100%
> compatible (counter example Microsofts 2000 era JVM), which means staying a
> 3 year delay downstream (like CentOS now Rocky linux) and risk due to muddy
> waters when it comes to security fixes.
>
> So I think akka.* package releases are off the table. The only way that
> would have been possible was by a formal Software Grant by Lightbend, which
> included the trademark, which clearly is not the case.
>
>
>
> On Wed, Nov 9, 2022 at 7:31 AM Alexandru Nedelcu <[email protected]>
> wrote:
>
> > On Wed, Nov 9, 2022, at 07:23, Greg Methvin wrote:
> > > If Pekko uses a different package name, most of those libraries will
> need
> > > to support Akka users that are not ready to migrate to Pekko, so they
> > will
> > > need to release equivalent versions for Akka and Pekko at the same
> time.
> > > That will probably not be too hard if we have a tool to migrate an Akka
> > > codebase to Pekko, but it will definitely complicate things for more
> > > complex projects like Play.
> >
> > One thing to keep in mind is that releasing Pekko under a different
> > package name is the only way libraries are able to support both, the only
> > way forward. We can't publish with the same group id on Maven Central,
> > therefore we cannot evict Akka from the classpath, therefore both can be
> > and will be on the classpath at the same time.
> >
> > For both libraries and users, having Pekko use the same package name
> would
> > be an absolute nightmare for both libraries and apps, because you then
> have
> > to manually manage exclusions in your build. Because both Pekko and Akka
> > tend to be transitive dependencies.
> >
> > Play Framework's development, AFAIK, was donated and is no longer
> > sponsored by Lightbend. I loved Play Framework and I used it in many
> > projects over the years, the only framework for Scala that brought us the
> > "Ruby on Rails" experience.
> >
> > Personally, I can no longer touch it, as long as it depends on Akka,
> > because its API assumes usage of actors, and so it's a minefield. I don't
> > know the future, but if we're taking bets, I'd bet that Play Framework
> will
> > fully migrate to Pekko and leave Akka completely behind 🤷‍♂️ because
> > that's the only way forward for FOSS projects like it. This is just a
> > personal opinion of course, but I'm sure I'm not alone in thinking that
> > Play, like Akka, is a hot potato right now for many projects. And the
> > difference b/w Play and Akka is that for Akka at least you have
> commercial
> > development and support available.
> >
> > My prediction is that if Pekko turns out to be a viable fork, the entire
> > FOSS ecosystem around Akka will turn around to depend on it, instead of
> > Akka; so trying to use the same package name would be just a short-term
> fix
> > that can only cause problems. There's a big IF in there, of course 🙂
> >
> > --
> > Alexandru Nedelcu
> > alexn.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>

Reply via email to