.... so was there then a need to open a discussion in the first place when we have the PR already?
On Thu, Aug 27, 2026 at 10:49 AM Aman Mittal <[email protected]> wrote: > Hi Aleks > > you are right Com.github.jk1.dependency-licence-report is already applied > but it's for informational purposes only. But nothing gates it based on > content. The main goal is that we can catch problematic dependency on PR > itself. Right now what I am proposing if to use existing plugins that are > already in fineract and draft a GitHub action based on that. Note: required > dependency is already there. What we need it to automate this in actions > file. What i am proposing is to enforce as CI check based on plugin results > no new scanner is built. > > Regards, > Aman > > > On Thu, 27 Aug, 2026, 1:30 pm Aleksandar Vidakovic, < > [email protected]> wrote: > >> Hi, >> >> ... not sure about the development part... there are a ton of Gradle >> plugins out there that do this, so wouldn't advise to put something >> together yourself; I think that would be wasted effort for an already >> solved problem... e.g. this one comes to mind >> https://github.com/jk1/Gradle-License-Report... technically I think we >> are required to list all licenses of all artifacts we use somewhere (I >> think the NOTICE file is usually the place if I'm not mistaken, maybe could >> be LICENSE). >> >> On Thu, Aug 27, 2026 at 8:23 AM Aman Mittal <[email protected]> >> wrote: >> >>> Hi all, >>> >>> I like to propose adding a CI check for Category X transitive >>> dependencies for Fineract. >>> >>> At present, there is no check in the build that catches this. A Category >>> X license could be introduced transitively through an otherwise unrelated >>> dependency bump and remain unnoticed until a release audit. Or even direct >>> dependency license changes [One example i recall is at the time of >>> liquibase where they changes their license on the new release] and sometime >>> needs manual reviews >>> >>> What's already in place, and why it doesn't cover this: >>> >>> - Apache RAT (./gradlew rat) already runs in CI, but RAT checks whether >>> our own source files have the correct Apache license headers. It does not >>> audit dependency licenses, including transitive dependencies, so it is >>> not a substitute for dependency license compliance checking. >>> >>> - CycloneDX is already applied at the root of build.gradle and generates >>> a complete SBOM. However, nothing currently consumes the SBOM to enforce >>> license policy. >>> >>> This would involve generating an SBOM for the `develop` branch and for >>> the PR head, then comparing the changes to flag any dependency using a >>> license that requires review. [This will also keep the existing >>> dependencies as it is but will flag for new changes] >>> >>> I'd like to gather feedback and reach consensus on the approach before >>> starting implementation. Please share your thoughts, concerns, or >>> objections. >>> >>> Once there is rough agreement, I'll follow up with a JIRA ticket to >>> track the implementation. >>> >>> Thanks and Regards >>> Aman >>> >>
