Date   

Re: Specific SPDX identifier question I didn't see addressed in the specification

J Lovejoy
 

Hi McCoy!

I’m moving the SPDX-general list to BCC and replying to SPDX-legal as that is the right place for this discussion.

Where is this question coming up in terms of context? That is, are you thinking in the context of an SPDX document and capturing  the licensing info for a file that is under MIT originally but then redistributed under BSD-2-Clause? Or are you thinking in the context of using an SPDX license identifiers in the source files?

Thanks,
Jilayne

On Jul 1, 2022, at 12:01 PM, McCoy Smith <mccoy@...> wrote:

I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.
 
Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:
  1. Preserve all existing IP notices (or in some cases, just copyright notices)
  2. Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT)  or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))
 
The rules around element 1 and SPDX are well-described.
With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):
 
SPDX-License-Identifier: MIT
[This file/package/project contains code originally licensed under:]
SPDX-License-Identifier: BSD-2-Clause
 
The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.

One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.
 
Thoughts? Am I missing something?


Re: License Type for Commercial Components #spdx

omidramine38@...
 

On ۲۳ ژوئن ۲۰۲۲, at ۱۵:۲۳, "Patil, Sandeep via lists.spdx.org" <philips.com@lists.spdx.org target=_blank>sandeep.patil=philips.com@lists.spdx.org> wrote:
Hi , 

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


Regards
Sandeep


Specific SPDX identifier question I didn't see addressed in the specification

McCoy Smith
 

I didn’t see this particular topic addressed in the specification (although I’m happy to be correcedt if I missed it), so I thought I’d post and see whether there is a solution that’s commonly used, or if there’s room for a new identifier.

 

Virtually all so-called “permissive” licenses permit the recipient of code to license out under different terms, as long as all the requirements of the in-bound license are met. In almost all of these permissive licenses those requirement boil down to:

  1. Preserve all existing IP notices (or in some cases, just copyright notices)
  2. Provide a copy of the license (or something to that effect: retaining “this permission notice” (ICU/Unicode/MIT)  or “this list of conditions” (BSD) or providing “a copy of this License” (Apache 2.0))

 

The rules around element 1 and SPDX are well-described.

With regard to element 2, a fully-compliant but informative notice when there is a change from the in-bound to the out-bound license would look something like this (with the square bracketed part being an example of a way to say this):

 

SPDX-License-Identifier: MIT

[This file/package/project contains code originally licensed under:]

SPDX-License-Identifier: BSD-2-Clause

 

The point being to express that the outbound license is MIT, but in order to fully comply with the requirements of BSD-2-Clause, one must retain “ this list of conditions and the following disclaimer” which including a copy of BSD-2-Clause accomplishes. Without the square bracketed statement above, it seems confusing as to what the license is (or whether, for example, the code is dual-licensed MIT AND BSD-2-Clause.


One way to do this I suppose is to use the LicenseComment: field to include this information, but it seems to me that this is enough of a common situation that there ought to be something more specific to address this situation.

 

Thoughts? Am I missing something?


Re: Where to put issues for "getting started with SPDX" documentation?

VM (Vicky) Brasseur
 

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 officially qualifies as a document but that’s easy enough to link to rather than move (and it would make little sense to move it under a docs repo anyway).

 

--V

 

From: <spdx@...> on behalf of "Manbeck, Jack via lists.spdx.org" <j-manbeck2=ti.com@...>
Reply to: "spdx@..." <spdx@...>
Date: Friday, June 24, 2022 at 07:52
To: "spdx@..." <spdx@...>
Subject: Re: [spdx] Where to put issues for "getting started with SPDX" documentation?

 

CAUTION:This email is received from an external domain. Open the hyperlink(s) & attachment(s) with caution.
.
 

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.,.

 

Jack

 

 

From: spdx@... <spdx@...> On Behalf Of Alexios Zavras
Sent: Friday, June 24, 2022 5:23 AM
To: spdx@...
Subject: [EXTERNAL] Re: [spdx] Where to put issues for "getting started with SPDX" documentation?

 

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@... <spdx@...> On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Thursday, 23 June, 2022 20:46
To: spdx@...
Subject: Re: [spdx] Where to put issues for "getting started with SPDX" documentation?

 

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 repo, so we can do the docs in docusaurus or some other static site generator type thing.

 

Which leaves us back at my initial question: Which repo to put this stuff in? My vote is a new spdx/docs repo.

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

 

From: <spdx@...> on behalf of "Manbeck, Jack via lists.spdx.org" <j-manbeck2=ti.com@...>
Reply to: "spdx@..." <spdx@...>
Date: Wednesday, June 22, 2022 at 06:44
To: "spdx@..." <spdx@...>
Subject: Re: [spdx] Where to put issues for "getting started with SPDX" documentation?

 

CAUTION:This email is received from an external domain. Open the hyperlink(s) & attachment(s) with caution.
.
 

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 seem to be used much anymore. I would create a repo for  “getting started” collateral. Besides the questions we could add examples and other documents over time. The someone can just grab it when they want to  get started,

 

 

We do have a FAQ: https://spdx.dev/faq/ that may have some good info as well if you have not seen it.

 

 

Jack Manbeck

 

 

From: spdx@... <spdx@...> On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Tuesday, June 21, 2022 1:48 PM
To: spdx@...
Subject: [EXTERNAL] [spdx] Where to put issues for "getting started with SPDX" documentation?

 

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 new people to show up and use/generate/understand SPDX, but we can (with time) fix that.

 

We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier to keep track of them.

 

The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?

 

So what do y’all think? Where should these issues go for now?

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro


Re: Where to put issues for "getting started with SPDX" documentation?

Manbeck, Jack
 

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.,.

 

Jack

 

 

From: spdx@... <spdx@...> On Behalf Of Alexios Zavras
Sent: Friday, June 24, 2022 5:23 AM
To: spdx@...
Subject: [EXTERNAL] Re: [spdx] Where to put issues for "getting started with SPDX" documentation?

 

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@... <spdx@...> On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Thursday, 23 June, 2022 20:46
To: spdx@...
Subject: Re: [spdx] Where to put issues for "getting started with SPDX" documentation?

 

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 repo, so we can do the docs in docusaurus or some other static site generator type thing.

 

Which leaves us back at my initial question: Which repo to put this stuff in? My vote is a new spdx/docs repo.

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

 

From: <spdx@...> on behalf of "Manbeck, Jack via lists.spdx.org" <j-manbeck2=ti.com@...>
Reply to: "spdx@..." <spdx@...>
Date: Wednesday, June 22, 2022 at 06:44
To: "spdx@..." <spdx@...>
Subject: Re: [spdx] Where to put issues for "getting started with SPDX" documentation?

 

CAUTION:This email is received from an external domain. Open the hyperlink(s) & attachment(s) with caution.
.
 

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 seem to be used much anymore. I would create a repo for  “getting started” collateral. Besides the questions we could add examples and other documents over time. The someone can just grab it when they want to  get started,

 

 

We do have a FAQ: https://spdx.dev/faq/ that may have some good info as well if you have not seen it.

 

 

Jack Manbeck

 

 

From: spdx@... <spdx@...> On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Tuesday, June 21, 2022 1:48 PM
To: spdx@...
Subject: [EXTERNAL] [spdx] Where to put issues for "getting started with SPDX" documentation?

 

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 new people to show up and use/generate/understand SPDX, but we can (with time) fix that.

 

We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier to keep track of them.

 

The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?

 

So what do y’all think? Where should these issues go for now?

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


Re: Where to put issues for "getting started with SPDX" documentation?

Alexios Zavras
 

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@... <spdx@...> On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Thursday, 23 June, 2022 20:46
To: spdx@...
Subject: Re: [spdx] Where to put issues for "getting started with SPDX" documentation?

 

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 repo, so we can do the docs in docusaurus or some other static site generator type thing.

 

Which leaves us back at my initial question: Which repo to put this stuff in? My vote is a new spdx/docs repo.

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

 

From: <spdx@...> on behalf of "Manbeck, Jack via lists.spdx.org" <j-manbeck2=ti.com@...>
Reply to: "spdx@..." <spdx@...>
Date: Wednesday, June 22, 2022 at 06:44
To: "spdx@..." <spdx@...>
Subject: Re: [spdx] Where to put issues for "getting started with SPDX" documentation?

 

CAUTION:This email is received from an external domain. Open the hyperlink(s) & attachment(s) with caution.
.
 

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 seem to be used much anymore. I would create a repo for  “getting started” collateral. Besides the questions we could add examples and other documents over time. The someone can just grab it when they want to  get started,

 

 

We do have a FAQ: https://spdx.dev/faq/ that may have some good info as well if you have not seen it.

 

 

Jack Manbeck

 

 

From: spdx@... <spdx@...> On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Tuesday, June 21, 2022 1:48 PM
To: spdx@...
Subject: [EXTERNAL] [spdx] Where to put issues for "getting started with SPDX" documentation?

 

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 new people to show up and use/generate/understand SPDX, but we can (with time) fix that.

 

We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier to keep track of them.

 

The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?

 

So what do y’all think? Where should these issues go for now?

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


Re: Where to put issues for "getting started with SPDX" documentation?

VM (Vicky) Brasseur
 

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 repo, so we can do the docs in docusaurus or some other static site generator type thing.

 

Which leaves us back at my initial question: Which repo to put this stuff in? My vote is a new spdx/docs repo.

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

 

From: <spdx@...> on behalf of "Manbeck, Jack via lists.spdx.org" <j-manbeck2=ti.com@...>
Reply to: "spdx@..." <spdx@...>
Date: Wednesday, June 22, 2022 at 06:44
To: "spdx@..." <spdx@...>
Subject: Re: [spdx] Where to put issues for "getting started with SPDX" documentation?

 

CAUTION:This email is received from an external domain. Open the hyperlink(s) & attachment(s) with caution.
.
 

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 seem to be used much anymore. I would create a repo for  “getting started” collateral. Besides the questions we could add examples and other documents over time. The someone can just grab it when they want to  get started,

 

 

We do have a FAQ: https://spdx.dev/faq/ that may have some good info as well if you have not seen it.

 

 

Jack Manbeck

 

 

From: spdx@... <spdx@...> On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Tuesday, June 21, 2022 1:48 PM
To: spdx@...
Subject: [EXTERNAL] [spdx] Where to put issues for "getting started with SPDX" documentation?

 

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 new people to show up and use/generate/understand SPDX, but we can (with time) fix that.

 

We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier to keep track of them.

 

The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?

 

So what do y’all think? Where should these issues go for now?

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro


License Type for Commercial Components #spdx

Patil, Sandeep
 

Hi , 

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


Regards
Sandeep


Re: Where to put issues for "getting started with SPDX" documentation?

Manbeck, Jack
 

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 seem to be used much anymore. I would create a repo for  “getting started” collateral. Besides the questions we could add examples and other documents over time. The someone can just grab it when they want to  get started,

 

 

We do have a FAQ: https://spdx.dev/faq/ that may have some good info as well if you have not seen it.

 

 

Jack Manbeck

 

 

From: spdx@... <spdx@...> On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Tuesday, June 21, 2022 1:48 PM
To: spdx@...
Subject: [EXTERNAL] [spdx] Where to put issues for "getting started with SPDX" documentation?

 

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 new people to show up and use/generate/understand SPDX, but we can (with time) fix that.

 

We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier to keep track of them.

 

The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?

 

So what do y’all think? Where should these issues go for now?

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro


Re: Where to put issues for "getting started with SPDX" documentation?

William Bartholomew (CELA)
 

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 clarify the spec, create samples, and write new docs.

 

I was experimenting with some new getting started documentation, you can see some examples here:

https://iamwillbar.github.io/spdx-spec/v2.2.2/use-cases/sbom/

https://iamwillbar.github.io/spdx-spec/v2.2.2/use-cases/third-party/

https://iamwillbar.github.io/spdx-spec/v2.2.2/use-cases/vulnerability-management/

 

Regards,

 

William Bartholomew (he/him) – Let’s chat

Principal Security Strategist

Global Cybersecurity Policy – Microsoft

 

My working day may not be your working day. Please don’t feel obliged to reply to this e-mail outside of your normal working hours.

 

From: spdx@... <spdx@...> On Behalf Of VM (Vicky) Brasseur via lists.spdx.org
Sent: Tuesday, June 21, 2022 10:48 AM
To: spdx@...
Subject: [EXTERNAL] [spdx] Where to put issues for "getting started with SPDX" documentation?

 

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 new people to show up and use/generate/understand SPDX, but we can (with time) fix that.

 

We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier to keep track of them.

 

The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?

 

So what do y’all think? Where should these issues go for now?

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro


Where to put issues for "getting started with SPDX" documentation?

VM (Vicky) Brasseur
 

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 new people to show up and use/generate/understand SPDX, but we can (with time) fix that.

 

We decided that step one of this would be to start collecting ideas for newbie questions that’ll need answering, etc. We’ll do this in issues to make it easier to keep track of them.

 

The next question is…where should those issues go? The -spec repo isn’t a good fit for them, neither is outreach. Do we perhaps need a new -docs repo…? I don’t know, but it’s worth considering. Or is this premature optimization and we should just pick a repo to log the issues in and then move them later if needed?

 

So what do y’all think? Where should these issues go for now?

 

--V

 

-- 

VM (Vicky) Brasseur

Director, Senior Strategy Advisor

Open Source Program Office

Wipro Limited

Time Zone: Pacific/West Coast US

 

'The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com'

Internal to Wipro


Re: [spdx-defects] [spdx] VEX integration in SPDX #spdx

Dick Brooks
 

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 centric, where a vulnerability is reported and a vendor issues a VEX.

 

It’s important to note that a VEX is very different from a product centric vulnerability disclosure report (VDR) which NIST requires for Executive Order 14028.

 

If you plan to sell products to the US Government then you will need to follow NIST’s requirements for Executive Order 14028:

https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1

 

Maintain vendor vulnerability disclosure reports at the SBOM component level

 

Here is the difference between a VEX and a VDR (attestation).

A VEX is an artifact showing the status of vulnerabilities within a product or products. Components with no vulnerabilities are not listed in a VEX, unless there is a "known not affected" status listed in the VEX.

A VDR is an attestation by a software vendor that they have checked each component of a software product in an SBOM for vulnerabilities and reports on the vulnerability status of each component, for a software product. A VDR is dynamically updated and maintained by the software vendor in order to answer the consumer question "What is the vulnerability status of Product P, NOW?"

 

Thanks,

 

Dick Brooks

 

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

 

Never trust software, always verify and report!

http://www.reliableenergyanalytics.com

Email: dick@...

Tel: +1 978-696-1788

 

From: spdx@... <spdx@...> On Behalf Of Jeff Schutt (jefschut) via lists.spdx.org
Sent: Thursday, June 2, 2022 1:40 PM
To: spdx@...; sandeep.patil@...; spdx-defects@...
Subject: Re: [spdx-defects] [spdx] VEX integration in SPDX #spdx

 

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 CSAF file.

 

We’re currently working on further security vulnerability information integrations with version 3.0 of the SPDX spec and would welcome your contributions :) Meetings are Wednesdays at 11am PT.

 

Jeff

 

 

From: <spdx@...> on behalf of "Rose Judge via lists.spdx.org" <rjudge=vmware.com@...>
Reply-To: "spdx@..." <spdx@...>
Date: Thursday, June 2, 2022 at 10:30 AM
To: "spdx@..." <spdx@...>, "sandeep.patil@..." <sandeep.patil@...>, "spdx-defects@..." <spdx-defects@...>
Subject: Re: [spdx-defects] [spdx] VEX integration in SPDX #spdx

 

Hi Sandeep,

 

The SPDX Defects working group announced security enhancements to the ExternalReference section of the spec as well as an explanatory Annex about how to include security information in an SPDX document. These changes apply to spec version 2.3 which should be released by the end of the month.

 

In order to include security/vulnerability information in 2.3, you will want to use the SECURITY ExternalReference Type. When using this format, there’s several security identifiers available: cpe22type, cpe23type, advisory, fix, url or swid that you can use to reference a VEX document. You can see examples of how this might be done in the link to Annex G above.

 

I’m also adding the SPDX Defects workgroup to the CC in case you have any further questions.

 

Thanks,

Rose

 

 

Subject:

[EXT] [spdx] VEX integration in SPDX #spdx

Date:

Tue, 31 May 2022 22:49:51 -0700

From:

Patil, Sandeep via lists.spdx.org <sandeep.patil=philips.com@...>

Reply-To:

spdx@...

To:

spdx@...



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 

 



Re: [spdx-defects] [spdx] VEX integration in SPDX #spdx

Jeff Schutt (jefschut)
 

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 CSAF file.

 

We’re currently working on further security vulnerability information integrations with version 3.0 of the SPDX spec and would welcome your contributions :) Meetings are Wednesdays at 11am PT.

 

Jeff

 

 

From: <spdx@...> on behalf of "Rose Judge via lists.spdx.org" <rjudge=vmware.com@...>
Reply-To: "spdx@..." <spdx@...>
Date: Thursday, June 2, 2022 at 10:30 AM
To: "spdx@..." <spdx@...>, "sandeep.patil@..." <sandeep.patil@...>, "spdx-defects@..." <spdx-defects@...>
Subject: Re: [spdx-defects] [spdx] VEX integration in SPDX #spdx

 

Hi Sandeep,

 

The SPDX Defects working group announced security enhancements to the ExternalReference section of the spec as well as an explanatory Annex about how to include security information in an SPDX document. These changes apply to spec version 2.3 which should be released by the end of the month.

 

In order to include security/vulnerability information in 2.3, you will want to use the SECURITY ExternalReference Type. When using this format, there’s several security identifiers available: cpe22type, cpe23type, advisory, fix, url or swid that you can use to reference a VEX document. You can see examples of how this might be done in the link to Annex G above.

 

I’m also adding the SPDX Defects workgroup to the CC in case you have any further questions.

 

Thanks,

Rose

 

 

Subject:

[EXT] [spdx] VEX integration in SPDX #spdx

Date:

Tue, 31 May 2022 22:49:51 -0700

From:

Patil, Sandeep via lists.spdx.org <sandeep.patil=philips.com@...>

Reply-To:

spdx@...

To:

spdx@...



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 

 



Re: SPDX Thurs General Meeting Reminder

Ria Schalnat (HPE)
 

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: SPDX-general <spdx@...>
Subject: [spdx] SPDX Thurs General Meeting Reminder

 

We will start this month’s meeting with an informal presentation from Kate about the OpenSSF “White House meeting” and implications for SPDX. https://www.linuxfoundation.org/press-release/linux-foundation-openssf-gather-industry-government-leaders-open-source-software-security-summit/

Anyone else who was involved is more than welcome to pitch in on discussion.

 

GENERAL MEETING

 

Meeting Time: Thurs, June 2, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting

To join by phone instead, tap this: +1.512.647.1431,,1310118349#

Looking for a different dial-in number?
See meeting dial-in numbers: 
https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting


If also dialing-in through a room phone, join without connecting to audio: 
https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true

 

Etherpad for minutes:

https://spdx.swinslow.net/p/spdx-general-minutes

 

Administrative Agenda

Attendance

Minutes Approval  https://github.com/spdx/meetings/blob/main/general/2022-05-05.md

 

Steering Committee Update – Phil

 

Technical Team Report – Kate/Gary/Others

  • Specification and Profiles
    • Overview
    • Core
    • Legal
    • Integrity
    • Defects
    • Usage and Other Emerging
  • Tooling

 

Legal Team Report – Jilayne/Paul/Steve

 

Outreach/Website Team Report – Jack/Sebastian

 

 


Re: SPDX Thurs General Meeting Reminder

J Lovejoy
 

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 current reality for 10+ years!)

On Jun 1, 2022, at 2:58 PM, May Wang <maywang@...> wrote:

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

On Wed, Jun 1, 2022 at 11:36 AM Phil Odence via lists.spdx.org <phil.odence=synopsys.com@...> wrote:

We will start this month’s meeting with an informal presentation from Kate about the OpenSSF “White House meeting” and implications for SPDX. https://www.linuxfoundation.org/press-release/linux-foundation-openssf-gather-industry-government-leaders-open-source-software-security-summit/

Anyone else who was involved is more than welcome to pitch in on discussion.

 

GENERAL MEETING

 

Meeting Time: Thurs, June 2, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting

To join by phone instead, tap this: +1.512.647.1431,,1310118349#

Looking for a different dial-in number?
See meeting dial-in numbers: 
https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting


If also dialing-in through a room phone, join without connecting to audio: 
https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true

 

Etherpad for minutes:

https://spdx.swinslow.net/p/spdx-general-minutes

 

Administrative Agenda

Attendance

Minutes Approval  https://github.com/spdx/meetings/blob/main/general/2022-05-05.md

 

Steering Committee Update – Phil

 

Technical Team Report – Kate/Gary/Others

  • Specification and Profiles
    • Overview
    • Core
    • Legal
    • Integrity
    • Defects
    • Usage and Other Emerging
  • Tooling

 

Legal Team Report – Jilayne/Paul/Steve

 

Outreach/Website Team Report – Jack/Sebastian

 

 





Re: [spdx-defects] [spdx] VEX integration in SPDX #spdx

Dick Brooks
 

Sandeep,

 

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

https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1

 

SPDX V 2.3 supports both VEX and Vulnerability Disclosure Reports (VDR), in support of the NIST recommendations for Executive Order 14028.

 

Here’s an example SPDX V 2.3 reference to a VDR:

 

ExternalRef SECURITY advisory https://github.com/rjb4standards/REA-Products/blob/master/SBOMVDR_JSON/VDR_118.json

 

Here’s an example SPDX V 2.3 reference to a VEX:

 

ExternalRef SECURITY advisory https://cert-portal.siemens.com/productcert/csaf/ssa-661247.json

 

Here’s an explanation of the difference between VEX and VDR:

 

In summary a VEX is an artifact showing the status of vulnerabilities within a product. Components with no vulnerabilities are not listed in a VEX, unless there is a "known not affected" product status contained in the VEX.

 

In summary, a VDR is an attestation by a software vendor that they have checked each component in a software product SBOM for vulnerabilities and reports on the vulnerability status of each component, for a software product.

 

 

Thanks,

 

Dick Brooks

 

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

 

Never trust software, always verify and report!

http://www.reliableenergyanalytics.com

Email: dick@...

Tel: +1 978-696-1788

 

From: spdx-defects@... <spdx-defects@...> On Behalf Of Jeff Schutt (jefschut) via lists.spdx.org
Sent: Thursday, June 2, 2022 1:40 PM
To: spdx@...; sandeep.patil@...; spdx-defects@...
Subject: Re: [spdx-defects] [spdx] VEX integration in SPDX #spdx

 

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 CSAF file.

 

We’re currently working on further security vulnerability information integrations with version 3.0 of the SPDX spec and would welcome your contributions :) Meetings are Wednesdays at 11am PT.

 

Jeff

 

 

From: <spdx@...> on behalf of "Rose Judge via lists.spdx.org" <rjudge=vmware.com@...>
Reply-To: "spdx@..." <spdx@...>
Date: Thursday, June 2, 2022 at 10:30 AM
To: "spdx@..." <spdx@...>, "sandeep.patil@..." <sandeep.patil@...>, "spdx-defects@..." <spdx-defects@...>
Subject: Re: [spdx-defects] [spdx] VEX integration in SPDX #spdx

 

Hi Sandeep,

 

The SPDX Defects working group announced security enhancements to the ExternalReference section of the spec as well as an explanatory Annex about how to include security information in an SPDX document. These changes apply to spec version 2.3 which should be released by the end of the month.

 

In order to include security/vulnerability information in 2.3, you will want to use the SECURITY ExternalReference Type. When using this format, there’s several security identifiers available: cpe22type, cpe23type, advisory, fix, url or swid that you can use to reference a VEX document. You can see examples of how this might be done in the link to Annex G above.

 

I’m also adding the SPDX Defects workgroup to the CC in case you have any further questions.

 

Thanks,

Rose

 

 

Subject:

[EXT] [spdx] VEX integration in SPDX #spdx

Date:

Tue, 31 May 2022 22:49:51 -0700

From:

Patil, Sandeep via lists.spdx.org <sandeep.patil=philips.com@...>

Reply-To:

spdx@...

To:

spdx@...



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 

 



Re: [spdx-defects] [spdx] VEX integration in SPDX #spdx

Rose Judge
 

Hi Sandeep,

 

The SPDX Defects working group announced security enhancements to the ExternalReference section of the spec as well as an explanatory Annex about how to include security information in an SPDX document. These changes apply to spec version 2.3 which should be released by the end of the month.

 

In order to include security/vulnerability information in 2.3, you will want to use the SECURITY ExternalReference Type. When using this format, there’s several security identifiers available: cpe22type, cpe23type, advisory, fix, url or swid that you can use to reference a VEX document. You can see examples of how this might be done in the link to Annex G above.

 

I’m also adding the SPDX Defects workgroup to the CC in case you have any further questions.

 

Thanks,

Rose

 

 

Subject:

[EXT] [spdx] VEX integration in SPDX #spdx

Date:

Tue, 31 May 2022 22:49:51 -0700

From:

Patil, Sandeep via lists.spdx.org <sandeep.patil=philips.com@...>

Reply-To:

spdx@...

To:

spdx@...



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 

 



Re: SPDX Thurs General Meeting Reminder

May Wang
 

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


On Wed, Jun 1, 2022 at 11:36 AM Phil Odence via lists.spdx.org <phil.odence=synopsys.com@...> wrote:

We will start this month’s meeting with an informal presentation from Kate about the OpenSSF “White House meeting” and implications for SPDX. https://www.linuxfoundation.org/press-release/linux-foundation-openssf-gather-industry-government-leaders-open-source-software-security-summit/

Anyone else who was involved is more than welcome to pitch in on discussion.

 

GENERAL MEETING

 

Meeting Time: Thurs, June 2, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting

To join by phone instead, tap this: +1.512.647.1431,,1310118349#

Looking for a different dial-in number?
See meeting dial-in numbers: 
https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting


If also dialing-in through a room phone, join without connecting to audio: 
https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true

 

Etherpad for minutes:

https://spdx.swinslow.net/p/spdx-general-minutes

 

Administrative Agenda

Attendance

Minutes Approval  https://github.com/spdx/meetings/blob/main/general/2022-05-05.md

 

Steering Committee Update – Phil

 

Technical Team Report – Kate/Gary/Others

  • Specification and Profiles
    • Overview
    • Core
    • Legal
    • Integrity
    • Defects
    • Usage and Other Emerging
  • Tooling

 

Legal Team Report – Jilayne/Paul/Steve

 

Outreach/Website Team Report – Jack/Sebastian

 

 


SPDX Thurs General Meeting Reminder

Phil Odence
 

We will start this month’s meeting with an informal presentation from Kate about the OpenSSF “White House meeting” and implications for SPDX. https://www.linuxfoundation.org/press-release/linux-foundation-openssf-gather-industry-government-leaders-open-source-software-security-summit/

Anyone else who was involved is more than welcome to pitch in on discussion.

 

GENERAL MEETING

 

Meeting Time: Thurs, June 2, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html


Conf call dial-in:

Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting

To join by phone instead, tap this: +1.512.647.1431,,1310118349#

Looking for a different dial-in number?
See meeting dial-in numbers: 
https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting


If also dialing-in through a room phone, join without connecting to audio: 
https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true

 

Etherpad for minutes:

https://spdx.swinslow.net/p/spdx-general-minutes

 

Administrative Agenda

Attendance

Minutes Approval  https://github.com/spdx/meetings/blob/main/general/2022-05-05.md

 

Steering Committee Update – Phil

 

Technical Team Report – Kate/Gary/Others

  • Specification and Profiles
    • Overview
    • Core
    • Legal
    • Integrity
    • Defects
    • Usage and Other Emerging
  • Tooling

 

Legal Team Report – Jilayne/Paul/Steve

 

Outreach/Website Team Report – Jack/Sebastian

 

 


VEX integration in SPDX #spdx

Patil, Sandeep
 

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 

41 - 60 of 1587