THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Technical Team/Minutes/2020-02-18

From SPDX Wiki
< Technical Team‎ | Minutes
Revision as of 23:06, 22 February 2020 by Goneall (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

February 18, 2020

Attendees

  • Thomas Steenbergen
  • Rose Judge
  • Steve Winslow
  • Jim Hutchinson
  • Gary O’Neall
  • Kate Stewart
  • Philippe Ombredanne
  • Peter Shin
  • Rohit
  • William Bartholomew

GSoC

  • Need some additional project ideas
  • Kate suggested adding package manager plugins for SPDX
  • Gary suggested some additional Java projects could be added
  • SPDX tools for updated license submission is pending a fix: https://github.com/spdx/spdx-online-tools/issues/140

Joint legal/tech call

  • Feedback from the meeting at FOSDEM was adding the ability to add licenses
    • There was a project last year that still needs to be deployed
    • Discussion having a non-curated or semi-curated license list
    • Steve proposed having a joint call with legal
    • Issue https://github.com/spdx/spdx-spec/issues/113 tracks last year’s proposal
    • Hashing of names proposed
    • Concern with hashing, two licenses match, but end up with 2 different ids, as they hash differently. Namespace approach from Mark Atwood avoids issue, avoids the duplicate license text being represented with multiple license ids
    • William raised the advantage of hashing allows for offline use
    • Philippe mentioned 1000+ additional licenses could be added
    • William suggested an aliasing approach to resolve duplicate licenses
    • Need a PR to specify the proposal
      • Kate agreed to write up the spec

2.2 Release

  • Merged PR’s#202 – updated matching guidelines
  • Merged #203 – new version of mkdocs and upgrade to Python 3
  • JSON-LD PR – fixed plural issue and will merge
    • Gary to fix tools
  • PR #206 – Optional-of – added NPM example and merged
  • Issue #174 – dependency root of
    • Discussed the use cases – example given of a packages.json file which is the “root” of all dependencies for a NPM package.
    • Suggest different name since what is being described is not really a dependency but a metadata file
    • Suggestion dependency_manifest_of
  • New draft view of the 2.2 in development spec is available: