GitHub does not ship a license scanner out of the box, and when we went looking in the marketplace, none of the existing actions did what we needed. So we built our own with a colleague from Microsoft and published it. In Part 4 of our GitHub DevSecOps series, Patrick Steger and I plug that License Finder action into our Spring Boot pipeline, configure which licenses are acceptable, and show how to surface the results inside GitHub.
Why License Compliance, Even on a “Simple” Project#
Patrick gives the same answer he gave for SCA. Our Java program uses Spring Boot, and Spring Boot pulls in dozens of libraries. Each comes with a license, and licenses come with rules — what you can do, what you cannot do, what you have to disclose. To stay compliant you have to know what you are using and decide which licenses you accept.
How We Got to a License Finder Action#
GitHub does not provide a built-in license scanner. The path is the same as for SCA: pick something from the marketplace. Nothing there fit. Together with our colleague Juan Manuel from Microsoft, we wrote a GitHub Action that wraps the Pivotal License Finder open source project. It is published in the marketplace under the name License Finder, and that is what we use here. The action is in alpha, and there is no easy in-UI view of all licenses used — that lives in the log output.
How the Action Works#
Once it is in your workflow the flow is straightforward. The action scans every dependency in your project, looks for the license file, compares each license to a configured list of permitted ones, reports non-compliant licenses as test results in the GitHub UI, and fails the build when a license outside the allowed list shows up. That last bit is what makes it a real gate rather than a passive report.
A Sub-Workflow, Not a Step in the Main One#
Rather than bolt license compliance onto the main pipeline, we add it as a separate sub-workflow. We define a new workflow file called License Compliance and trigger it from the main pipeline (and optionally manually). The job checks out the code and runs the License Finder action. One small fix is needed: you have to remove the Maven file before the action runs, otherwise License Finder does not start cleanly.
Configuring Permitted Licenses#
The action takes two key parameters. permitted-licenses is the list of licenses you accept — for the demo we started with MIT and Apache-2.0 so we would deliberately get findings. approved-dependencies is the list of libraries that ship without a license file at all but that you have decided are fine. For simplicity we added every Spring Boot dependency without a license file to that list. In a real project that decision deserves more care.
Surfacing the Results in GitHub#
License Finder produces a unit test report file. We feed that to the publish-unit-test-result action — the same one we used in earlier sessions — but with one tweak: we rename the report to License Compliance Check so that it shows up in the GitHub UI under that name rather than as a generic test result. We also upload the full report as a downloadable artifact so anyone can grab the raw output as a zip.
What the First Run Showed#
The pipeline ran, the License Compliance Check appeared in the workflow, and the check told us it had found 55 libraries — five of them with licenses outside our allowed list. Drilling into the raw output we saw one BSD-licensed library, one with CDDL + GPLv2, and three using Eclipse Public License 1.0. None of those are problematic for our use case, so we added them to the allowed list. After a re-run the check went green and all 55 libraries passed.
Who Decides What Is Acceptable?#
I asked Patrick the obvious question: who actually decides which licenses get added to the allow list? His answer: depends on the company. In some organisations a central architecture or security department owns the policy. In others it sits with the project — typically the tech lead, who also keeps a security risk list. The tool does not answer this for you. It just enforces whatever policy you configure, so make sure someone owns that policy.
What This Pipeline Buys You#
With the License Finder action plus a small sub-workflow you get a scanner that runs on every pipeline, fails the build on unapproved licenses, surfaces results as a check inside GitHub, and lets anyone download the raw report. Compared to GitLab’s built-in template this takes more setup, but the end result is the same: a license question answered automatically on every commit.
Key Takeaways#
GitHub has no built-in license scanner. You go to the marketplace. When nothing fits, you write your own action — that is exactly how the License Finder action we use was created.
Run it as a sub-workflow. Keeping license compliance in its own workflow file makes it easy to reuse, trigger manually, and reason about independently from the main build.
Permitted-licenses and approved-dependencies do different jobs. One is the policy on licenses you accept; the other handles libraries that ship without a license file at all. Treat both with intent.
Rename the test report. Publishing the License Finder output through the unit test action makes it visible in the UI, but only if you give it a meaningful name — otherwise it disappears as another “test result”.
The policy needs an owner. Tooling enforces the allow list; it does not decide what belongs in it. Pick the role — central security, central architecture, tech lead — and make the responsibility explicit.
Mind the alpha-state caveats. Our action is in alpha, and there is no nice “all licenses used” view inside GitHub — you have to read the log. Plan around it; do not be surprised by it.