Hey all, I believe we are finished with this discussion.
As the next step, I'm going to start the vote. I will close the vote after 72 hours or 2/3 of committers have voted (whichever comes later). When I call the vote I will individually list +1's, 0's, -1's, and abstentions. Best Regards, Myrle Committer, Apache Fineract On Mon, Oct 16, 2017 at 8:33 PM, Phil Steitz <[email protected]> wrote: > On 10/16/17 4:32 AM, Myrle Krantz wrote: >> 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. > > Hi Merle, > > I don't see any problem at all with a). This happens frequently in > the Incubator, where initially granted code has dependencies on > libraries with unapproved licenses. Step 0 is to get the code in so > getting it ready for release can be done by the community. Getting > the code granted and formally incorporated into the project is > important. Accepting the grant does not commit the project to > actually releasing it or anything based on it. It just means that > it is part of the project and you can point people at the sources, > accept patches under the ASF CLA, etc. Once the code is granted > and accepted into the project, you can decide how to solve the > dependency problems. Unless the sources that you are bringing in > themselves include LGPL code, you are not violating any ASF policy > by incorporating them into your project. You are correct, though, > that ASF policy [1] forbids release of code that has non-optional > LGPL dependencies and you will need to find a way to handle that > before first release. > > Phil > > [1] https://www.apache.org/legal/resolved.html#optional > > >> >> 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/ > >
