Open source licenses in your software: what businesses should check

Which open source licenses are in your software? Almost every modern application is built on open source libraries, and each one comes with a license that sets the terms of use. Most business owners never see that list. On 16 October 2026, GitHub made open source license compliance generally available, so license checks can now run automatically on every pull request.

This article explains why dependency licenses matter, how GitHub's new feature works, and what to ask the team that builds your software.

Why dependency licenses matter

A dependency is any library your application uses instead of writing that code from scratch. Libraries bring their own dependencies too, so the real list is often much longer than the one your developers chose directly. Each library's license defines what you may do with it, and organisations usually decide which licenses they accept.

The problem is timing. If an unacceptable license is discovered during an audit, an investment round or an acquisition, replacing the library can be slow and expensive. Catching it when the library is first added costs almost nothing.

What GitHub launched

• An enterprise-wide license policy, activated with a ruleset condition that requires license compliance results before merging.
• Automatic checks whenever a pull request adds or modifies dependencies, with an annotation for each noncompliant dependency.
• A dedicated role, Enterprise Open-Source License Manager, for people who review and approve exception requests.
• License data in the dependency graph and SBOM exports, now also for data-resident GitHub Enterprise Cloud customers.
• Audit log events and APIs, including an endpoint coding agents can use to avoid recommending packages that break the policy.

The feature is available for GitHub Enterprise Cloud customers, including data-resident ones, for repositories with GitHub Code Security enabled.

What happens when a dependency fails

According to GitHub, each annotation must be addressed by removing or replacing the dependency, amending the license policy, or creating a package exception. That turns license compliance into a normal part of code review rather than a separate project later.

License checks fit naturally next to other pipeline safeguards. Our article on securing your CI/CD pipeline covers how to lock workflow dependencies to reviewed code.

What to ask your software partner

1. 1Can we get a dependency list with licenses at handover, for example as an SBOM export?
2. 2Which licenses do you accept, and who decides when one is unusual?
3. 3Are licenses checked automatically when new libraries are added?
4. 4Who keeps dependencies up to date after launch?

Clear answers to these questions are part of a healthy project, alongside the scope and timeline covered in our MVP development guide.

What it means for your business

When you commission software, you also inherit everything it is built from. Knowing what is inside your application, and checking licenses as libraries are added, protects you from expensive surprises during audits, fundraising or acquisitions.

How Estontinc helps

Estontinc is a software house in Malang with 100+ projects and 50+ clients over more than six years. Through our custom software service we deliver dependency inventories with our projects and keep libraries maintained after launch. Our cloud and DevOps team adds automated dependency and license checks to your pipeline.

Want to know what is inside your application? Tell us about it through the contact page, and we will reply within 24 hours.