Hi Kate, Thanks a ton for the clarification. It definitely helps, I am sorry for this delayed response. I have one more question/doubt though. In 2.2.1 Corpus Tags, What I infer is that either the

Minutes here and below: http://wiki.spdx.org/view/General_Meeting/Minutes/2015-08-06 Announcements: LinuxCon Europe: If you are attending, there will be a supply chain focused session on Thursday

All I can do is comment on the SPDX spec from the perspective of a small business and FOSS contributor. The spec is already quite heavy weight and adding this tag might make sense for the larger

With no special presentation this month, I suspect the meeting will only require 30 mins. GENERAL MEETING Meeting Time: Thurs, Aug 6, 8am PDT / 10 am CDT / 11am EDT / 15:00 UTC.

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

How do you propose it be trusted? It is just a string! You need substantially more infrastructure than just a SPDX tag to generate trust. Regards, Jeremiah

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:

Adding to Kate’s comments, the SPDX presumption is that developers of open source software would like to: a. have their software used by others b. make sure the software is used under the terms they

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

Its impossible to answer this question, largely because there's not enough data -- what are these "other systems" (Windows?) and what are the "external packages"? This is my assumption as well. I

Beats me. But to me the proposed solution looks much worse than whatever problem it is that you're trying to solve. Speaking of which, where is the document that describes the problem you're trying to

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

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

To add to Philippe's comments, and speaking on behalf of a major producer of open source software, the proposal for an "External Security and Asset Management Identifier" seems to be fundamentally

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

Hi Philippe, HI Yev Philippe, You are right about SWID. Yev, I may be biased over using CPEs and not using SWIDs. Here are my points on SWID. 1. SWID looks nice to have for software asset management

D’oh! Arrgh! Other grunting noises! Here is the correct link. Terribly sorry for the confusion/inconvenience. https://docs.google.com/document/d/1HTgrEKBlza_U3yZBKpgu9JDYhZkZ6Jbj9jNsmRreCMo/edit

<ybronshteyn@...> wrote: Yev: I guess you meant External and not Eternal.... I provided a few comments to your proposed spec in the doc

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

Here is the spec for the proposed EternalPackage element. While I touch on usage in the beginning, I'll discuss some specific use cases in the context of SpdxTools on the