Why you should always check licenses in your PHP project

Source: Dev.to

When we consider dependencies in a PHP project, we typically focus on security, performance, and maintenance. One critical aspect is often overlooked: software licenses.

Whether you are building an open‑source library, a commercial SaaS, or a private internal application, the licenses of your dependencies matter. Ignoring them can lead to legal risks, compliance issues, and unexpected obligations.

Composer provides a built‑in command to help with this:

composer licenses

In this article we’ll explore why license checks are essential and how to use Composer’s tooling—especially the summary and JSON output formats—to keep your project compliant and under control.

Why license compliance matters (even for applications)

A common misconception is:

“I’m building an application, not an open‑source library; licenses don’t matter.”

This is not true. Checking the licenses used in a project is essential for several important reasons.

Legal obligations

Some licenses (e.g., GPL) may require you to:

• Disclose source code
• Use the same license for derivative works
• Provide attribution or license texts

Commercial restrictions

Certain licenses are incompatible with proprietary software or paid products.

Future‑proofing

Today’s internal tool might become:

• An open‑source project
• A commercial product
• Part of a larger ecosystem

CI/CD & compliance

Many companies require license audits as part of:

• Security reviews
• Vendor assessments
• Release pipelines

Knowing what you depend on is not optional; it’s responsible software development.

Getting an overview with composer licenses -f summary

The quickest way to understand your project’s license landscape is:

composer licenses -f summary

The command generates a table that lists each license together with the number of packages that use it. Example output:

-------------- ------------------------
 License        Number of dependencies
-------------- ------------------------
 MIT            81
 BSD-3-Clause   33
 BSD-2-Clause   2
 GPL-2.0-only   2
 GPL-3.0-only   2
 proprietary    1
 Apache-2.0     1
-------------- ------------------------

What the summary tells you

• MIT / BSD / Apache – Generally permissive and safe for most projects.
• GPL‑2.0‑only / GPL‑3.0‑only – Strong copyleft licenses that may impose redistribution obligations.
• proprietary – A red flag that requires manual review.

If you want to learn more about open‑source licenses, visit the Open Source Initiative license list.

The summary output is perfect for:

• Quick audits
• Documentation
• Team discussions
• Deciding whether deeper analysis is needed

However, it doesn’t indicate which packages are responsible for those licenses. For that, use the JSON output format.

Going deeper with composer licenses -f json

For automated checks or detailed analysis, Composer can output machine‑readable data:

composer licenses -f json

The JSON includes:

• Project metadata (name, version, license)
• A dependencies object where each dependency contains its version and one or more license entries

Example:

{
  "name": "laravel/laravel",
  "version": "dev-main",
  "license": ["MIT"],
  "dependencies": {
    "brick/math": {
      "version": "0.14.1",
      "license": ["MIT"]
    },
    "some/gpl-package": {
      "version": "1.2.3",
      "license": ["GPL-3.0-only"]
    }
  }
}

This format is ideal for:

• CI pipelines
• Custom policy enforcement
• Reporting tools
• Automated alerts

Checking license policies with PHP

Once you have the JSON output, you can automatically verify that all dependencies comply with your organization’s allowed‑license list.

Assume the project only permits the following licenses:

MIT;BSD-2-Clause;BSD-3-Clause;Apache-2.0

A small PHP script can detect disallowed licenses:

/dev/null', $output, $exitCode);

if ($exitCode !== 0) {
    fwrite(STDERR, "Failed to execute composer licenses\n");
    exit(1);
}

$data = json_decode(implode("\n", $output), true);

// Check dependencies
foreach ($data['dependencies'] as $name => $package) {
    $licenses = $package['license'] ?? [];

    // If none of the licenses are in the allowed list, report it
    if (!array_intersect($licenses, $allowedLicenses)) {
        echo sprintf(
            "%s (%s) -> %s\n",
            $name,
            $package['version'] ?? 'unknown',
            $licenses ? implode(', ', $licenses) : 'NO LICENSE'
        );
    }
}

The script:

• Runs composer licenses -f json directly
• Parses the output safely
• Checks each dependency’s license against the whitelist
• Reports packages that violate the policy

You can easily extend this to:

• Fail a CI build
• Generate compliance reports
• Send alerts
• Whitelist or blacklist specific packages

Why checking licenses matters in practice

Automating license checks:

• Prevents accidental license violations
• Protects your company and clients
• Makes compliance repeatable and auditable
• Encourages better dependency hygiene

Most importantly, it shifts license compliance from a “nice‑to‑have” afterthought to an integral part of your development workflow.

Takeaway: Use composer licenses -f summary for a quick overview, and composer licenses -f json together with a small script (or a dedicated tool) for automated, policy‑driven compliance checks. This keeps your PHP projects legally safe and development‑ready.

Final thoughts

Composer already gives you the tools—you just need to use them.

• Use composer licenses -f summary for a quick overview.
• Use composer licenses -f json for automation and deep analysis.
• Integrate license checks early, not after problems arise.

Dependency management is not just about code.
It’s also about responsibility.