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 >> >
