Technical Team/Minutes/2018-02-05

From SPDX Wiki
Jump to: navigation, search

February 5, 2019


  • Kate Stewart
  • Gary O'Neall
  • Michael Herzog
  • Dennis Clark

License Namespace Proposals

  • We discussed the license namespace proposal Mark Atwood circulated on the email distribution list
  • Since Mark was not on the call, we agreed to not finalize any proposal until we’ve had a larger review including Mark and the larger community
  • Those on the call reached consensus on the following items:
    • We should separate the issues of referencing the license text / metadata from the issue of license list namespaced
    • Solving the license list namespace was important
  • We discussed 3 different solutions to the namespace issue
    • Mark’s proposal of using the DNS names
    • Ad-hoc naming where any organization (e.g. LicenseRef-<namespace>-id) where any organization can use any namespace
    • A registry of namespaces which contains additional metadata
  • We discussed a few potential issues with some of the approaches
    • Uniqueness of the naming – We would like to make sure there are no name collisions
    • Reability of the license ID’s – We would like the ID’s to be easily human readable and writeable
    • Verifiable / secure – If we have an SPDX document references a license in a different namespace, we would like a mechanism to make sure the license hasn’t been changed
    • Versioning – If the license list in a specific namespace changes (e.g. a license is removed or modified), we would like to be able to refer to the version used when creating the SPDX document
  • We tended to favor a registration approach
    • Pro’s – can help solve the readability, uniqueness, versioning and security
    • Con’s – would be slower than just using a well formed license ID since the registry would have to accept any contributions before it could be used
    • Proposal to use Github as the repository for the namespace implementation
    • Proposal to store the license information as an SPDX document containing the license ID’s themselves
      • Alternative discussed was the Github repo would only contain a reference to an external document. This approach had issues with security and versioning.
    • Directory structure could contain version information
    • License ref syntax would allow mapping to a specific document
    • Versioning would be optional
    • Additions and updates to the namespaces would be pull requests
      • We could automate the verification and possibly the acceptance of the PR’s using a build script
    • Kate will propose more specifics