LicenseReviewProcessImprovementSpec

Revision 24 as of 2010-10-22 22:59:10

Clear message

Summary

The license statement for packages is not always accurate, due to conflicts at the file level inside the package. Improving the process for documenting the actual license(s) in effect, for a package, before it is accepted into main, is the goal.

Rationale

Package license statements do not always accurately reflect all of the actual licenses that need to be complied with for that package. See: 1

When a new packages is nominated for main, as part of the license check the individual files should be scanned for licenses. By using current open source tools to analyze the contents, the file level can be surveyed efficiently, and the licenses can be recorded accurately in the package before it is accepted into main.

Use Cases

  • A package is denoted to as released under BSD, however files inside it are licensed under GPLv2. If the files are part of the binary, then the source distribution requirement needs to be known to comply with. Knowing there are GPLv2 licensed files present, signals that better analysis in order to comply with the license terms may be required.

Scope

This specification covers the promotion of a new package into main. Once a new package has been adopted, ongoing scans to prevent inadvertent inclusion may be required.

Design

When a new package is nominated to be promoted into main:

  • The person nominating it, should run FOSSology, ninka, or one of the commercial tools on the package, and verify that the results at the file level match the declared license of the package.
  • If any file does not match the declared license of the package:
    • It should be documented as a detected license, in the information associated with the package.
  • If any detected license is incompatible with the declared license:
    • Before the package is accepted into main, the person nominating it should work with the package maintainer to resolve the licensing conflict.

    • a good summary of compatible/incompatible licenses can be found: 2

Summary

This specification is for a process change to be applied before accepting new packages into main, by using file level scanning tools to check the analysis.

Rationale

There is increased awareness in the commercial supply chain to ensure that the licenses code is released under can be complied to [3]. There is a legacy of projects where the intent of the package maintainer does not match what the licenses in the contents say [1]. This step is a low cost overhead to avoid the problem becoming worse.

Scope and Use Cases

Scope at this time is limited to packages getting added into main. We may want to extend it to updates to main packages to go through the file level scrutiny, but first step is to make sure new packages are license accurately documented as a condition of addition.

Use Cases

Implementation Plan

  • installation of common tools that can provide file level scanning
  • update process requirements[4] and process [5] to make license check explicit
  • file level exceptions to package license get documented in one of the emerging standard formats (DEP-5 or SPDX)
  • main archive approvers understand the new requirement and have a strategy to look for it.

Implementation

Outstanding Issues

  • process documentation and existing tools confuse copyright and licensing in places.
  • is there an approved list of licenses for packages that can go into main?
  • FOSSology server setup and access, or other tools?
  • mechanism to list all the licenses present in a package ( DEP-5 [8] , SPDX [9], ?? )

BoF agenda and discussion

We'll have a first public session on this at UDS-N

References

CategorySpec