Technical Team/Minutes/2011-01-25

Minutes 1/25/2011

Attendees:

Bill Schineller
Gary O'Neall
Peter Williams
Kate Stewart

Summary of follow-up items from the call:

• License section - consider renaming non-standard licenses to embedded licenses - has implications on the short form names.  Todo: Kate to follow-up on the proposal. 
• Document and review the algorithm for creating the xor'd sha1's from the file list
• Change the description in the source information field in the package section
• Discuss/decide if the package level asserted license should be optional or mandatory
• Rename "asserted license" to "asserted licensing"
• Future topic- should there be additional optional fields for non-standard licenses?
• Add a comment for the reviewer in the review section
• Reconcile the tag names with the SPDX overview
• consider a more consistent naming convention

Minute details:

Review spdx overview slides sent by Kate - purpose to align on the current status of the spec:
 Section Headers in the spec - Reviewer information has been moved to a separate section at the end
 License section - consider renaming non-standard licenses to embedded licenses - has implications on the short form names.  Todo: Kate to follow-up on the proposal.  Note that embedded is somewhat ambiguous - used for "embedded in the package" as opposed to "embedded in the SPDX file"
 Identification section - Version of SPDX - does it make sense in the RDF spec?  Topic for future discussion.
 Identification section - Method of xor for all file sha's to generate overall checksum - need to publish and review the specific algorithm
 The package file sha is optional in case the spdx file is embedded
 Source information - change description to reflect additional information on the source rather than anomalies (e.g. the download URL is no longer available)
 Package level - agree to add asserted license
  Asserted may include logic (and/or disjunctive/etc)
  Seen licenses would just be a list
  Not clear if asserted license at the package level should be mandatory or optional - future discussion
 Copyright - just a string for release 1 of SPDX
 
 Should there be additional optional tags in the non-standard license?  Topic for a future proposal.
 File - Asserted License -> Asserted Licensing (takes care of possibility of multiple licenses)
 File - Seen license - can be multiple licenses
  Cardinality - does it make sense to have a mandatory field that may contain 0 items  - yes since it confirms that "none were found"
 Reviews - should there be a comment for the reviewer?  Yes - add this as an optional field.

Todo: reconcile the tag names with the spdx overview
Need a better naming convention - add to topic for next week's call - suggestion to invite the individual providing the feedback to the call.