Hi Uday, I don't think so. This is an optional field to permit linkage to security information IF it exists. If it doesn't exist, its more the responsibility of the package creator or distributor to r

There is no SPDX tag - per se. An SPDX document for a package contains hash codes at the file level. (SHA1, SHA256 ), as well as an algorithm for a verification code to be generated from the component

Hi Uday, Proposal was to permit use of either. It was not mandating that one or another needs be used. Agree. Also, see appendix A in NIST-8060 where CPE can be derived from SWID. see: http://csrc.nis

The base document that these changes are being proposed for is SPDX 2.0 see: http://spdx.org/SPDX-specifications/spdx-version-2.0 The goal of software package data exchange (SPDX) is to create a commo

The SPEC being referred to is a NIST one, rather than ANSI. see: http://csrc.nist.gov/publications/PubsDrafts.html#NIST-IR-8060 Which is open. Its in its second reading right now, and its in a public

here's the link: https://docs.google.com/document/d/1j6LWnkh5GbMV9Xo5_zJ0wTNLROEIa4o1OU279YueI90/edit

Hi Philippe, The document you commented on was from last week's discussion. Your input is appreciated and you're opinion is lining up with some of the thoughts expressed as part of the external identi

Hi Yev, The spec you linked to was the one I created for las week's call. Is there a different document we should be refering to? Thanks, Kate

Hi Terin Neither could we. :-) Ah yes, that should be considered. Right now when NONE or NOASSERTION are permitted, they are associated with the actual fields in the specification (ie. LicenseConclude

Hi Terin, Can you give us a real life use case where either "NONE" or "NOASSERTION" should be used in combination with other licenses? If there's a compelling use case as to why it should be allowed,