Composer License Checker Laravel Package

Product Decisions This Supports

• License compliance readiness for enterprise sales: Legal/procurement and security questionnaires routinely ask which OSS licenses ship in the product. This package produces that inventory on demand, turning a multi-day legal scramble into a repeatable command — a direct enabler for closing enterprise or regulated-industry deals.
• Build vs. buy / vendor-risk review: Before committing to a dependency (or an acquisition/technical due diligence), PMs can see whether a package is MIT/Apache (permissive, low obligation) versus GPL/AGPL (copyleft, potential source-disclosure or distribution constraints). This informs architecture and procurement choices, not just engineering hygiene.
• Roadmap and release gating: An automated CI check enforces the company's OSS policy so a restrictive license cannot silently enter the product through a routine dependency bump. That is a governance decision — "we will not ship copyleft without legal review" — encoded as a check rather than a wiki page.
• Use cases to prioritize: pre-release license audits, customer security/compliance packages, M&A and vendor due diligence, and an internal open-source contribution policy for the platform team.
• Signal for investment sizing: The 0.83 opportunity score and modest adoption (58 stars) suggest a real but narrow pain — strongest in Laravel shops selling to enterprises, not in consumer or pre-revenue products.

When to Consider This Package

Adopt when:

• The product is PHP/Laravel and dependencies are managed with Composer — the tool speaks the native ecosystem with no extra platform.
• You need a cheap, fast, CI-friendly license gate and do not yet have a software composition analysis (SCA) vendor.
• Legal/compliance has asked for license visibility, or an enterprise customer's questionnaire is blocking a deal.
• You want a low-ops, MIT-licensed utility your own engineers can read, fork, and maintain.

Look elsewhere when:

• The stack is polyglot (Node, Python, Go, containers). A Composer-only scanner leaves most of the surface unscanned; a multi-ecosystem SCA tool wins.
• The requirement is vulnerability scanning, not license policy. This tool answers "what licenses," not "what CVEs."
• You need SBOM generation (SPDX/CycloneDX) or attestation for regulated or government buyers.
• You need enterprise workflow: legal review queues, exception tracking, policy dashboards, SSO, and audit trails. Buy (FOSSA, Snyk, Mend) rather than build.
• The team is small and pre-compliance; a one-time license audit may be enough, and adding a CI gate creates friction before there is a policy to enforce.

How to Pitch It (Stakeholders)

To executives: This is inexpensive insurance against a license problem that can stall an enterprise deal, force a re-architecture, or trigger a legal review at the worst possible moment. It gives us a defensible answer to "what open source are you shipping?" and prevents an engineer's routine dependency update from quietly introducing obligations we cannot meet — for the price of a CI check, not a vendor contract.

To engineering: One Composer command lists every dependency's license; one CI step fails the build if a disallowed license appears. It is MIT-licensed, native to our stack, and cheap to run — no dashboards, no agents. It deliberately does not replace vulnerability scanning or SBOM tooling; treat it as the license-policy layer, and keep SCA on the roadmap if compliance requirements widen.