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/
