License Compliance Auditing via Dependency Analysis

The M&A due diligence request arrives on a Tuesday morning: complete open source license compliance report for all software, due Friday. The legal team has three days to produce an inventory of every open source component in the entire product codebase, every license that applies, every obligation that must be fulfilled before the acquirer’s legal review. For organizations that treat license compliance as a periodic manual review exercise, that Tuesday morning begins one of the most expensive fire drills in enterprise software. For organizations with mature dependency analysis infrastructure, it begins with running a report.

Software is mostly assembled, not written. The Black Duck 2026 OSSRA report found that 98% of commercial codebases contain open-source components, 87% have at least one known vulnerability, and the mean number of vulnerabilities per codebase has more than doubled year-over-year. License compliance auditing is the discipline that answers a different but related question: not just which components contain vulnerabilities, but which components impose legal obligations on how the software can be distributed, modified, or commercialized. A missed GPL-2.0 dependency in a proprietary commercial product is not a security incident. It is a licensing violation that can require source code disclosure, legal settlement, or product withdrawal.

The foundation of license compliance auditing is dependency analysis, the systematic identification of every software component that a codebase directly or indirectly depends on, with complete attribution of the license that governs each component. Dependency analysis is not a scan of the package manifest. It is a full structural examination of what the software actually includes at build time and runtime, regardless of whether those inclusions are declared, transitive, vendored, or implicit.

Why Dependency Analysis Is the Foundation

License compliance is a dependency problem before it is a legal problem. You cannot assess the license obligations of a software product without first knowing what that product is made of, every component, every library, every copied snippet. The license analysis is downstream of the dependency inventory. Get the inventory wrong and the license analysis is built on an incomplete picture.

Three questions that dependency analysis must answer for license compliance:

Hangi bileşenler dahildir? Not just the direct dependencies declared in package.json or pom.xml, but every transitive dependency they bring in, every vendored library copied into the source tree, every statically linked component compiled into the binary, and every dynamically loaded module called at runtime. A good SCA engine cross-references those components with vulnerability databases like the NVD, checks license metadata, and flags known exploits or legal risks before they impact your delivery pipeline. The same engine must also be accurate at the inventory level, what is actually in the software, before the license analysis can be trusted.

Under which licenses are they governed? A component may have a single declared license, a dual license with options, multiple licenses applying to different files, or a license that has changed across versions. FOSSA’s license detection engine claims 99.8% accuracy, which matters when your legal team needs to verify open-source obligations alongside the security inventory. License identification at the component level is necessary but insufficient, identifying at the file or snippet level is required for components where different files carry different licenses.

What obligations do those licenses impose? A permissive license (MIT, Apache-2.0) imposes attribution requirements. A weak copyleft license (LGPL) imposes different obligations depending on whether the component is linked dynamically or statically. A strong copyleft license (GPL-2.0, GPL-3.0) may require distributing the source code of the entire combined work. Understanding obligation requires understanding the license terms, not just the license identifier.

The Four Types of Dependencies That Create License Exposure

Not all dependencies are equally visible or equally governed by existing tooling. License exposure comes from four distinct dependency types, each requiring different discovery methods:

1. Package Manager Dependencies (declared and transitive)

The most visible layer: dependencies declared in manifest files (package.json, pom.xml, requirements.txt, go.mod, Cargo.toml) and the transitive dependencies they resolve at build time. Package manager dependencies are the best-covered category, SCA tools scan manifests, lockfiles, and build artifacts to enumerate them.

The critical distinction is between direct and transitive. A direct dependency is the one the developer chose. A transitive dependency is what the direct dependency requires. A developer who adds a single react-data-grid package to a Node.js project may be importing dozens of transitive dependencies, each with its own license. The developer did not choose those licenses. They exist in the dependency tree regardless.

json

// package.json: 1 direct dependency declared
{
  "dependencies": {
    "react-data-grid": "^7.0.0"
  }
}

// npm lockfile resolves to 47 transitive dependencies, including:
// - react@18.2.0 (MIT)
// - clsx@1.2.1 (MIT)
// - scheduler@0.23.0 (MIT)
// - tslib@2.6.0 (0BSD)
// - ...43 more, each with its own license
// The developer declared 1 license obligation; they shipped 47.

The transitive license trap: The license risk is not in what you declared. It is in what your dependencies declared, and what their dependencies declared. A clean direct dependency tree with permissive licenses can conceal a GPL-licensed transitive dependency three levels deep that imposes copyleft obligations on the entire distribution.

2. Vendored and Copied Source Code

Source code from external projects copied directly into the repository, a pattern common in C/C++ projects, Go projects without modules, and legacy codebases. Vendored code does not appear in package manager manifests because it was added through copy-paste rather than through a dependency manager.

SCANOSS’s snippet-level scanning goes well beyond manifest-based detection, matching source code fragments against over 100 million open source files in the OSSKB. Snippet-level scanning is required to identify vendored code and copied functions, approaches that declare no manifest dependency but carry full license obligations as if the component had been explicitly included.

A vendored utility function copied from a Stack Overflow answer that originated in GPL-licensed code carries the same copyleft obligation as a direct GPL dependency, but it appears nowhere in the package manifest, the lockfile, or any automated scan that reads only declared dependencies.

3. Statically Linked Libraries

Libraries compiled directly into the application binary at build time. Unlike dynamically linked libraries that exist as separate files at runtime, statically linked libraries are embedded in the executable. They are not visible in package manager manifests, they appear in build configurations (Makefile, CMakeLists.txt, linker scripts) and in the compiled binary itself.

For LGPL-licensed libraries specifically, the static versus dynamic linking distinction determines the license obligation. LGPL permits dynamic linking without copyleft propagation; static linking may trigger copyleft requirements on the combined work. A binary analysis tool that examines the compiled artifact, rather than only the source manifest, is required to identify statically linked components and their licenses.

4. Runtime-Loaded Dependencies

Libraries loaded dynamically at runtime through plugin architectures, late binding, or scripting engine integrations. These dependencies may not be resolvable from source code analysis alone, they depend on the runtime environment, configuration, and execution path. Database drivers loaded through reflection, parser plugins discovered through service loader mechanisms, and scripting extensions loaded from filesystem paths at startup are all runtime dependencies with potential license implications.

License Risk Categories and Their Obligations

Open source licenses fall along a spectrum from permissive to restrictive. Understanding where each license sits on this spectrum determines the compliance obligation it creates:

İzin verici lisanslar (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC)

Yükümlülük: Attribution, include the license text and copyright notice in distributions. Source code disclosure not required. Commercial use permitted without restriction. Integration into proprietary products permitted.

Risk level for commercial software: Low. Attribution is easy to fulfill automatically.

Weak copyleft licenses (LGPL-2.0, LGPL-2.1, LGPL-3.0, MPL-2.0, EUPL-1.2)

Yükümlülük: Attribution plus modifications to the licensed component must be shared. For LGPL specifically: dynamic linking generally satisfies the license without triggering copyleft on the calling code; static linking may not.

Risk level for commercial software: Medium. Depends on linking method. Dynamic linking is usually safe; static linking requires careful legal review.

Strong copyleft licenses (GPL-2.0, GPL-3.0, AGPL-3.0)

Yükümlülük: Attribution plus the entire combined work that includes the GPL component must be made available under GPL terms (source code disclosure). AGPL extends this to software accessed over a network.

Risk level for commercial software: High. A GPL-licensed component statically linked into or derived from a proprietary commercial product may require disclosure of the proprietary source code. This is the license risk that generates the largest legal settlements.

Network copyleft (AGPL-3.0)

Yükümlülük: All obligations of GPL-3.0, plus: users who interact with the software over a network are considered to be receiving the software, triggering the source disclosure obligation even for SaaS products that never distribute binaries.

Risk level for SaaS products: Very high. AGPL is specifically designed to close the “SaaS loophole” in GPL. A commercial SaaS product that includes an AGPL component must disclose its source to any user who interacts with it over a network.

Proprietary and commercial licenses

Yükümlülük: Defined by the license agreement, varies from “no redistribution” to “per-unit royalty” to “enterprise seat license.” These are not open source but appear in dependency trees when commercial components are used.

Risk seviyesi: Varies by terms. Often discovered during M&A due diligence when the license fee obligations of acquired products are enumerated.

License Compatibility: The Matrix That Matters

When components with different licenses are combined in a single software product, the licenses must be compatible. Incompatible license combinations create legal risk that cannot be resolved by attribution alone, the combination itself may violate one or both licenses.

Birlikte	İLE	Apaçi-2.0	LGPL-2.1	GPL-2.0	GPL-3.0	PLFA-3.0
İLE	Uyumlu	Uyumlu	Uyumlu	Uyumlu	Uyumlu	Uyumlu
Apaçi-2.0	Uyumlu	Uyumlu	Uyumlu	Uyumsuz	Uyumlu	Uyumlu
LGPL-2.1	Uyumlu	Uyumlu	Uyumlu	Uyumlu	Uyumsuz	Uyumsuz
GPL-2.0	Uyumlu	Uyumsuz	Uyumlu	Uyumlu	Uyumsuz	Uyumsuz
GPL-3.0	Uyumlu	Uyumlu	Uyumsuz	Uyumsuz	Uyumlu	Uyumlu
Özel	Uyumlu	Uyumlu	Dikkat	Uyumsuz	Uyumsuz	Uyumsuz

The most consequential incompatibility for commercial software: Apache-2.0 and GPL-2.0 are incompatible. An Apache-2.0 licensed library cannot be combined with a GPL-2.0 licensed component in the same work. Since many foundational open source components (Linux kernel modules, some older Java libraries) are GPL-2.0 rather than GPL-3.0, this incompatibility creates real compliance risk in mixed dependency trees.

The AGPL-3.0 row is the most restrictive for SaaS: essentially nothing combines cleanly with AGPL-3.0 in a commercial product without triggering the network copyleft obligation.

Enforcing License Policy in CI/CD

License compliance that depends on periodic audits fails at the moment of introduction: the GPL dependency that someone added last sprint has been in production for three weeks before the quarterly audit catches it. Continuous enforcement at the merge gate is the only approach that prevents non-compliant dependencies from entering the codebase.

tatlım

# GitHub Actions: license compliance gate on every PR
name: License Compliance Check

on:
  pull_request:

jobs:
  license-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install license checker
        run: npm install -g license-checker fossa-cli

      - name: Scan dependency licenses
        run: |
          license-checker --summary --excludePrivatePackages \
            --out license-report.json

      - name: Enforce license policy
        run: |
          # Block GPL-2.0, GPL-3.0, AGPL-3.0, SSPL in commercial product
          FORBIDDEN=$(license-checker --failOn \
            "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL" \
            --excludePrivatePackages 2>&1 || true)

          if echo "$FORBIDDEN" | grep -q "FAIL"; then
            echo "Forbidden license detected in dependencies"
            echo "$FORBIDDEN"
            exit 1
          fi

      - name: Generate SBOM artifact
        run: |
          # Generate CycloneDX SBOM for audit trail
          npx @cyclonedx/cyclonedx-npm \
            --output-file sbom-$(date +%Y%m%d).json

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom-*.json

Dikkat et: License policy is organization-specific. The forbidden list in the example above reflects a common commercial policy, but your organization’s legal team must define which licenses are permitted, flagged for review, and forbidden for your specific product type, distribution model, and customer agreements. A library permitted in an internal tool may be forbidden in a customer-distributed product.

SBOM Generation and Format Standards

A Software Bill of Materials (SBOM) is the structured artifact that makes license compliance auditable, shareable, and machine-verifiable. Compliance teams can confirm license obligations without manual audits when an SBOM provides this data. Two formats dominate the market:

SiklonDX, developed by OWASP, designed for security and supply chain use cases. Supports components, services, vulnerabilities (VEX), formulas, and machine learning model bills of materials. The preferred format for security-focused SBOMs and the format required by most modern SCA tool integrations.

SPDX, maintained by the Linux Foundation, the ISO/IEC standard (ISO 5962:2021). Required by some government procurement standards including aspects of EO 14028. More focused on license compliance than security, with a richer license expression language (SPDX expressions can capture complex multi-license scenarios: GPL-2.0-only AND MIT OR Apache-2.0).

EO 14028 already blocks non-SBOM vendors from federal contracts, the CRA starts enforcing vulnerability reporting in September 2026, and PCI DSS 4.0 is already in the auditors’ hands. You are either shipping SBOMs or you are losing deals.

For enterprise software products, producing both formats costs little beyond generating from the same dependency analysis. The audience for each differs: security teams and vulnerability management workflows consume CycloneDX; legal teams, procurement, and regulatory compliance workflows typically prefer SPDX.

The Legacy Codebase Problem: No Package Manager, No Manifest

The dependency analysis tooling described above, SCA scanners, lockfile parsers, SBOM generators, operates on the assumption that software dependencies are managed through package managers and declared in manifest files. This assumption holds for modern Java, JavaScript, Python, Go, and Rust projects. It does not hold for legacy enterprise environments built on COBOL, JCL, and mainframe platforms.

In a mainframe environment, third-party software dependency manifests in three ways that standard SCA tools cannot detect:

Licensed sort and utility products. JCL job streams call utility programs, sort products (DFSORT, SyncSort/Syncsort now known as Precisely, CA Sort), report writers (SAS, EASYTRIEVE), and data conversion tools, that are licensed commercial software with their own license terms, maintenance contracts, and compliance requirements. These appear in JCL as PGM=SORT, PGM=IEBGENER, PGM=ICETOOL, program names, not package identifiers. No SCA tool that reads package.json or pom.xml onları bulacak.

Vendor-supplied COBOL copybooks. Third-party software vendors supply COBOL copybooks that are licensed software. A fintech software vendor that provides COBOL programs for payment processing may supply copybooks that define their proprietary data structures. Every COBOL program that includes those copybooks is using licensed software. The license obligations are real; the package manager entry does not exist.

Embedded algorithms from licensed sources. Financial institutions running COBOL systems may have incorporated licensed algorithms, actuarial calculation routines, cryptographic implementations, numerical analysis libraries, directly into COBOL source code. These may have originated as licensed source that was compiled into the codebase and cannot be identified from package managers.

For these components, the discovery method is source code analysis: tracing CALL statements to identify called programs, examining COPY statements to identify included members, and matching program names against a registry of known third-party components. The output feeds the same license compliance workflow, but it requires a tool that understands COBOL and JCL semantics, not just modern package manifest formats.

Building the Audit-Ready Compliance Package

When legal, compliance, or an external auditor requests license compliance evidence, a scan report is necessary but not sufficient. The audit-ready compliance package contains:

• Complete dependency inventory, every component, version, and license, including transitive dependencies, organized by product and version
• License obligation matrix, for each license category present, the specific obligations (attribution, source disclosure, modification notice) and how each is fulfilled
• Attribution notices file, compiled legal notices for all components that require attribution, in the format required by each license (NOTICE file for Apache-2.0, LICENSE file for MIT, etc.)
• Incompatibility analysis, documentation that no incompatible license combinations are present in the combined product, with legal rationale for any boundary cases
• SBOM artifact, current CycloneDX or SPDX file, signed and timestamped, covering all components in scope
• Politika belgeleri, the organization’s written open source license policy, including the approval process for new licenses
• Onay kayıtları, for any license requiring legal review before inclusion, the documented approval and the business justification
• Remediation history, documentation of any previously identified violations and the actions taken to resolve them

For M&A due diligence specifically: Acquirers increasingly request this package as part of technical due diligence. A clean compliance package with no unresolved violations accelerates the diligence process. A package that reveals unresolved GPL violations in a proprietary product typically results in either price adjustment, escrow requirements, or remediation as a closing condition, all of which are more expensive than the compliance program that would have prevented them.

Ne kadar SMART TS XL Supports License Compliance in Enterprise Codebases

SMART TS XL'S uygulama bağımlılık eşlemesi provides the structural dependency analysis layer for enterprise codebases, particularly in the legacy environment where standard SCA tools reach their limits.

For mainframe environments, the dependency map identifies every program called by every other program (surfacing third-party utility calls embedded in JCL and COBOL), every copybook included by every program (surfacing vendor-supplied copybook dependencies), and every dataset accessed by every program (surfacing data-layer dependencies on licensed database products). This analysis produces the component inventory that is the precondition for license compliance auditing in environments where no package manager exists.

MKS statik kod analizi capability identifies code patterns associated with specific third-party components: proprietary API call signatures, vendor-specific data structure conventions, and licensed algorithm implementations embedded in custom COBOL source. These findings supplement the manifest-based inventory with the code-level dependencies that manifest scanning cannot reach.

MKS etki analizi capability makes license policy changes actionable: if a component’s license changes, a dependency relicenses from MIT to AGPL-3.0, a vendor modifies their terms, the impact analysis identifies every program in the portfolio that depends on that component, either directly or transitively. This converts a license change event from an unknown risk into a defined remediation scope.

MKS kurumsal arama capability makes the dependency inventory queryable for compliance purposes: find every program that calls a specific utility, every copybook that includes a specific vendor-supplied member, every program that depends on a specific licensed component, in seconds, across the full legacy portfolio. This search capability is the practical tool for the Tuesday morning M&A audit request: a query rather than a manual review.

For organizations building comprehensive SBOM coverage that spans both modern and legacy systems, SMART TS XL provides the legacy component inventory that standard SBOM generators cannot produce, complementing tools like Syft, FOSSA, and Dependency-Track for the modern stack.

The Audit That Should Never Be a Surprise

License compliance auditing is one of the few regulatory disciplines where the penalty for non-compliance is frequently discovered not by a regulator but by a business partner, an acquirer, a customer’s legal team, or a distributor who reads the license terms and asks for evidence of compliance. The cost of that discovery ranges from awkward to existential depending on the severity of the violation and the stage of the transaction.

The dependency analysis program that prevents this discovery from being a surprise is not expensive relative to the risk it mitigates. It requires knowing what is in the software, every component, every transitive dependency, every vendored snippet, every legacy utility, and checking each against the organization’s license policy continuously rather than periodically. The tools exist. The standards (SBOM, SPDX, CycloneDX) exist. The regulatory mandate (EO 14028, CRA, PCI-DSS 4.0) exists. The only missing piece, for most organizations, is the discipline to treat dependency analysis as infrastructure rather than as an audit exercise.

The Tuesday morning that begins with a report instead of a fire drill is the Tuesday morning that dependency analysis infrastructure made possible.