Spdx Licenses Laravel Package

Technical Evaluation

Architecture Fit

• Lightweight and focused: The package is a pure validation/lookup library for SPDX licenses, with no dependencies beyond PHP core (post-v1.6.0). It fits seamlessly into Laravel’s dependency management and compliance workflows without introducing architectural bloat.
• SPDX-aligned: Directly maps to SPDX 3.x standards, ensuring compatibility with modern compliance tools (e.g., FOSSA, Black Duck, or custom SPDX-RDF generators).
• Stateless design: No external services or databases required—ideal for edge cases (e.g., CI/CD pipelines) or serverless Laravel deployments.
• Extensible: Core methods (getLicenseByIdentifier, validate) can be wrapped in Laravel services (e.g., LicenseValidatorService) or extended via traits for project-specific logic (e.g., custom license blacklists).

Integration Feasibility

• Composer-native: Designed for Composer ecosystems, with minimal friction for Laravel projects (e.g., composer require composer/spdx-licenses).
• PHP 7.2+ compatibility: Aligns with Laravel’s supported PHP versions (8.0+), avoiding legacy constraints.
• Zero-configuration: No database migrations, queues, or caching layers required. Instant validation via SpdxLicenses::validate($input).
• Laravel service provider pattern: Can be bootstrapped as a singleton in AppServiceProvider for global access:

  public function register() {
      $this->app->singleton(SpdxLicenses::class, fn() => new SpdxLicenses());
  }
  

• Artisan command integration: Easy to expose as a CLI tool (e.g., php artisan spdx:validate for project-wide license checks).

Technical Risk

Key Questions for TPM

1. Compliance Scope:

   • Will this be used for dependency validation only, or also for user-uploaded content (e.g., Laravel packages submitted via a marketplace)?
   • Are there custom license requirements beyond SPDX/OSI (e.g., proprietary licenses)?

2. Integration Points:

   • Should validation occur at Composer install time (e.g., via a custom plugin) or runtime (e.g., middleware for license-aware feature flags)?
   • Will results be logged, notified, or blocked (e.g., fail CI/CD on non-compliant licenses)?

3. Performance:

   • For large projects, will SpdxLicenses::getLicenses() be called frequently? If so, caching should be implemented.
   • Are there bulk validation needs (e.g., scanning all vendor/ dependencies)? Consider parallel processing with Laravel Queues.

4. Maintenance:

   • Who will update the package version when SPDX releases new license identifiers?
   • Should deprecation warnings trigger automated refactoring (e.g., via Laravel’s php artisan make:license-migration)?

5. Extensibility:

   • Will the library need custom rules (e.g., "block GPLv3 in proprietary modules")? If so, a decorator pattern or Laravel policy can extend functionality.
   • Should license data be exported (e.g., for SPDX-RDF generation)? The package provides raw data via getLicenses().

6. Error Handling:

   • How should invalid SPDX expressions be handled? Return exceptions, sanitize inputs, or log warnings?
   • Should deprecated licenses trigger runtime errors or just warnings?

7. Testing:

   • Are there existing license validation tests in the Laravel codebase that need adaptation?
   • Should mutual recursion tests be added to ensure SPDX expressions like MIT AND Apache-2.0 are handled correctly?

Integration Approach

Stack Fit

• Laravel Ecosystem:

  • Composer Integration: Validate licenses during composer install via a custom Composer plugin or post-install script.
  • Service Container: Register SpdxLicenses as a singleton for global access (e.g., app(SpdxLicenses::class)).
  • Artisan Commands: Create a spdx:validate command for ad-hoc checks:

    php artisan spdx:validate --file=composer.json --fail-on=deprecated
    

  • Middleware: Block requests from non-compliant dependencies (e.g., LicenseComplianceMiddleware).
  • Event Listeners: Trigger license checks on Composer\Installer\PackageEvent or Illuminate\Foundation\Application\Booted.

• PHP Stack:

  • PSR-11 Container: Works natively with Laravel’s DI container.
  • No Framework Lock-in: Pure PHP library—can be used in non-Laravel PHP projects (e.g., CLI tools, APIs).

Migration Path

Compatibility

• Laravel Versions: Compatible with Laravel 8+ (PHP 7.4+) and Laravel 9/10 (PHP 8.0+).
• Composer: Works with Composer 2.x (primary use case) and Composer 1.x (legacy support via v1.5.x).
• PHP Extensions: No dependencies beyond PHP core (post-v1.6.0).
• SPDX Standards: Aligns with SPDX 3.x, ensuring compatibility with tools like:
  • FOSSA
  • Black Duck
  • SPDX Tools

Sequencing

1. Phase 1: Validation Layer

   • Integrate SpdxLicenses into a Laravel service for license validation.
   • Add unit tests for core methods (validate, isOsiApprovedByIdentifier).
   • Example:

     $validator = new SpdxLicenses();
     if (!$validator->validate($package->getLicense())) {
         throw new LicenseValidationException("Invalid SPDX license: {$package->getLicense()}");
     }
     

2. Phase 2: Composer Integration

   • Create a custom Composer plugin or post-install script to enforce license rules.
   • Example plugin:

     use Composer\Plugin\PluginInterface;
     use Composer\EventDispatcher\EventSubscriberInterface;
     use Composer\Install