Spdx Licenses Laravel Package

Technical Evaluation

Architecture Fit

• Lightweight and focused: The package is a pure validation/lookup library with no dependencies beyond PHP, making it ideal for compliance checks without bloating the stack.
• SPDX-aligned: Directly integrates with the official SPDX license list (3.28+), ensuring regulatory compliance (e.g., EU DORA, SBOMs).
• Laravel-friendly: Works seamlessly with Composer (already used in Laravel ecosystems) and can be embedded in service layers, middleware, or CLI tools.
• Extensible: Provides hooks for custom validation logic (e.g., blacklisting non-OSI licenses) via validate() method.

Integration Feasibility

• Zero-configuration: Install via composer require composer/spdx-licenses and use SpdxLicenses class.
• Laravel service provider pattern: Can be wrapped in a ServiceProvider for dependency injection (e.g., app()->make(SpdxLicenses::class)).
• Middleware integration: Validate licenses in HTTP requests (e.g., block non-compliant dependencies in SaaS APIs).
• Artisan command: Build a spdx:audit command for CLI-based compliance checks.
• Event listeners: Trigger license validation on package installation/updates (via Composer events).

Technical Risk

Key Questions

1. Compliance Scope:
   • Should license validation apply to all dependencies or only direct dependencies?
   • Do we need to block builds on non-compliant licenses (CI/CD) or just warn?
2. SPDX Version Strategy:
   • Should we lock to a specific SPDX version (e.g., 3.28) or auto-update with the package?
3. Custom Rules:
   • Do we need organization-specific license policies (e.g., "Reject GPLv3 in proprietary modules")?
4. Performance:
   • Will getLicenses() be called frequently (e.g., per request)? If so, cache aggressively.
5. Error Handling:
   • Should invalid licenses fail fast (e.g., throw InvalidArgumentException) or log and continue?
6. Laravel Integration:
   • Should this be a global helper (app('spdx')) or a contextual service (e.g., only in audit routes)?
7. Audit Trail:
   • Do we need to record license validation results (e.g., in a database for compliance reporting)?

Integration Approach

Stack Fit

• Laravel Ecosystem:
  • Composer: Native integration (already used for dependencies).
  • Service Container: Inject SpdxLicenses as a singleton or context-bound service.
  • Artisan: Build CLI tools for manual audits or CI/CD hooks.
  • Middleware: Validate licenses in incoming requests (e.g., block non-compliant dependency usage).
  • Events: Trigger validation on package install/update (via Composer’s post-autoload-dump).
• PHP Extensions:
  • Works with any PHP 7.2+ project (Laravel 8+).
  • Compatible with Lumen (micro-framework) or standalone PHP scripts.

Migration Path

Compatibility

• Laravel Versions:
  • Laravel 9/10: Use composer/spdx-licenses:^1.6 (PHP 7.2+).
  • Laravel 8: Use composer/spdx-licenses:^1.5 (PHP 5.3+).
• Composer:
  • Works with Composer 2.x (recommended) and 1.x (legacy).
  • Can be used alongside other Composer plugins (e.g., composer/audit).
• SPDX Spec:
  • Supports SPDX 3.0+ (latest: 3.28). Ensure your license expressions comply.

Sequencing

1. Phase 1: Validation Layer
   • Add SpdxLicenses to a ServiceProvider (e.g., App\Providers\SpdxServiceProvider).
   • Example:

     $this->app->singleton(SpdxLicenses::class, function ($app) {
         return new SpdxLicenses();
     });
     

2. Phase 2: CLI Audit Tool
   • Create an Artisan command to scan composer.json files:

     php artisan spdx:audit --fail-on=deprecated,non-osi
     

3. Phase 3: CI/CD Integration
   • Add a GitHub Action to fail builds on license violations:

     - name: Check SPDX Licenses
       run: composer validate --check-licenses
     

4. Phase 4: Runtime Enforcement
   • Add middleware to block non-compliant dependencies in production:

     public function handle(Request $request, Closure $next) {
         $license = $request->dependency->license;
         if (!$this->spdx->isOsiApprovedByIdentifier($license)) {
             abort(403, "Non-compliant license detected.");
         }
         return $next($request);
     }
     

5. Phase 5: Composer Plugin
   • Build a custom Composer plugin to enforce licenses during composer install:

     // src/Plugin.php
     public function onPostAutoloadDump() {
         $licenses = new SpdxLicenses();
         foreach ($this->getComposer()->getRepositoryManager()->getLocalRepository()->getPackages() as $package) {
             if (!$licenses->isOsiApprovedByIdentifier($package->getLicense())) {
                 throw new \RuntimeException("Non-OSI license detected: {$package->getLicense()}");
             }
         }
     }
     

Operational Impact

Maintenance

• Low Effort:
  • No manual license list updates: SPDX data is auto-updated by the package maintainers.
  • Minimal code changes: Validation logic is stable (only SPDX spec changes may require testing).
• Dependencies:
  • Single Composer package: No additional dependencies beyond PHP.
  • Monitor for SPDX updates: Subscribe to SPDX announcements for breaking changes.
• Deprecation Handling:
  • Use isDeprecatedByIdentifier() to log warnings or block deprecated licenses.
  • Example:

    if ($this->spdx->isDeprecatedByIdentifier($license)) {
        \Log::warning("Deprecated license detected: {$license}");
        // Optionally: throw new \