Why you should always check licenses in your PHP project

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

This command generates an output that lists the licenses used, along with the number of packages that use each license. In the output example, we can see that for my current project, the most used license by the dependencies is the license "MIT".

-------------- ------------------------
 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
-------------- ------------------------

This summary gives a clear picture of how licenses are distributed across your dependencies.

• MIT / BSD / Apache These are 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 are interested in going deeper into Licenses, you can take a look at: https://opensource.org/licenses

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, we can use the JSON output format.

Going deeper with composer licenses -f json

To perform automated checks or detailed analysis, Composer can output machine-readable data:

composer licenses -f json

The JSON output includes:

• Project metadata (name, version, license)
• A dependencies object where each dependency includes:
  • Package name
  • Version
  • One or more licenses

The JSON output follows a structure similar to the one shown below.

{
  "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 JSON output, you can automatically check your organization’s license policy.

Let’s say your project only allows:

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

Using the JSON output, we can write a small PHP script to automatically detect disallowed licenses.

<?php

$allowedLicenses = explode(';', 'MIT;BSD-2-Clause;BSD-3-Clause;Apache-2.0');

// Execute Composer and capture JSON output
exec('composer licenses -f json 2>/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 (!array_intersect($licenses, $allowedLicenses)) {
        echo sprintf(
            "%s (%s) -> %s\n",
            $name,
            $package['version'] ?? 'unknown',
            $licenses ? implode(', ', $licenses) : 'NO LICENSE'
        );
    }
}

The scripts:

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

You can easily extend this to:

• Fail a CI build
• Generate 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 manual afterthought to an integrated development practice.

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.