Chris— We interrogated the issue of the ELK license some time ago while we were in the Incubator. Even ELK v 6 raised this question given their introduction of a new license that prohibited CSP’s from distributing. We definitely didn’t want to be confused with a CSP in distributing ELK...
Our intent has therefore never been to release and maintain ELK builds as an Apache product. We felt that would push our project in directions that veered away from its original intent. We have always maintained examples of an ELK back-end that others could build and experiment with. What we actually distribute through the repo are really just docker files and config files. As I mentioned we have never released an official backend. Our users utilize a far too wide distribution of database technologies with Flagon to support them all—Couchbase, Postgres, Rocks. I don’t see it as a problem, Chris, to maintain unreleased examples (assuming license terms allow for that). Elastic products remain good technology. However, I think your comments are well taken as encouragement to explore other database technologies, which might have more agreeable license terms. Josh > On Jan 16, 2024, at 12:39 PM, Evan Jones <evan.a.jon...@gmail.com> wrote: > > Chris, > > Thanks for your feedback. > > While ES > 7.10 poses a problem, the ELK stack is not a 100% *mandatory* > part of Apache Flagon. Rather, our aim has been to provide the ELK stack > scripts as examples for how to stand up one possible back-end for UserALE > logs. > > Per Category X: You may rely on them when they support an optional feature > <https://www.apache.org/legal/resolved.html#optional>, is it possible to > retain the > 7.10 ELK stack examples so long as we clarify the *optional* > nature and also provide examples of other alternative back-ends? > > Also, re: Jason's question -- Supposing the plugin does pose issues, would > it be possible to release it separately from Apache Flagon itself? > > Best > > Evan Jones > Website: www.ea-jones.com > > > On Tue, Jan 16, 2024 at 12:03 PM Jason Young <j...@apache.org> wrote: > >> My bad for having a weird email setup and not signing emails. >> >> As far as the elastic license change, we've had discussions about creating >> an elastic search plugin similar to these >> https://docs.elastic.co/integrations/apache-intro. Would that be >> problematic given the license change? >> >> Jason >> >> On 2024/01/14 11:38:21 Christofer Dutz wrote: >>> And to add to that: The part of the ELK-stack modernization got me >> digging a bit. >>> At first I thought, seeing version 6.2.2 in the repo made me think: All >> ok, but it seems that there are currently efforts underway to update to >> 8.11.1 ( >> https://github.com/apache/flagon/commit/1fb7c561f342d7f8ae080cd64f2381e8f4e45b6a) >> Since version 7.11. the Elastic stuff is released under the new SSPL >> license, wich is officially rated category X ( >> https://www.apache.org/legal/resolved.html) so it is not allowed to >> release Apache software that relies on anything above 7.10. >>> >>> Chris >>> >>> On 2024/01/14 11:21:01 Christofer Dutz wrote: >>>> Hi all, >>>> >>>> I was just going through the projects latest activity and while having >> a look at one of the last VOTE threads, I would like to mention that the >> summary of the ASF rules on voting on releases was not quite correct: >>>> >>>> It's actually: >>>> "At least three PMC members must vote affirmatively for release, and >> there must be more positive than negative votes" >>>> >>>> So technically also 2 binding +1 votes and one binding -1 vote would >> also be enough for a release, even if usually this would of course not be >> encouraged. >>>> >>>> I also initially I had a bit of a problem actually seeing who the >> release manager was as the email didn't contain a name and the name I see >> in ponymail is just "proton_mail_bridge". It's always nice to add your name >> to an email ... I was glad to see that in your vote, you did add your name >> ;-) >>>> >>> >>
