Hi Ivan,
I don’t need a policy to clearly understand that the Apache project stops to be healthy once it is controlled by one entity. This is related to governance, not to OSI approved license (if a lib is open-source or not). Apache mission - Create software for the public good. Apache project is: - Open Source, commercial-friendly Licence, - Open Governance (clear, documented leader election), - Open Brand (Brand owner is always ASF, it is a non-profit, charity organization). And once community adds a dependency to any vendor-controlled and released artifact I suppose it is not anymore for the public good, it is for good of vendor. A goal can be to be advertized using this open-source project and the Apache brand. Vendor in some cases want just Apache brand, and rarely shares Apache principles and Apache Way. Maybe Konstantin could explain better than me, why the community should not accept vendor-provided dependencies. Hopefully, Cos can also evaluate idea separate GitHub repository with full control from PMC (root credentials is placed to private SVN + clear release procedure). Sincerely, Dmitriy Pavlov Disclaimer: Opinions expressed in this email are those of the author, and do not necessarily represent the views of any company the author might be affiliated with at the moment of writing. ср, 10 июл. 2019 г. в 15:06, Nikolay Izhikov <nizhi...@apache.org>: > Ivan. > > > I suppose that I did not ever claim such thing > > Thanks for clarifing :) > > > > GitHub project outside any commercial company accounts, there all Apache > committers added as collaborators may work. > > Sounds nice for me as well. > > +1 from me if it compatible with Apache policies. > > > В Ср, 10/07/2019 в 14:59 +0300, Павлухин Иван пишет: > > Nikolay, > > > Why we should close H2 fork from Ignite commiters in the first place? > > > > I suppose that I did not ever claim such thing. I think we are > > discussing various options. And ones might be simpler and others might > > be harder. > > > > Dmitriy, > > > > To my shame I am not very competent in licensing and related > > questions. I mostly think about how the problem can be solved > > technically. If something is against Apache policies then we > > definitely can go with it (would be great to get a reference to such > > policies). > > > > > GitHub project outside any commercial company accounts, there all > Apache committers added as collaborators may work. > > > > Sounds nice for me as well. > > > > And I would like to return to the beginning. > > 1. What do we want? Improve SQL in Ignite. > > 2. How do we want to do it? In the most convenient "legal" way. > > > > Perhaps there are other bright thoughts how to keep it simple? > > > > ср, 10 июл. 2019 г. в 14:18, Dmitriy Pavlov <dpav...@apache.org>: > > > > > > Wearing the hat of Apache Ignite PMC: > > > I'm against starting with dependency on GridGain code in any case. > Gridgain > > > can do its own forks of both. > > > > > > We all know how much influence the company has on the community and > adding > > > one more (I remind there is gridgain:shmem) > > > means the open-governed solution is dependent on closely-governed. > Would > > > you use something open-source if it depends on binaries? I don't care > about > > > license in that case. > > > > > > you can count on '-1' from my side. > > > > > > GitHub project outside any commercial company accounts, there all > Apache > > > committers added as collaborators may work. > > > > > > > > > ср, 10 июл. 2019 г. в 13:28, Юрий <jury.gerzhedow...@gmail.com>: > > > > > > > Agree with Ivan. > > > > > > > > We can start work with H2 fork owned by GG and decide change it > later in > > > > case it will bring some issues to Ignite community. Currently I > don't see > > > > any issues here. > > > > > > > > I'm worried about the issue, with process to synchonize changes H2 > fork and > > > > Ignite. As possible solution it could be as follow: > > > > Ignite has dependency only to released version of H2 fork. > > > > Then we could modify the fork in any time without compatibility > issues. > > > > When new feature is ready to use by Ignite need to modify code of > Ignite > > > > and change dependency version for H2 fork. > > > > However H2 for in the case should be release more often than Ignite. > > > > > > > > WDYT? > > > > > > > > ср, 10 июл. 2019 г. в 13:08, Павлухин Иван <vololo...@gmail.com>: > > > > > > > > > Nikolay, > > > > > > > > > > Could you please elaborate why is it "closed source"? > > > > > > > > > > > What the difference for the Ignite community? > > > > > > > > > > The difference is similar to using version X and version Y of the > same > > > > > library. Version Y might be better. > > > > > > > > > > > I think all Ignite commiters should have write priveledges to H2 > fork. > > > > > > > > > > I agree, it is quite natural. Actually, my only point is that we > can > > > > > do it at any point later, cannot we? > > > > > > > > > > ср, 10 июл. 2019 г. в 12:25, Nikolay Izhikov <nizhi...@apache.org > >: > > > > > > > > > > > > Ivan > > > > > > > > > > > > We have closed source code dependency for now owned by H2 owners. > > > > > > With new fork we will have the same closed dependency owned by > Grid > > > > > > > > Gain. > > > > > > > > > > > > What the difference for the Ignite community? > > > > > > > > > > > > > 2. Anyways some process must be established for merging changes > > > > > > > requiring changes in h2 library. So, I suppose it should be > review of > > > > > > > changes in 2 repositories. > > > > > > > > > > > > The question is - *Who can apply those changes*. > > > > > > > > > > > > I think all Ignite commiters should have write priveledges to H2 > fork. > > > > > > > > > > > > В Ср, 10/07/2019 в 11:30 +0300, Павлухин Иван пишет: > > > > > > > Folks, > > > > > > > > > > > > > > I would like to highlight a couple of points. > > > > > > > 1. Perhaps it is not so crucial where is this fork located if > the > > > > > > > > code > > > > > > > is publicly available and can be cloned to another repository > easily. > > > > > > > We can relocate code and use it at any point in future. > > > > > > > 2. Anyways some process must be established for merging changes > > > > > > > requiring changes in h2 library. So, I suppose it should be > review of > > > > > > > changes in 2 repositories. > > > > > > > > > > > > > > Now (and beforehand) we use original h2. And how many of us > were ever > > > > > > > interested what changes were made in h2? So, perhaps for the > first > > > > > > > time we can start with GG fork? And if later on some problems > with > > > > > > > that appear we can clone it and use that new fork without much > > > > > > > trouble, can't we? > > > > > > > > > > > > > > ср, 10 июл. 2019 г. в 09:52, Nikolay Izhikov < > nizhi...@apache.org>: > > > > > > > > > > > > > > > > Hello, Denis. > > > > > > > > > > > > > > > > > Nickolay, as for that fork which is in GG codebase - > GridGain is > > > > > > > > a > > > > > major > > > > > > > > > contributor and maintainer but the others are welcomed to > send > > > > > > > > > pull-requests. > > > > > > > > > > > > > > > > Can we make this fork maintained by Ignite Community? > > > > > > > > > > > > > > > > With all respect to Grid Gain as an author of Apache Ignite > I don't > > > > > > > > > > like when some huge dependencies > > > > > > > > (incompatible with community-driven analogue) belongs to the > > > > > > > > > > enterprise. > > > > > > > > > > > > > > > > This leads us to the situation when Grid Gain will decide > which > > > > > > > > > > features will be added to the SQL engine and which not. > > > > > > > > > > > > > > > > В Пн, 08/07/2019 в 13:51 -0700, Denis Magda пишет: > > > > > > > > > Dmitry, > > > > > > > > > > > > > > > > > > To make this fully-vendor neutral even at the originating > > > > > > > > > > repository level, > > > > > > > > > we can create and work with the H2 fork as a separate > Github repo > > > > > > > > > > (separate > > > > > > > > > project governed and maintained by Ignite community). That > repo > > > > > > > > > > can't be > > > > > > > > > part of Ignite due to license mismatch. Thus, during > release > > > > > > > > > > times, we need > > > > > > > > > to assemble a binary (maven artifact) from that fork. > > > > > > > > > > > > > > > > > > However, it's not clear to me how to use those sources > during the > > > > > > > > > > dev time? > > > > > > > > > It sounds like Ignite can use only the binary (Maven) > artifact > > > > > > > > > > that has to > > > > > > > > > be updated/regenerated if there are any changes. *SQL > experts*, > > > > > > > > > > could you > > > > > > > > > please step in? > > > > > > > > > > > > > > > > > > Nickolay, as for that fork which is in GG codebase - > GridGain is > > > > > > > > a > > > > > major > > > > > > > > > contributor and maintainer but the others are welcomed to > send > > > > > > > > > pull-requests. > > > > > > > > > > > > > > > > > > - > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jul 4, 2019 at 9:26 AM Dmitriy Pavlov < > > > > > > > > dpav...@apache.org> > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi Denis, > > > > > > > > > > > > > > > > > > > > As you know, some time ago I've started a discussion > about > > > > > > > > > > removing > > > > > > > > > > dependence from gridgain:shmem. Ignite community seems > to be > > > > > > > > not > > > > > so much > > > > > > > > > > interested in this removal, for now. So once added it > could > > > > > > > > stay > > > > > here > > > > > > > > > > forever. Reverse dependency direction seems to be more > natural. > > > > > > > > > > It is like > > > > > > > > > > the open-core model. > > > > > > > > > > > > > > > > > > > > I feel more comfortable if all Ignite dependencies are > released > > > > > > > > > > as part of > > > > > > > > > > the Ignite code base, or some open governed project with > a > > > > > > > > > > license from > > > > > > > > > > Category A https://www.apache.org/legal/resolved.html. > > > > > > > > > > > > > > > > > > > > It is true that H2 has Category B license, so derivative > can't > > > > > > > > > > be committed > > > > > > > > > > into ASF repository. > > > > > > > > > > > > > > > > > > > > What if we consult with le...@apache.org to find > additional > > > > > > > > > > ways to donate > > > > > > > > > > forked version into ASF codebase? We anyway need their > approval > > > > > > > > > > because > > > > > > > > > > gridgain/h2 has a non-standard license, so we should > approve > > > > > > > > > > including > > > > > > > > > > non-standard licensed component it the product. > > > > > > > > > > > > > > > > > > > > Sincerely, > > > > > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > > > > > > чт, 4 июл. 2019 г. в 18:57, Denis Magda < > dma...@apache.org>: > > > > > > > > > > > > > > > > > > > > > Hi Igniters, > > > > > > > > > > > > > > > > > > > > > > As you know, Ignite SQL engine is tightly coupled with > the H2 > > > > > > > > > > database > > > > > > > > > > > > > > > > > > > > that > > > > > > > > > > > provides basic parsing and query execution > capabilities. > > > > > > > > This > > > > > synergy > > > > > > > > > > > > > > > > > > > > has > > > > > > > > > > > worked well for a while until Ignite SQL engine got a > much > > > > > > > > > > broader > > > > > > > > > > > > > > > > > > > > adoption > > > > > > > > > > > for all sort of use cases. > > > > > > > > > > > > > > > > > > > > > > Presently, there is a list of impactful issues and > > > > > > > > limitations > > > > > related to > > > > > > > > > > > memory management, distributed engine optimization, and > > > > > > > > > > queries planning > > > > > > > > > > > that require changes in H2. We've tried to contribute > to H2 > > > > > > > > > > directly with > > > > > > > > > > > no significant luck - what's needed for our distributed > > > > > > > > engine > > > > > is of no > > > > > > > > > > > interest to H2 community. At the same time, we can't > leave > > > > > > > > the > > > > > things as > > > > > > > > > > > is, as long as these limitations keep Ignite SQL > engine from > > > > > > > > > > gradual > > > > > > > > > > > evolution. > > > > > > > > > > > > > > > > > > > > > > As a solution, we created an H2 fork [1] and did all > of the > > > > > > > > > > required > > > > > > > > > > > changes there. We would be happy to include the fork > into > > > > > > > > > > Ignite source > > > > > > > > > > > base, but H2's license (available under dual MPL 2.0 > and EPL > > > > > > > > > > 1.0) is not > > > > > > > > > > > compliant with Apache 2.0. However, if Ignite starts > using > > > > > > > > our > > > > > maven > > > > > > > > > > > artifacts instead of the standard H2's ones, then the > > > > > > > > > > licensing issue is > > > > > > > > > > > solved. > > > > > > > > > > > > > > > > > > > > > > Is the community ready to accept this solution and > swap the > > > > > > > > > > standard H2 > > > > > > > > > > > artifact with the one prepared by GridGain? Presently, > all of > > > > > > > > > > those > > > > > > > > > > > improvements are available to GridGain customers, but > > > > > > > > GridGain > > > > > wants to > > > > > > > > > > > make all of them be available for Ignite community. And > > > > > > > > that's > > > > > the only > > > > > > > > > > > legal way we've come up with... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://github.com/gridgain/gridgain/tree/master/modules/h2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > - > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Best regards, > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > -- > > > > Живи с улыбкой! :D > > > > > > > > > > >
