I lean strongly toward `docs` as the repo name. It’s a standard and expected name for a repo that contains any sort of documentation, so people will be able to find it in GitHub. Yes, the spec

I agree something like help or getting started as a repo name. That way someone can just grab all of the getting started collaterals that may get generated over time: documents, examples, etc.,.

May I propose something like github.com/spdx/help since “docs” covers a lot more things (even the specification itself). +1 on being a new, separate location. -- zvr From: spdx@...

GitHub is a given, which is why we decided to start opening issues rather than just maintaining a file. I’d prefer to have either a dedicated docs repo or a /docs folder in another appropriate

Hi , What is the license type that needs be used in spdx for 3rd parties with proprietary licenses (e.g., Microsoft)? Regards Sandeep

Yes! I think this is a great idea. We’ve tried in the past to do this but could never get people “focused” on it. I agree its needed. I vote to put it the list in GitHub. The wiki doesn’t

I would put them in the spdx-spec repository, and we can label them as docs. One of the reasons for this is it allows us to address issues holistically, for example, the right thing to do might be to

Howdy, team. In last week’s Outreach call we discussed the lack of “getting started with SPDX” documentation, info that could take someone from Zero to SPDX. Currently it’s really hard for

Sandeep, A good example of a VEX advisory is provided by Siemens in their log4j advisory: https://cert-portal.siemens.com/productcert/csaf/ssa-661247.json NOTE: VEX’s are vulnerability

Hi Sandeep, To add to Rose’s comments… For version 2.3, the new Advisory identifier (F.2.3) is a catch-all that will enable linking to any VEX information, e.g., as contained within OSV or

Hoping this is recorded – I have another unmovable meeting at this time! Ria From: spdx@... <spdx@...>On Behalf Of Phil Odence via lists.spdx.org Sent: Wednesday, June 1, 2022 11:36 AM To:

It was not recorded and I don’t think we’ve ever really done that for general meetings specifically nor for other meetings for the most part (not to say we can’t, but that has been and is the

Sandeep, NIST also recommends that vendors and consumers “Maintain vendor vulnerability disclosure reports at the SBOM component level.” See 5/5

Hi Sandeep, The SPDX Defects working group announced security enhancements to theExternalReference section of the spec as well as an explanatory Annex about how to include security information in

Will the meeting be recorded? I have a conflict, but would love to listen to the updates. Thanks.

We will start this month’s meeting with an informal presentation from Kate about the OpenSSF “White House meeting” and implications for

Hi , Is there any roadmap to integrate VEX to with SPDX ? Or is there already way in current SPDX specification to integrate vulnerability information ? Regards Sandeep

Armijn raises a valid concern. We’ve avoided dynamic information in the past, but even with version 1.0 you could argue the “Concluded License” could change over time if new information is

Sort of. Security information is even more likely to change after release, EOL for open source components supported by the community may, but much less frequently. Thinking so far, is that this

Steve, Regarding: “I have no opinion on end-of-life either way, but wouldn’t the same argument apply to security vulnerabilities?” Yes, if a software vendor chooses to list each known