Composer License Checker Laravel Package

Product Decisions This Supports

• Compliance-as-code in the definition of done. Turning your license policy into a versioned .allowed-licenses.php file makes "no unapproved licenses ship" an enforceable acceptance criterion on every PR rather than a periodic legal audit. This is a roadmap enabler for any release gate or "production readiness" checklist you already own.
• Build vs. buy. The capability is narrow and deterministic: read dependency metadata, compare against an allow-list, exit non-zero. That is a ~100-line internal script. This package is the "buy" option that costs one dev dependency and one config file, so the decision is not budget but ownership: do you want to maintain a homegrown checker, or adopt a small MIT-licensed tool you can fork if abandoned? (14 stars / 0 dependents means you are effectively the maintainer of last resort — plan for that.)
• Enterprise and procurement readiness. Security questionnaires, SOC 2 style reviews, customer IP indemnification clauses, and vendor onboarding forms increasingly ask "how do you track third-party license obligations?" A CI-enforced allow-list plus its JSON output gives you an answerable, demonstrable control.
• M&A / IP due diligence prep. Copyleft exposure (GPL/AGPL) in a distributed or on-prem product is a diligence finding. Running this in CI creates a running record of dependency license posture instead of a fire drill.
• Open-sourcing or dual-licensing decisions. Before publishing an internal package or an OSS component, you need to know whether your dependency tree is compatible with the license you intend to ship under. This is a cheap pre-check.
• Roadmap scoping for "supply chain" work. Running it once gives a baseline inventory and a violation list; that list sizes the real workstream (replacing a GPL dependency vs. accepting a documented exception).
• Governance of exceptions. addAllowedVendor() and addAllowedPackage() are explicit escape hatches. That is good product design — it forces exceptions to be visible and reviewable in code review rather than hidden in tribal knowledge. Treat each entry as a decision record with an owner.
• Use cases that fit well: Laravel/PHP monoliths and APIs, agency/client deliverables where each client has its own license policy (via --allow-file), internal packages with an allow-list of vendors, and pre-release checks for distribution-style products.
• Signals from the package itself that shape the decision: it is a dev-only tool (no runtime footprint, no production risk), it has two license providers (installed.json default — no Composer binary needed, but it parses a Composer-internal schema that can change; composer licenses — more stable API, needs Composer present), it supports --format json for dashboards/ticketing, and it handles disjunctive licensing and packages with no declared license (both of which are where naive grep-based scripts break). Note the runtime constraint: v1.4.x requires PHP 8.4+ (it dropped 8.2); v1.2.x covers PHP 8.2/8.3. Verify parity with your app's PHP version before committing.

When to Consider This Package

Adopt when:

• Your stack is PHP/Composer-only (or PHP-dominant with a single Composer root). This tool has no view into npm, pip, Go modules, or container base images.
• You are on PHP 8.4+ for v1.4.x, or willing to pin v1.2.x on 8.2/8.3. Check this first — it is the most likely blocker.
• Your policy is expressible as an allow-list of licenses plus vendor/package exemptions. That covers the majority of real policies.
• You have a CI pipeline and want a fast, deterministic, exit-code gate — no account, no network call, no SaaS contract, no data leaving your build.
• You want the check at the PR level, close to the engineer who added the dependency, so violations get fixed by the person with context.
• You accept a single-vendor, small-community dependency: 14 stars, 0 dependents, MIT license, active maintenance, small surface area. The mitigation is that the code is small and MIT — forking is realistic if it stalls.
• You want machine-readable output for a dashboard or ticket automation (--format json).

Look elsewhere when:

• You are polyglot or need one control across all ecosystems — buy an SCA platform (Snyk, FOSSA, Mend/WhiteSource, Black Duck, Debricked) rather than stitching N single-ecosystem checkers.
• You need licenses + vulnerabilities + SBOM (CycloneDX/SPDX) in one artifact. This generates no SBOM and scans no CVEs.
• You need attribution output — NOTICE files, third-party license text bundles shipped with a distributed binary. This checks compliance, it does not assemble the notices.
• You need legal workflow: approval queues, exception expiry dates, owner attestations, dashboards, and an audit trail suitable for a regulator. This gives you a CI exit code and JSON; the process layer is yours.
• You need vendor support, an SLA, or a security review of the tool itself as a procurement requirement.
• You want enforcement at the registry/proxy level (blocking a package from being installed at all) rather than detecting it post-install.
• You cannot tolerate the installed.json provider's reliance on a Composer-internal schema, and you also cannot guarantee the composer binary in the CI image. One of the two providers must be viable for you.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: This is a small, free, MIT-licensed developer tool that adds an automated license-compliance gate to our PHP build pipeline. It reads the licenses of every Composer dependency we install, compares them against a policy file we control, and fails the build if anything unapproved appears. The cost is roughly an afternoon of setup and one CI step; the return is a continuously verified answer to "what open-source license obligations are we carrying?" — the question that shows up in enterprise security questionnaires, customer contracts, M&A diligence, and any decision to open-source or redistribute our code. It reduces the risk of discovering a copyleft (GPL/AGPL) dependency after it has shipped, when remediation is expensive and legal review is urgent. It is dev-only: nothing is added to production, no data leaves our CI, and no vendor contract is required. Adoption risk is low because the tool is small and MIT-licensed — if the upstream project stalls, we can fork it.

For engineering — the pitch:

• Install as a dev dependency: composer require --dev lendable/composer-license-checker. No runtime footprint.
• One config file in the repo root, .allowed-licenses.php, declaring permitted licenses (MIT, BSD-2/3-Clause, Apache-2.0, ...), plus addAllowedVendor() for our own org and addAllowedPackage() for justified exemptions. The config is code — it goes through review, so exceptions are explicit and attributable.
• One CI line: ./vendor/bin/composer-license-checker. Non-zero exit fails the build. Wire it next to the static analysis and test jobs.
• Use --provider-id=json (default) to avoid needing the Composer binary in the check container; switch to --provider-id=licenses if the installed.json schema drifts.
• --format json if we want to feed results into a dashboard or auto-open a ticket.
• It already handles the edge cases a homegrown grep script gets wrong: disjunctive license expressions and packages declaring no license at all.
• Prerequisite: PHP 8.4+ for the current line (pin v1.2.x if we are still on 8.2/8.3).

What to be honest about internally: This is a policy-enforcement mechanic, not a compliance program. It does not scan for vulnerabilities, does not produce an SBOM, and does not generate attribution notices. It has a small community footprint, so we own the upgrade path. Set expectations accordingly: it answers "are we violating our stated license policy?" — not "are we legally safe?" That second question is a legal-review process, and this tool's job is to make sure legal only ever sees genuine exceptions instead of a spreadsheet.