THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Technical Team/Minutes/2018-02-05
From SPDX Wiki
February 5, 2019
Attendees
- 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