I agree we need a strong enough community to be able to fix the
security issues in house.
For the security patch release, it's hard for the forked project to
keep track of all the security reports. We may only know about the
security issue when Lightbend does the release.
If the Lightbend
+1 to everything Greg says, although I wouldn’t consider it to be a hostile
fork
just as I don’t consider the fork of Hudson to Jenkins to be a hostile fork. In
my
book it isn’t a hostile fork when the major contributors simply switch to the
new
repository and infrastructure. i.e - if the
On Tue, Sep 27, 2022 at 4:55 AM PJ Fanning wrote:
>...
> In some cases, the critical fix might be submitted to the fork first
> and it may be easier for the Lightbend team to cherry pick those cases
> than it is for the fork team to do the opposite.
>
Should an ALv2 fork arise *anywhere*[1],
This seems needed given the state of Lightbend/licensing. Agreed with
Roman's sentiment, though getting Lightbend to change at this point seems
unlikely [ also, I don't have direct contacts there so am not well
positioned to try to negotiate any changes ]. Glad to see people coming
together
PJ,
Several of us working on the mdedetrich github projects [1] are preparing
to submit a proposal to the incubator, hopefully by the end of the week.
We have had contact from several individual devlopers, organizations,
projects, and companies about such a project. We identified a champion and
Thanks Willem for taking the time to look into this.
The license change means the fork project will not be able to cherry
pick future fixes from Lightbend - at least not readily.
On a case by case basis, we could request that the PR submitter also
contribute them to the fork project.
In some
Hi PJ,
Thanks for driving this discussion!
As mentioned above, Lightbend switched the license from upstream and we
simply _cannot_ backport code from there any longer.
However, it's reasonable to me that we start a new project based on the
latest APL-2.0 licensed version (forked) to save users
Thanks Ralph for looking at this.
It is early days but a number of people have expressed an interest in
joining the new community.
https://github.com/mdedetrich/akka-apache-project/discussions/3
There are some former Lightbend employees and some very active
contributors. Most of the people
Hi PJ! Thanks for moving the discussion to this list! For
completeness' sake -- let me repeat the comments I made on the legal
one:
On Mon, Sep 26, 2022 at 9:12 PM PJ Fanning wrote:
>
> Hi everyone,
>
> Apologies if this is not the right mailing list. If it is not, please
> let me know and I'll
No, fixes most definitely cannot be back ported. But someone can look at the
code fix and describe in very general terms what the fix was and then someone
else can implement it. But you cannot copy code and I wouldn’t even create
psuedo code as doing that would almost certainly be copyright
After going through the FAQ of the Akka license, it looks like we
cannot backport the BSL codes to the Apache License branch.
> If there is a newer version of the software under BSL, can I backport any of
> the code to an older, Open Source, version of Akka?
> No. In this circumstance, you
Before going too far with this I would be interested to know:
1. Who the initial committers/PMC members would be.
2. How much familiarity the proposed people already have with the code base.
3. How diverse the community is from an employment point of view.
In other words, I would be concerned if
Hi everyone,
Apologies if this is not the right mailing list. If it is not, please
let me know and I'll switch the thread to the right list.
Lighbend [1], the company that maintains the popular open source
framework, Akka [2], recently announced they are moving Akka to a
non-OSS commercial
13 matches
Mail list logo
