Hey Fineracters, Before I bring Fineract CN to vote, I need to bring up one last topic which is painful for us all: hibernate-jpa
I know: nobody wants to talk about that, but we don't really have a choice. Most of the Fineract CN services have a run-time-only dependency on hibernate-jpa. Unlike the other hibernate libraries we use, hibernate-jpa is an LGPL library. The Apache Software Foundation does not allow LGPL source dependencies because of the legal risks they pose to potential commercial users of our code. LGPL is a category X license. Hibernate-jpa implements a JSR specification which is available under the CDDL 1.1 and TCK. CDDL 1.1 is a category B license (1); it won't block us releasing dependent code. Because the JPA interface is licensed via a category B license, and because FineractCN does not use any "non-JPA" features of hibernate, the FineractCN service code has no compile-time dependencies to a category X license. Component-test code is a different matter. Our component-tests do depend on hibernate-jpa via spring-boot-starter-data-jpa. We might argue that if we only make a source release of the service and API code and not the component-test code, that we are within policy. Binary releases of FineractCN would be ruled out, or someone would have to do the pre-release testing work with OpenJPA. This approach is complicated by our multiple-repository approach. We need to produce artifacts from "lower" projects before we can build "higher" projects. And building would be so much easier if we could place those artifacts in an artifactory rather than making everyone build everything every time. But even build-snapshot artifacts could be considered a source release. Likewise, running integration tests would be easier if we could reference build artifacts in an artifactory rather than locally. It remains to be seen if the ASF would accept this argument and this approach. If the ASF does not accept this approach, there are two potential paths forward: a.) We bring the source into the project, then resolve this issue before the first release. b.) We resolve this issue before we accept the source into the project. I personally would prefer a, so that we can get back into on-list development. I don't know if the ASF would accept that approach though. Does anybody else have an opinion? Am I missing any important information? Please share. Greetings, Myrle 1.) https://www.apache.org/legal/resolved.html On Tue, Sep 19, 2017 at 10:18 AM, Myrle Krantz <[email protected]> wrote: > Hey all, > > I'd like to begin discussion to bring Mifos I/O in to the Fineract > project as Apache Fineract CN. I propose the following process to get > us there. Note that this is a discussion thread. I will send a > voting thread once discussion has died down. > > A.) Discuss and vote to accept the code into the Fineract project and > begin the Apache processes. We should not proceed beyond this point > until at least 2/3 of the Committers have voted. My preference is that > we reach 100%. > B.) Go through the IP clearance process (1) for that code via the > Incubator. This will probably require at least: > a.) A software grant from the Mifos Initiative > b.) A CLA from Kuelap > c.) An iCLAs from Mark van Veen, Nina Delvos, and Riana Allen. > d.) A thorough check through of the code to make sure those of us > working on it haven't missed any licensing issues. > C.) Discuss the necessary infrastructure for the code, and place the > corresponding requests with the INFRA team. This will at least include > JIRA, and github. > D.) Move the code and rename the packages from Mifos to Fineract. > E.) After migrating the code resolve any release-blockers which might remain. > F.) Go through the final QA/Release process for the new code base. > Release under the name Fineract CN to disambiguate from the current > Fineract code base. > G.) Announce and document. > H.) goto E. > > I am *not* proposing that we stop development on the existing Fineract > code base. That is a decision for each individual contributor to > make, and it's not a decision that needs to be made at this time. > > This will be a long process. It may be late October before we are even > at C. Please be patient once we get going. > > Do you see anything that I've missed? Do you have any concerns? > > Best Regards, > Myrle Krantz > Individual Contributor, Apache Fineract > > 1.) http://incubator.apache.org/ip-clearance/
