Re: [spdx-tech] Linking SPDX 3.0 documents

[Norio Kobota]

> -Original Message-
> From: Joshua Watt 
> Sent: Thursday, May 9, 2024 10:22 AM
> 
> On Wed, May 8, 2024, 7:13 PM norio.kob...@sony.com
> <mailto:norio.kob...@sony.com>   <mailto:norio.kob...@sony.com> > wrote:
> 
>   Hi Joshua-san and tech team,
> 
>   Let me ask you a few questions about the Json-LD sample.
> 
>   1. about "type" key
>   For example, "type": "Person" at line.5 could be considered a Person
> class object in a Core profile, but by definition there is no "type" key.
>   How should I think about this, and could you describe it somewhere
> in the specification document?
> 
> "type" is an alias for the json-ld "@type" field. It's not defined in the spec
> because it's specific to json-ld and thus it was decided not to put it in the
> model. There probably needs to be some json-ld serialization annex written
> to describe that
> 
> 
>   2. about "@id": "_:creationinfo"/1
> 
>   The value of "@id" must be IRI. But from the spdx-3.0-schema.json
> at https://github.com/spdx/spdx-3-serialization-prototype-
> playground/blob/main/jsonld/spdx-3.0-schema.json#L4025-L4027
>  serialization-prototype-playground/blob/main/jsonld/spdx-3.0-
> schema.json*L4025-
> L4027__;Iw!!JmoZiZGBv3RvKRSx!9Mr_mPJtMSk4H49WSnitZmq7Y_GxR5ymR
> m0MkAdOjlJv7LQWF3gj7zxVodBV3hxf48MKfpvTNWf4wbla9DAN$> ,
> "_:creationinfo" is thought to be defined as a BlankNode, not IRI.
> 
> Blank nodes (implicit or otherwise are allowed for objects that do not derive
> from Element (e.g. that do not have an spdxid). This was done because those
> do not typically need to be referenced outside a document (if they even
> need to be referenced by name at all) and it would be a pain to users to have
> to write them when they are not necessary.
> 
>   And the key "@id" is also undefined in the SPDX specification.
> 
> This is the same reason as "type"
> 
> 
>   Is there any way to describe it somewhere in the specification?
> 
> 
> It does but I'm not sure how
> 

Thanks, Joshua-san. I understood.

> There probably needs to be some json-ld serialization annex written to 
> describe that

I agree that it will be more easier to understand if the json-ld annex is 
written. 
As I'm writing Lite-example with json-ld, I'm happy if I could contribute in 
the future.

>   Best,
>   -- Kobota
> 
> 
> 
>   From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>
> mailto:Spdx-tech@lists.spdx.org> > On Behalf
> Of Kate Stewart
>   Sent: Thursday, May 9, 2024 8:46 AM
>   To: Joshua Watt  <mailto:jpewhac...@gmail.com> >
>   Cc: SPDX Technical Mailing List  <mailto:Spdx-tech@lists.spdx.org> >
>   Subject: Re: [spdx-tech] Linking SPDX 3.0 documents
> 
> 
> 
>   Thanks Joshua!
> 
> 
> 
>   Very much appreciate your pulling this together.
> 
> 
> 
>   Alexios,  Max - can you please review?
> 
> 
> 
>   Thanks
>   Kate
> 
> 
> 
>   On Wed, May 8, 2024 at 6:40 PM Joshua Watt
> mailto:jpewhac...@gmail.com> > wrote:
> 
>   All,
> 
>   In the tech call it was asked how to link SPDX 3 documents
> together.
>   To describe this, I've written another How-To Annex which
> can be read
>   here: https://github.com/JPEWdev/spdx-
> spec/blob/development/v3.0.1/docs/annexes/cross-reference.md
>  spec/blob/development/v3.0.1/docs/annexes/cross-
> reference.md__;!!JmoZiZGBv3RvKRSx!9Mr_mPJtMSk4H49WSnitZmq7Y_GxR
> 5ymRm0MkAdOjlJv7LQWF3gj7zxVodBV3hxf48MKfpvTNWf4wfL_DeH4$>
> 
>   The pull request to integrate this into the documentation is
> here:
>   https://github.com/spdx/spdx-spec/pull/938
>  spec/pull/938__;!!JmoZiZGBv3RvKRSx!9Mr_mPJtMSk4H49WSnitZmq7Y_GxR
> 5ymRm0MkAdOjlJv7LQWF3gj7zxVodBV3hxf48MKfpvTNWf4wfwltkyM$>
> 
>   This is the correct way to do it to the best of my knowledge;
> please
>   review and let me know if it needs corrections.
> 
>   Thanks,
>   Joshua Watt
> 
>   



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5638): https://lists.spdx.org/g/Spdx-tech/message/5638
Mute This Topic: https://lists.spdx.org/mt/105992376/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Linking SPDX 3.0 documents

[Joshua Watt]

On Wed, May 8, 2024, 7:13 PM norio.kob...@sony.com 
wrote:

> Hi Joshua-san and tech team,
>
>
>
> Let me ask you a few questions about the Json-LD sample.
>
>
>
> 1. about "type" key
>
> For example, "type": "Person" at line.5 could be considered a Person class
> object in a Core profile, but by definition there is no "type" key.
>
> How should I think about this, and could you describe it somewhere in the
> specification document?
>
"type" is an alias for the json-ld "@type" field. It's not defined in the
spec because it's specific to json-ld and thus it was decided not to put it
in the model. There probably needs to be some json-ld serialization annex
written to describe that




2. about "@id": "_:creationinfo"/1
>
> The value of "@id" must be IRI. But from the spdx-3.0-schema.json at
> https://github.com/spdx/spdx-3-serialization-prototype-playground/blob/main/jsonld/spdx-3.0-schema.json#L4025-L4027,
> "_:creationinfo" is thought to be defined as a BlankNode, not IRI.
>
Blank nodes (implicit or otherwise are allowed for objects that do not
derive from Element (e.g. that do not have an spdxid). This was done
because those do not typically need to be referenced outside a document (if
they even need to be referenced by name at all) and it would be a pain to
users to have to write them when they are not necessary.


And the key "@id" is also undefined in the SPDX specification.
>
This is the same reason as "type"



Is there any way to describe it somewhere in the specification?
>

It does but I'm not sure how


>
> Best,
>
> -- Kobota
>
>
>
> *From:* Spdx-tech@lists.spdx.org  *On Behalf Of
> *Kate Stewart
> *Sent:* Thursday, May 9, 2024 8:46 AM
> *To:* Joshua Watt 
> *Cc:* SPDX Technical Mailing List 
> *Subject:* Re: [spdx-tech] Linking SPDX 3.0 documents
>
>
>
> Thanks Joshua!
>
>
>
> Very much appreciate your pulling this together.
>
>
>
> Alexios,  Max - can you please review?
>
>
>
> Thanks
> Kate
>
>
>
> On Wed, May 8, 2024 at 6:40 PM Joshua Watt  wrote:
>
> All,
>
> In the tech call it was asked how to link SPDX 3 documents together.
> To describe this, I've written another How-To Annex which can be read
> here:
> https://github.com/JPEWdev/spdx-spec/blob/development/v3.0.1/docs/annexes/cross-reference.md
>
> The pull request to integrate this into the documentation is here:
> https://github.com/spdx/spdx-spec/pull/938
>
> This is the correct way to do it to the best of my knowledge; please
> review and let me know if it needs corrections.
>
> Thanks,
> Joshua Watt
>
> 
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5637): https://lists.spdx.org/g/Spdx-tech/message/5637
Mute This Topic: https://lists.spdx.org/mt/105992376/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Linking SPDX 3.0 documents

[Norio Kobota]

Hi Joshua-san and tech team,

Let me ask you a few questions about the Json-LD sample.

1. about "type" key
For example, "type": "Person" at line.5 could be considered a Person class 
object in a Core profile, but by definition there is no "type" key.
How should I think about this, and could you describe it somewhere in the 
specification document?
2. about "@id": "_:creationinfo"/1
The value of "@id" must be IRI. But from the spdx-3.0-schema.json at 
https://github.com/spdx/spdx-3-serialization-prototype-playground/blob/main/jsonld/spdx-3.0-schema.json#L4025-L4027,
 "_:creationinfo" is thought to be defined as a BlankNode, not IRI.
And the key "@id" is also undefined in the SPDX specification.
Is there any way to describe it somewhere in the specification?

Best,
-- Kobota

From: Spdx-tech@lists.spdx.org  On Behalf Of Kate 
Stewart
Sent: Thursday, May 9, 2024 8:46 AM
To: Joshua Watt 
Cc: SPDX Technical Mailing List 
Subject: Re: [spdx-tech] Linking SPDX 3.0 documents

Thanks Joshua!

Very much appreciate your pulling this together.

Alexios,  Max - can you please review?

Thanks
Kate

On Wed, May 8, 2024 at 6:40 PM Joshua Watt 
mailto:jpewhac...@gmail.com>> wrote:
All,

In the tech call it was asked how to link SPDX 3 documents together.
To describe this, I've written another How-To Annex which can be read
here: 
https://github.com/JPEWdev/spdx-spec/blob/development/v3.0.1/docs/annexes/cross-reference.md<https://github.com/JPEWdev/spdx-spec/blob/development/v3.0.1/docs/annexes/cross-reference.md>

The pull request to integrate this into the documentation is here:
https://github.com/spdx/spdx-spec/pull/938<https://github.com/spdx/spdx-spec/pull/938>

This is the correct way to do it to the best of my knowledge; please
review and let me know if it needs corrections.

Thanks,
Joshua Watt



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5636): https://lists.spdx.org/g/Spdx-tech/message/5636
Mute This Topic: https://lists.spdx.org/mt/105992376/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Linking SPDX 3.0 documents

[Kate Stewart]

Thanks Joshua!

Very much appreciate your pulling this together.

Alexios,  Max - can you please review?

Thanks
Kate

On Wed, May 8, 2024 at 6:40 PM Joshua Watt  wrote:

> All,
>
> In the tech call it was asked how to link SPDX 3 documents together.
> To describe this, I've written another How-To Annex which can be read
> here:
> https://github.com/JPEWdev/spdx-spec/blob/development/v3.0.1/docs/annexes/cross-reference.md
>
> The pull request to integrate this into the documentation is here:
> https://github.com/spdx/spdx-spec/pull/938
>
> This is the correct way to do it to the best of my knowledge; please
> review and let me know if it needs corrections.
>
> Thanks,
> Joshua Watt
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5635): https://lists.spdx.org/g/Spdx-tech/message/5635
Mute This Topic: https://lists.spdx.org/mt/105992376/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] CISA open registration for the ICT_SCRM conference on June 12

[Isaac Hepworth via lists.spdx.org]

> The collection of CISA Secure Software Attestation forms begin June 8,
2024

Small correction: this is the deadline for agencies to *have collected*
attestations for critical software; not for attestation collection to begin.

Isaac


On Wed, May 8, 2024 at 11:36 AM Dick Brooks via lists.spdx.org  wrote:

> There will be lots of discussion regarding Vulnerability reporting, SBOM’s
> and SBOM sharing with the US Government using the CISA RSAA portal.
>
>
>
> If you are interested in US Government SBOM work and selling products to
> the US Government, then you should seriously consider attending this
> conference:
>
> The collection of CISA Secure Software Attestation forms begin June 8,
> 2024.
>
>
>
>
> https://www.eventbrite.com/e/innovations-in-ict-supply-chain-risk-management-conference-registration-890982100447
>
>
>
> I have successfully shared SPDX and CycloneDX SBOM’s with US Government
> agencies using the CISA RSAA portal and will talk about this capability
> during the conference.
>
>
>
> 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: d...@reliableenergyanalytics.com
>
> Tel: +1 978-696-1788 <(978)%20696-1788>
>
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5633): https://lists.spdx.org/g/Spdx-tech/message/5633
Mute This Topic: https://lists.spdx.org/mt/105986056/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] How to validate documents

[Dick Brooks]

Thanks, Joshua. I’ll take a look and give it a test run.

 

In the meantime, I’m going to continue to instruct my government colleagues to 
request SPDX V 2.3 or CycloneDX 1.5 SBOMs and use the respective online 
validation tools to validate SBOM’s uploaded through the CISA RSAA portal when 
the June 8, 2024 gates open for secure software attestation collection, and 
related artifacts, i.e. SBOMs and POA

 

Thanks for doing this.

 

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: d...@reliableenergyanalytics.com 
 

Tel: +1 978-696-1788

 

 

 

 

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Joshua 
Watt
Sent: Tuesday, May 7, 2024 3:46 PM
To: SPDX Technical Mailing List 
Subject: [spdx-tech] How to validate documents

 

All,

 

There have been a lot of questions about how to validate SPDX 3 documents, so I 
wrote a markdown file that describes how to manually do the validation using 
the JSON Schema and SHACL model. The PR to add it to the SPDX 3 model is here:

https://github.com/spdx/spdx-3-model/pull/765

 

https://github.com/spdx/spdx-3-model/pull/765/commits/81cbf1834fd8ec6c0575d82288f626d8547b21ba
 


Validating SPDX 3 JSON-LD documents



 








 


There are two mechanisms for validating SPDX 3 JSON-LD documents; validating



 


the JSON Schema, and validating against the SHACL model.



 








 


These two different mechanisms serve validate the document in different ways,



 


so it is recommended to do both types of validation to ensure that your



 


documents are correct.



 








 


Validation of documents can be done locally using the methods described below.



 








 


## Validating the JSON Schema



 








 


SPDX 3 JSON-LD documents adhere to a JSON Schema to ensure that they can be



 


parsed as either RDF documents using a full RDF parsing library, or as more



 


simplistic JSON documents using a basic JSON parser. Validating a document



 


against the JSON schema requires installing a tool that can do the validation.



 








 


JSON Schema validation is designed to ensure that a document is structurally



 


conformant to the SPDX 3 spec (that is, all the proper fields are used and have



 


the correct types), but it is unable to ensure that a document is semantically



 


correct (that is that everything is used in the correct way).



 








 


There are a few tools that are known to work, which are described below



 








 


### ajv



 








 


[ajv](https://ajv.js.org/) is a Node.js implementation of a JSON schema



 


validator. It is the recommended validation tool as it has been shown to be



 


fast and helpful in its error messages. To get started, the tool must first be



 


installed from NPM:



 








 


```shell



 


npm install --global ajv-cli



 


```



 








 


Unfortunately, `ajv` does not allow referencing a schema from a URL, so it must



 


first be downloaded locally in order to do validation:



 








 


```shell



 


wget -O spdx-3-schema.json https://spdx.org/schema/3.0.0/spdx-json-schema.json



 


```



 








 


Validation of a document can now be done with the command:



 








 


```shell



 


ajv validate --spec=draft2020 -s spdx-json-schema.json -d 



 


```



 








 


### check-jsonschema



 








 


[check-jsonschema](https://check-jsonschema.readthedocs.io/en/stable/) is a



 


Python based command line tool to validate a JSON schema built on top of the



 


[jsonschema](https://python-jsonschema.readthedocs.io/en/stable/) library. It



 


is not as fast as `ajv` (especially for large documents), but may be useful in



 


places where using NPM is not desired, or if you want to be able to reference



 


the schema directly from a URL.



 








 


To install the tool, use pip:



 








 


```shell



 


python3 -m pip install --user check-jsonschema



 


```



 








 


`check-jsonschema` can reference the schema directly from its URL, so there is



 


no need to download it first. To validate a document, run the command:



 

Re: [spdx-tech] easy and simple way to express licenses in subdirectories

[Oliver Fendt via lists.spdx.org]

Hi Gary,

great, thank you very much. I will provide a reference.

Ciao
Oliver

Von: Gary O'Neall 
Gesendet: Freitag, 3. Mai 2024 01:31
An: Fendt, Oliver (T SSP) ; spdx-tech@lists.spdx.org
Betreff: RE: [spdx-tech] easy and simple way to express licenses in 
subdirectories

Hi Oliver,

Looks like a good candidate for adding this to the examples 
repository<https://github.com/spdx/spdx-examples>.

I opened issue #79<https://github.com/spdx/spdx-examples/issues/79> to track 
the request.

We could add just the SPDX file, but it would be nice if we had some source 
files to use in the example as well - if you happen to have a good open source 
example, could you attach or reference that in the issue?

I'm just about to head out on a 10 day vacation, so it may be a while before I 
can generate the associated SPDX file, but I will take a look at it when I get 
back.

Best,
Gary


From: Spdx-tech@lists.spdx.org<mailto:Spdx-tech@lists.spdx.org> 
mailto:Spdx-tech@lists.spdx.org>> On Behalf Of Oliver 
Fendt via lists.spdx.org
Sent: Thursday, May 2, 2024 11:45 AM
To: Gary O'Neall mailto:g...@sourceauditor.com>>; 
spdx-tech@lists.spdx.org<mailto:spdx-tech@lists.spdx.org>
Subject: Re: [spdx-tech] easy and simple way to express licenses in 
subdirectories

Hi Gary,

thanks a lot.
Can you please give me an example with a valid syntax in tag value, if possible?

Ciao
Oliver

Von: Gary O'Neall mailto:g...@sourceauditor.com>>
Gesendet: Donnerstag, 2. Mai 2024 20:38
An: Fendt, Oliver (T SSP) 
mailto:oliver.fe...@siemens.com>>; 
spdx-tech@lists.spdx.org<mailto:spdx-tech@lists.spdx.org>
Betreff: RE: [spdx-tech] easy and simple way to express licenses in 
subdirectories

Hi Oliver,

In SPDX, you can use the SPDX Package to represent a subdirectory of files 
within a larger package.

In your scenario, one approach would be to create an SPDX package - if it 
doesn't have a logical name, you could call it something like "C licensed 
files" with a declared license of C.  Then use the "contains" relationship from 
the parent package to the subdirectory.

Let me know if you need more context / description.

Best,
Gary

From: Spdx-tech@lists.spdx.org<mailto:Spdx-tech@lists.spdx.org> 
mailto:Spdx-tech@lists.spdx.org>> On Behalf Of Oliver 
Fendt via lists.spdx.org
Sent: Thursday, May 2, 2024 12:48 AM
To: spdx-tech@lists.spdx.org<mailto:spdx-tech@lists.spdx.org>
Subject: [spdx-tech] easy and simple way to express licenses in subdirectories

Dear Folks,

I have a simple question and I am wondering whether you can help me.
Sometimes you find in a package (lets assume the declared license is A) in some 
subdirectory (lets assume SUB-DIR-X) a README file with the following wording: 
"the files in this directory are licensed under license C", but none of the 
files in this directory contain any license information and do not contain any 
reference to the README file in this directory.

Is there an easy and simple way to express this in spdx 2.3 and in spdx 3.0 
(but 2.3 is currently more important)

Thank you very much

Ciao
Oliver




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5626): https://lists.spdx.org/g/Spdx-tech/message/5626
Mute This Topic: https://lists.spdx.org/mt/105858877/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] easy and simple way to express licenses in subdirectories

[Gary O'Neall]

Hi Oliver,

 

Looks like a good candidate for adding this to the examples repository
<https://github.com/spdx/spdx-examples> .

 

I opened issue #79 <https://github.com/spdx/spdx-examples/issues/79>  to
track the request.

 

We could add just the SPDX file, but it would be nice if we had some source
files to use in the example as well - if you happen to have a good open
source example, could you attach or reference that in the issue?

 

I'm just about to head out on a 10 day vacation, so it may be a while before
I can generate the associated SPDX file, but I will take a look at it when I
get back.

 

Best,
Gary

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of
Oliver Fendt via lists.spdx.org
Sent: Thursday, May 2, 2024 11:45 AM
To: Gary O'Neall ; spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] easy and simple way to express licenses in
subdirectories

 

Hi Gary,

 

thanks a lot.

Can you please give me an example with a valid syntax in tag value, if
possible?

 

Ciao

Oliver

 

Von: Gary O'Neall mailto:g...@sourceauditor.com> > 
Gesendet: Donnerstag, 2. Mai 2024 20:38
An: Fendt, Oliver (T SSP) mailto:oliver.fe...@siemens.com> >; spdx-tech@lists.spdx.org
<mailto:spdx-tech@lists.spdx.org> 
Betreff: RE: [spdx-tech] easy and simple way to express licenses in
subdirectories

 

Hi Oliver,

 

In SPDX, you can use the SPDX Package to represent a subdirectory of files
within a larger package.

 

In your scenario, one approach would be to create an SPDX package - if it
doesn't have a logical name, you could call it something like "C licensed
files" with a declared license of C.  Then use the "contains" relationship
from the parent package to the subdirectory.

 

Let me know if you need more context / description.

 

Best,
Gary

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of
Oliver Fendt via lists.spdx.org
Sent: Thursday, May 2, 2024 12:48 AM
To: spdx-tech@lists.spdx.org <mailto:spdx-tech@lists.spdx.org> 
Subject: [spdx-tech] easy and simple way to express licenses in
subdirectories

 

Dear Folks,

 

I have a simple question and I am wondering whether you can help me.

Sometimes you find in a package (lets assume the declared license is A) in
some subdirectory (lets assume SUB-DIR-X) a README file with the following
wording: "the files in this directory are licensed under license C", but
none of the files in this directory contain any license information and do
not contain any reference to the README file in this directory.

 

Is there an easy and simple way to express this in spdx 2.3 and in spdx 3.0
(but 2.3 is currently more important)

 

Thank you very much

 

Ciao

Oliver

 





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5625): https://lists.spdx.org/g/Spdx-tech/message/5625
Mute This Topic: https://lists.spdx.org/mt/105858877/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] easy and simple way to express licenses in subdirectories

[Oliver Fendt via lists.spdx.org]

Hi Gary,

thanks a lot.
Can you please give me an example with a valid syntax in tag value, if possible?

Ciao
Oliver

Von: Gary O'Neall 
Gesendet: Donnerstag, 2. Mai 2024 20:38
An: Fendt, Oliver (T SSP) ; spdx-tech@lists.spdx.org
Betreff: RE: [spdx-tech] easy and simple way to express licenses in 
subdirectories

Hi Oliver,

In SPDX, you can use the SPDX Package to represent a subdirectory of files 
within a larger package.

In your scenario, one approach would be to create an SPDX package - if it 
doesn't have a logical name, you could call it something like "C licensed 
files" with a declared license of C.  Then use the "contains" relationship from 
the parent package to the subdirectory.

Let me know if you need more context / description.

Best,
Gary

From: Spdx-tech@lists.spdx.org<mailto:Spdx-tech@lists.spdx.org> 
mailto:Spdx-tech@lists.spdx.org>> On Behalf Of Oliver 
Fendt via lists.spdx.org
Sent: Thursday, May 2, 2024 12:48 AM
To: spdx-tech@lists.spdx.org<mailto:spdx-tech@lists.spdx.org>
Subject: [spdx-tech] easy and simple way to express licenses in subdirectories

Dear Folks,

I have a simple question and I am wondering whether you can help me.
Sometimes you find in a package (lets assume the declared license is A) in some 
subdirectory (lets assume SUB-DIR-X) a README file with the following wording: 
"the files in this directory are licensed under license C", but none of the 
files in this directory contain any license information and do not contain any 
reference to the README file in this directory.

Is there an easy and simple way to express this in spdx 2.3 and in spdx 3.0 
(but 2.3 is currently more important)

Thank you very much

Ciao
Oliver




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5624): https://lists.spdx.org/g/Spdx-tech/message/5624
Mute This Topic: https://lists.spdx.org/mt/105858877/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] easy and simple way to express licenses in subdirectories

[Gary O'Neall]

Hi Oliver,

 

In SPDX, you can use the SPDX Package to represent a subdirectory of files
within a larger package.

 

In your scenario, one approach would be to create an SPDX package - if it
doesn't have a logical name, you could call it something like "C licensed
files" with a declared license of C.  Then use the "contains" relationship
from the parent package to the subdirectory.

 

Let me know if you need more context / description.

 

Best,
Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of
Oliver Fendt via lists.spdx.org
Sent: Thursday, May 2, 2024 12:48 AM
To: spdx-tech@lists.spdx.org
Subject: [spdx-tech] easy and simple way to express licenses in
subdirectories

 

Dear Folks,

 

I have a simple question and I am wondering whether you can help me.

Sometimes you find in a package (lets assume the declared license is A) in
some subdirectory (lets assume SUB-DIR-X) a README file with the following
wording: "the files in this directory are licensed under license C", but
none of the files in this directory contain any license information and do
not contain any reference to the README file in this directory.

 

Is there an easy and simple way to express this in spdx 2.3 and in spdx 3.0
(but 2.3 is currently more important)

 

Thank you very much

 

Ciao

Oliver

 





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5623): https://lists.spdx.org/g/Spdx-tech/message/5623
Mute This Topic: https://lists.spdx.org/mt/105858877/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Is "VexAssessmentRelationship" typo in how-to-implement-VEX-in-SPDX.md?

[Dick Brooks]

No-san,

 

Thank you for the quick reply.

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of 
no.tan...@sony.com
Sent: Friday, April 26, 2024 7:10 AM
To: Spdx-tech@lists.spdx.org; d...@reliableenergyanalytics.com
Subject: Re: [spdx-tech] Is "VexAssessmentRelationship" typo in 
how-to-implement-VEX-in-SPDX.md?

 

Hi Dick-san,

I don't have such information.

I have just confirmed current specification.

 

Best regards,

Nobuyuki Tanaka

Sony Group Corporation.

 

  _  

差出人: Dick Brooks mailto:d...@reliableenergyanalytics.com> >
送信日時: 2024年4月26日 20:07
宛先: Tanaka, Nobuyuki (SGC) mailto:no.tan...@sony.com> >; 
Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> >
件名: RE: [spdx-tech] Is "VexAssessmentRelationship" typo in 
how-to-implement-VEX-in-SPDX.md? 

 

Nobuyuki Tanaka,

 

Is Sony planning to issue an updated SBOM when a VEX status changes for any of 
the VEX statements contained in an SBOM?

 

How will Sony indicate that a SBOM has no identified vulnerabilities?

 

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of 
no.tan...@sony.com <mailto:no.tan...@sony.com> 
Sent: Thursday, April 25, 2024 9:12 PM
To: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org> 
Subject: Re: [spdx-tech] Is "VexAssessmentRelationship" typo in 
how-to-implement-VEX-in-SPDX.md?

 

Hi all, 

Thanks, I could get a reply directly.

@type should be  "VulnAssessmentRelationship", and "amends" should be 
"amendedBy".

 

Best regards,

Nobuyuki Tanaka

Sony Group Corporation

 

  _  

差出人: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> > が 
no.tan...@sony.com <mailto:no.tan...@sony.com>  mailto:no.tan...@sony.com> > の代理で送信
送信日時: 2024年4月25日 15:36
宛先: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> >
件名: [spdx-tech] Is "VexAssessmentRelationship" typo in 
how-to-implement-VEX-in-SPDX.md?

 

Hi all,

I'd like to confirm one thing in how-to-implement-VEX-in-SPDX.md.

This document is very helpful to understand creating VEX.

https://github.com/spdx/spdx-spec/blob/cb47a183637a952b644a8b4b3677f5794b2cc0bf/docs/annexes/how-to-implement-VEX-in-SPDX.md

 

Is the following @type "VulnAssessmentRelationship" or 
"VexVulnAssessmentRelationship"?

  "@type": "VexAssessmentRelationship",
  "@id": "urn:spdx.dev:vex-update",
  "relationshipType": "amends",
  "from": "urn:spdx.dev:vex-underInvestigation-1",
  "to": ["urn:spdx.dev:vex-affected-1"],

 

Sorry, I need time to create github accout, so I sent this mail to this ML.

 

Best regards,

Nobuyuki Tanaka

Sony Group Corporation

 





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5618): https://lists.spdx.org/g/Spdx-tech/message/5618
Mute This Topic: https://lists.spdx.org/mt/105742798/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Is "VexAssessmentRelationship" typo in how-to-implement-VEX-in-SPDX.md?

[no.tan...@sony.com]

Hi Dick-san,
I don't have such information.
I have just confirmed current specification.

Best regards,
Nobuyuki Tanaka
Sony Group Corporation.


差出人: Dick Brooks 
送信日時: 2024年4月26日 20:07
宛先: Tanaka, Nobuyuki (SGC) ; Spdx-tech@lists.spdx.org 

件名: RE: [spdx-tech] Is "VexAssessmentRelationship" typo in 
how-to-implement-VEX-in-SPDX.md?


Nobuyuki Tanaka,



Is Sony planning to issue an updated SBOM when a VEX status changes for any of 
the VEX statements contained in an SBOM?



How will Sony indicate that a SBOM has no identified vulnerabilities?





Thanks,



Dick Brooks

[cid:image001.png@01DA97A8.3210E980]  [cid:image003.png@01DA97A8.6884E250]

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership



Never trust software, always verify and 
report!<https://reliableenergyanalytics.com/products> ™

http://www.reliableenergyanalytics.com<http://www.reliableenergyanalytics.com/>

Email: d...@reliableenergyanalytics.com<mailto:d...@reliableenergyanalytics.com>

Tel: +1 978-696-1788





From: Spdx-tech@lists.spdx.org  On Behalf Of 
no.tan...@sony.com
Sent: Thursday, April 25, 2024 9:12 PM
To: Spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] Is "VexAssessmentRelationship" typo in 
how-to-implement-VEX-in-SPDX.md?



Hi all,

Thanks, I could get a reply directly.

@type should be  "VulnAssessmentRelationship", and "amends" should be 
"amendedBy".



Best regards,

Nobuyuki Tanaka

Sony Group Corporation





差出人: Spdx-tech@lists.spdx.org<mailto:Spdx-tech@lists.spdx.org> 
mailto:Spdx-tech@lists.spdx.org>> が 
no.tan...@sony.com<mailto:no.tan...@sony.com> 
mailto:no.tan...@sony.com>> の代理で送信
送信日時: 2024年4月25日 15:36
宛先: Spdx-tech@lists.spdx.org<mailto:Spdx-tech@lists.spdx.org> 
mailto:Spdx-tech@lists.spdx.org>>
件名: [spdx-tech] Is "VexAssessmentRelationship" typo in 
how-to-implement-VEX-in-SPDX.md?



Hi all,

I'd like to confirm one thing in how-to-implement-VEX-in-SPDX.md.

This document is very helpful to understand creating VEX.

https://github.com/spdx/spdx-spec/blob/cb47a183637a952b644a8b4b3677f5794b2cc0bf/docs/annexes/how-to-implement-VEX-in-SPDX.md<https://github.com/spdx/spdx-spec/blob/cb47a183637a952b644a8b4b3677f5794b2cc0bf/docs/annexes/how-to-implement-VEX-in-SPDX.md>



Is the following @type "VulnAssessmentRelationship" or 
"VexVulnAssessmentRelationship"?

  "@type": "VexAssessmentRelationship",

  "@id": "urn:spdx.dev:vex-update",

  "relationshipType": "amends",

  "from": "urn:spdx.dev:vex-underInvestigation-1",

  "to": ["urn:spdx.dev:vex-affected-1"],



Sorry, I need time to create github accout, so I sent this mail to this ML.



Best regards,

Nobuyuki Tanaka

Sony Group Corporation






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5617): https://lists.spdx.org/g/Spdx-tech/message/5617
Mute This Topic: https://lists.spdx.org/mt/105742798/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Is "VexAssessmentRelationship" typo in how-to-implement-VEX-in-SPDX.md?

[Dick Brooks]

Nobuyuki Tanaka,

 

Is Sony planning to issue an updated SBOM when a VEX status changes for any
of the VEX statements contained in an SBOM?

 

How will Sony indicate that a SBOM has no identified vulnerabilities?

 

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council - A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always
verify and report! (tm)

 <http://www.reliableenergyanalytics.com/>
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com>
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of
no.tan...@sony.com
Sent: Thursday, April 25, 2024 9:12 PM
To: Spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] Is "VexAssessmentRelationship" typo in
how-to-implement-VEX-in-SPDX.md?

 

Hi all, 

Thanks, I could get a reply directly.

@type should be  "VulnAssessmentRelationship", and "amends" should be
"amendedBy".

 

Best regards,

Nobuyuki Tanaka

Sony Group Corporation

 

  _  

差出人: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>
mailto:Spdx-tech@lists.spdx.org> > が
no.tan...@sony.com <mailto:no.tan...@sony.com>   > の代理で送信
送信日時: 2024年4月25日 15:36
宛先: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>
mailto:Spdx-tech@lists.spdx.org> >
件名: [spdx-tech] Is "VexAssessmentRelationship" typo in
how-to-implement-VEX-in-SPDX.md? 

 

Hi all,

I'd like to confirm one thing in how-to-implement-VEX-in-SPDX.md.

This document is very helpful to understand creating VEX.

https://github.com/spdx/spdx-spec/blob/cb47a183637a952b644a8b4b3677f5794b2cc
0bf/docs/annexes/how-to-implement-VEX-in-SPDX.md

 

Is the following @type "VulnAssessmentRelationship" or
"VexVulnAssessmentRelationship"?

  "@type": "VexAssessmentRelationship",
  "@id": "urn:spdx.dev:vex-update",
  "relationshipType": "amends",
  "from": "urn:spdx.dev:vex-underInvestigation-1",
  "to": ["urn:spdx.dev:vex-affected-1"],

 

Sorry, I need time to create github accout, so I sent this mail to this ML.

 

Best regards,

Nobuyuki Tanaka

Sony Group Corporation

 





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5616): https://lists.spdx.org/g/Spdx-tech/message/5616
Mute This Topic: https://lists.spdx.org/mt/105742798/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Is "VexAssessmentRelationship" typo in how-to-implement-VEX-in-SPDX.md?

[no.tan...@sony.com]

Hi all,
Thanks, I could get a reply directly.
@type should be  "VulnAssessmentRelationship", and "amends" should be 
"amendedBy".

Best regards,
Nobuyuki Tanaka
Sony Group Corporation


差出人: Spdx-tech@lists.spdx.org  が no.tan...@sony.com 
 の代理で送信
送信日時: 2024年4月25日 15:36
宛先: Spdx-tech@lists.spdx.org 
件名: [spdx-tech] Is "VexAssessmentRelationship" typo in 
how-to-implement-VEX-in-SPDX.md?

Hi all,
I'd like to confirm one thing in how-to-implement-VEX-in-SPDX.md.
This document is very helpful to understand creating VEX.
https://github.com/spdx/spdx-spec/blob/cb47a183637a952b644a8b4b3677f5794b2cc0bf/docs/annexes/how-to-implement-VEX-in-SPDX.md

Is the following @type "VulnAssessmentRelationship" or 
"VexVulnAssessmentRelationship"?

  "@type": "VexAssessmentRelationship",
  "@id": "urn:spdx.dev:vex-update",
  "relationshipType": "amends",
  "from": "urn:spdx.dev:vex-underInvestigation-1",
  "to": ["urn:spdx.dev:vex-affected-1"],

Sorry, I need time to create github accout, so I sent this mail to this ML.

Best regards,
Nobuyuki Tanaka

Sony Group Corporation






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5615): https://lists.spdx.org/g/Spdx-tech/message/5615
Mute This Topic: https://lists.spdx.org/mt/105742798/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Update on website redirects

[Gary O'Neall]

The URL’s have been updated – let me know if you see any issues.
Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Joshua 
Watt
Sent: Tuesday, April 9, 2024 10:06 AM
To: Gary O'Neall 
Cc: SPDX Technical Mailing List ; Jeff Licquia 
; Steve Winslow ; Kate Stewart 

Subject: Re: [spdx-tech] Update on website redirects

 

Gary,

 

Due to changes in the output file names from the SPDX spec parser, some of 
these URLs need to be adjusted. Please change these redirects to the new URLs:

 

https://spdx.org/rdf/3.0.0/spdx-model.ttl -> 
https://spdx.github.io/spdx-spec/v3.0/model/spdx-model.ttl

https://spdx.org/rdf/3.0.0/spdx-context.jsonld -> 
https://spdx.github.io/spdx-spec/v3.0/model/spdx-context.jsonld

https://spdx.org/rdf/3.0.0/spdx-json-serialize-annotations.ttl -> 
https://spdx.github.io/spdx-spec/v3.0/model/jsonld-annotations.ttl

 

 

On Wed, Apr 3, 2024 at 12:42 PM Gary O'Neall mailto:g...@sourceauditor.com> > wrote:

Greetings all,

 

All of the redirects for the schemas/context files for the SPDX 3.0 release are 
now in place.

 

Below is the list of URL and the target of the redirects.

 

Let me know if you have any issues accessing the files.

 

Gary

 


URL

Redirect Target


https://spdx.org/schema/3.0.0/spdx-json-schema.json

https://spdx.github.io/spdx-spec/v3.0/model/schema.json


https://spdx.org/rdf/3.0.0/spdx-model.ttl

https://spdx.github.io/spdx-spec/v3.0/model/ontology.rdf.ttl


https://spdx.org/rdf/3.0.0/spdx-context.jsonld

https://spdx.github.io/spdx-spec/v3.0/model/context.jsonld





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5604): https://lists.spdx.org/g/Spdx-tech/message/5604
Mute This Topic: https://lists.spdx.org/mt/105313822/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Update on website redirects

[Joshua Watt]

Gary,

Due to changes in the output file names from the SPDX spec parser, some of
these URLs need to be adjusted. Please change these redirects to the new
URLs:

https://spdx.org/rdf/3.0.0/spdx-model.ttl ->
https://spdx.github.io/spdx-spec/v3.0/model/spdx-model.ttl
https://spdx.org/rdf/3.0.0/spdx-context.jsonld ->
https://spdx.github.io/spdx-spec/v3.0/model/spdx-context.jsonld
https://spdx.org/rdf/3.0.0/spdx-json-serialize-annotations.ttl ->
https://spdx.github.io/spdx-spec/v3.0/model/jsonld-annotations.ttl


On Wed, Apr 3, 2024 at 12:42 PM Gary O'Neall  wrote:

> Greetings all,
>
>
>
> All of the redirects for the schemas/context files for the SPDX 3.0
> release are now in place.
>
>
>
> Below is the list of URL and the target of the redirects.
>
>
>
> Let me know if you have any issues accessing the files.
>
>
>
> Gary
>
>
>
> URL
>
> Redirect Target
>
> https://spdx.org/schema/3.0.0/spdx-json-schema.json
>
> https://spdx.github.io/spdx-spec/v3.0/model/schema.json
>
> https://spdx.org/rdf/3.0.0/spdx-model.ttl
>
> https://spdx.github.io/spdx-spec/v3.0/model/ontology.rdf.ttl
>
> https://spdx.org/rdf/3.0.0/spdx-context.jsonld
>
> https://spdx.github.io/spdx-spec/v3.0/model/context.jsonld
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5603): https://lists.spdx.org/g/Spdx-tech/message/5603
Mute This Topic: https://lists.spdx.org/mt/105313822/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Using sh:in for enums

[Joshua Watt]

Done

https://github.com/spdx/spec-parser/pull/113

On Thu, Apr 4, 2024 at 4:31 AM Alexios Zavras  wrote:
>
> Yes, we should.
> Submit the PR, Joshua.
>
> --
> zvr
> -Original Message-
> From: Gary O'Neall 
> Sent: Wednesday, 3 April, 2024 22:27
> To: 'Joshua Watt' ; 'SPDX Technical Mailing List' 
> 
> Cc: Zavras, Alexios ; 'Sean Barnum' 
> 
> Subject: RE: [spdx-tech] Using sh:in for enums
>
> See https://github.com/spdx/spdx-3-model/issues/460
>
> I personally think we should implement this - especially if Joshua has local 
> changes.
>
> Alexios - agree?
>
> Gary
>
> > -Original Message-
> > From: Spdx-tech@lists.spdx.org  On Behalf Of
> > Joshua Watt
> > Sent: Wednesday, April 3, 2024 9:24 AM
> > To: SPDX Technical Mailing List 
> > Cc: Zavras, Alexios ; Sean Barnum
> > ; Gary O'Neall 
> > Subject: [spdx-tech] Using sh:in for enums
> >
> > After some poking around in the SHACL model, I realized we may want to
> > use the sh:in constraint for properties that reference an enum to
> > restrict the possible values to actual enum values, as this will
> > greatly aid end users in knowing if documents are valid.
> >
> > This would generate SHACL for a property that looks like:
> >
> > [ sh:class <https://rdf.spdx.org/v3/Core/PresenceType> ;
> > sh:in (
> ><https://rdf.spdx.org/v3/Core/PresenceType/yes>
> ><https://rdf.spdx.org/v3/Core/PresenceType/no>
> ><https://rdf.spdx.org/v3/Core/PresenceType/noAssertion> ) ;
> > sh:maxCount 1 ;
> > sh:nodeKind sh:IRI ;
> > sh:path <https://rdf.spdx.org/v3/AI/autonomyType> ],
> >
> > I've already got a local change in spec parser repo I can push up as a
> > PR if we want to do this.
> >
> > Thanks,
> > Joshua Watt
> >
> >
> >
>
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://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
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5599): https://lists.spdx.org/g/Spdx-tech/message/5599
Mute This Topic: https://lists.spdx.org/mt/105312223/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Using sh:in for enums

[Alexios Zavras]

Yes, we should.
Submit the PR, Joshua.

-- 
zvr
-Original Message-
From: Gary O'Neall  
Sent: Wednesday, 3 April, 2024 22:27
To: 'Joshua Watt' ; 'SPDX Technical Mailing List' 

Cc: Zavras, Alexios ; 'Sean Barnum' 

Subject: RE: [spdx-tech] Using sh:in for enums

See https://github.com/spdx/spdx-3-model/issues/460

I personally think we should implement this - especially if Joshua has local 
changes.

Alexios - agree?

Gary

> -Original Message-
> From: Spdx-tech@lists.spdx.org  On Behalf Of 
> Joshua Watt
> Sent: Wednesday, April 3, 2024 9:24 AM
> To: SPDX Technical Mailing List 
> Cc: Zavras, Alexios ; Sean Barnum 
> ; Gary O'Neall 
> Subject: [spdx-tech] Using sh:in for enums
> 
> After some poking around in the SHACL model, I realized we may want to 
> use the sh:in constraint for properties that reference an enum to 
> restrict the possible values to actual enum values, as this will 
> greatly aid end users in knowing if documents are valid.
> 
> This would generate SHACL for a property that looks like:
> 
> [ sh:class <https://rdf.spdx.org/v3/Core/PresenceType> ;
> sh:in (
><https://rdf.spdx.org/v3/Core/PresenceType/yes>
><https://rdf.spdx.org/v3/Core/PresenceType/no>
><https://rdf.spdx.org/v3/Core/PresenceType/noAssertion> ) ;
> sh:maxCount 1 ;
> sh:nodeKind sh:IRI ;
> sh:path <https://rdf.spdx.org/v3/AI/autonomyType> ],
> 
> I've already got a local change in spec parser repo I can push up as a 
> PR if we want to do this.
> 
> Thanks,
> Joshua Watt
> 
> 
> 


Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5598): https://lists.spdx.org/g/Spdx-tech/message/5598
Mute This Topic: https://lists.spdx.org/mt/105312223/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Using sh:in for enums

[Gary O'Neall]

See https://github.com/spdx/spdx-3-model/issues/460

I personally think we should implement this - especially if Joshua has local 
changes.

Alexios - agree?

Gary

> -Original Message-
> From: Spdx-tech@lists.spdx.org  On Behalf Of
> Joshua Watt
> Sent: Wednesday, April 3, 2024 9:24 AM
> To: SPDX Technical Mailing List 
> Cc: Zavras, Alexios ; Sean Barnum
> ; Gary O'Neall 
> Subject: [spdx-tech] Using sh:in for enums
> 
> After some poking around in the SHACL model, I realized we may want to use
> the sh:in constraint for properties that reference an enum to restrict the
> possible values to actual enum values, as this will greatly aid end users in
> knowing if documents are valid.
> 
> This would generate SHACL for a property that looks like:
> 
> [ sh:class  ;
> sh:in (
>
>
> ) ;
> sh:maxCount 1 ;
> sh:nodeKind sh:IRI ;
> sh:path  ],
> 
> I've already got a local change in spec parser repo I can push up as a PR if 
> we
> want to do this.
> 
> Thanks,
> Joshua Watt
> 
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5597): https://lists.spdx.org/g/Spdx-tech/message/5597
Mute This Topic: https://lists.spdx.org/mt/105312223/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Pre meeting topic: SPDX Serialization URLs

[Gary O'Neall]

+1 on spdx.org.

 

I can also help with maintaining files in the spdx.org website if we want to go 
in that direction.  I have setup redirects for the model URI’s referenced in 
the spec (example: spdx.org/rdf/Core/Annotation).  Note that the redirects 
changes the URL in the address bar.  If this approach is OK, I can setup 
similar redirects for these files. 

 

Currently, Steve and I can upload to spdx.org/licenses and spdx.org/rdf 
subdirectories.  If we want to use a different subdirectory or a subdomain 
(e.g. docs.spdx.org), we will likely need help from LF IT.

 

Any thoughts on specific subdomain or subdirectory names?  For the context 
file, putting it under the rdf subdirectory makes sense to me, but I’m not sure 
if this makes sense for the JSON schema since it is not RDF specific.

 

One other detail – in RDF we have the current released terms at 
spdx.org/rdf/terms and we have specific versions under 
spdx.org/rdf/ontology/spdx-X-Y.  Do we want to take a similar approach to host 
multiple versions of the schema and context files?

 

Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Steve 
Winslow
Sent: Monday, April 1, 2024 11:06 AM
To: Kate Stewart 
Cc: Gary O'Neall ; Joshua Watt ; 
SPDX Technical Mailing List 
Subject: Re: [spdx-tech] Pre meeting topic: SPDX Serialization URLs

 

I’d agree with Kate — putting these on the spdx.org <http://spdx.org>  domain 
probably makes sense. In addition to the License List, the RDF model files for 
2.3 are also on spdx.org <http://spdx.org>  (see 
https://spdx.org/rdf/ontology/spdx-2-3/)

 

The split of the website to spdx.dev, and all other SPDX assets remaining on 
spdx.org <http://spdx.org> , is kind of a historical artifact that I’m happy to 
describe in more detail if needed (hopefully it isn't needed).  :)

 

If you do want to push them to spdx.org <http://spdx.org> , I can likely assist 
with that. Though may also need some help from Linux Foundation IT support as 
they currently manage the hosting for that domain.

 

If it’s redirects you’re looking for, I know we have some set up as well so 
that we were able to preserve old links when the website moved to Wordpress / 
spdx.dev. For example, the old URL https://spdx.org/ids redirects to 
https://spdx.dev/learn/handling-license-info/. I’m assuming we could do the 
same to redirect to a GitHub Pages site if needed in the short term.

 

Steve





On Apr 1, 2024, at 1:15 PM, Kate Stewart mailto:kstew...@linuxfoundation.org> > wrote:

 

How about hosting them on the spdx.org <http://spdx.org/>  domain,  like we do 
the license list?  (https://spdx.org/licenses/)

 

On Mon, Apr 1, 2024 at 11:35 AM Gary O'Neall mailto:g...@sourceauditor.com> > wrote:

Note: the spdx.dev <http://spdx.dev/>  website uses WordPress.  I'm not 
proficient in WordPress myself and I'm not sure how to implement a redirect (I 
suspect there is a plugin for this), but I do have access to make the changes 
if we want to have the official URL have the spdx.dev <http://spdx.dev/> domain.

Gary

> -Original Message-
> From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
> mailto:Spdx-tech@lists.spdx.org> > On Behalf Of
> Joshua Watt
> Sent: Friday, March 29, 2024 7:34 AM
> To: SPDX Technical Mailing List  <mailto:Spdx-tech@lists.spdx.org> >
> Subject: [spdx-tech] Pre meeting topic: SPDX Serialization URLs
> 
> All,
> 
> Since we are rapidly approaching the announcement date for SPDX 3, we need
> to make sure that we are able to have users write valid serialized SPDX 3
> documents on the day of announcement. In order for JSON-LD serialization to
> work properly, we need to provide URLs for the JSON-LD context file, the JSON
> schema to validate documents, and the RDF model. These are currently
> hosted at https://spdx.github.io/spdx-spec/v3.0/model/ . This URL will be
> encoded into serialized documents, so before we tell the masses that they
> should write SPDX 3 documents, these URLs need to be finalized and host
> actual content. I suspect that we will not want these URLs to live on GitHub,
> and some URL on spdx.dev <http://spdx.dev/>  would be a better choice, but I 
> do not know what
> that URL would be or how to make it "live". I think that making the actual
> URLs redirect to the GitHub ones will be sufficient until we are done 
> finalizing
> SPDX 3.0, as that might be easier than trying to have the current GitHub
> Actions pipeline publish somewhere else, but I have no idea how to set this
> up. This issue is captured in https://github.com/spdx/spdx-3-
> model/issues/679, please comment there if possible.
> 
> If we can sort this out before Tuesday's tech meeting, that would be great, 
> but
> if not we will discuss it there and try to reach a resolution. The two items 
> we
> need to sol

Re: [spdx-tech] Pre meeting topic: SPDX Serialization URLs

[Steve Winslow]

I’d agree with Kate — putting these on the spdx.org  domain 
probably makes sense. In addition to the License List, the RDF model files for 
2.3 are also on spdx.org  (see 
https://spdx.org/rdf/ontology/spdx-2-3/)

The split of the website to spdx.dev, and all other SPDX assets remaining on 
spdx.org , is kind of a historical artifact that I’m happy to 
describe in more detail if needed (hopefully it isn't needed).  :)

If you do want to push them to spdx.org , I can likely assist 
with that. Though may also need some help from Linux Foundation IT support as 
they currently manage the hosting for that domain.

If it’s redirects you’re looking for, I know we have some set up as well so 
that we were able to preserve old links when the website moved to Wordpress / 
spdx.dev. For example, the old URL https://spdx.org/ids redirects to 
https://spdx.dev/learn/handling-license-info/. I’m assuming we could do the 
same to redirect to a GitHub Pages site if needed in the short term.

Steve

> On Apr 1, 2024, at 1:15 PM, Kate Stewart  wrote:
> 
> How about hosting them on the spdx.org  domain,  like we do 
> the license list?  (https://spdx.org/licenses/)
> 
> On Mon, Apr 1, 2024 at 11:35 AM Gary O'Neall  > wrote:
>> Note: the spdx.dev  website uses WordPress.  I'm not 
>> proficient in WordPress myself and I'm not sure how to implement a redirect 
>> (I suspect there is a plugin for this), but I do have access to make the 
>> changes if we want to have the official URL have the spdx.dev 
>> domain.
>> 
>> Gary
>> 
>> > -Original Message-
>> > From: Spdx-tech@lists.spdx.org  
>> > mailto:Spdx-tech@lists.spdx.org>> On Behalf Of
>> > Joshua Watt
>> > Sent: Friday, March 29, 2024 7:34 AM
>> > To: SPDX Technical Mailing List > > >
>> > Subject: [spdx-tech] Pre meeting topic: SPDX Serialization URLs
>> > 
>> > All,
>> > 
>> > Since we are rapidly approaching the announcement date for SPDX 3, we need
>> > to make sure that we are able to have users write valid serialized SPDX 3
>> > documents on the day of announcement. In order for JSON-LD serialization to
>> > work properly, we need to provide URLs for the JSON-LD context file, the 
>> > JSON
>> > schema to validate documents, and the RDF model. These are currently
>> > hosted at https://spdx.github.io/spdx-spec/v3.0/model/ . This URL will be
>> > encoded into serialized documents, so before we tell the masses that they
>> > should write SPDX 3 documents, these URLs need to be finalized and host
>> > actual content. I suspect that we will not want these URLs to live on 
>> > GitHub,
>> > and some URL on spdx.dev  would be a better choice, but 
>> > I do not know what
>> > that URL would be or how to make it "live". I think that making the actual
>> > URLs redirect to the GitHub ones will be sufficient until we are done 
>> > finalizing
>> > SPDX 3.0, as that might be easier than trying to have the current GitHub
>> > Actions pipeline publish somewhere else, but I have no idea how to set this
>> > up. This issue is captured in https://github.com/spdx/spdx-3-
>> > model/issues/679, please comment there if possible.
>> > 
>> > If we can sort this out before Tuesday's tech meeting, that would be 
>> > great, but
>> > if not we will discuss it there and try to reach a resolution. The two 
>> > items we
>> > need to solve are:
>> > 1. What are the file URLs for these items 2. Who is going to do the work to
>> > setup the redirects
>> > 
>> > Thanks,
>> > Joshua Watt
>> > 
>> > 
>> > 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5590): https://lists.spdx.org/g/Spdx-tech/message/5590
Mute This Topic: https://lists.spdx.org/mt/105216516/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Pre meeting topic: SPDX Serialization URLs

[Kate Stewart]

How about hosting them on the spdx.org domain,  like we do the license
list?  (https://spdx.org/licenses/)

On Mon, Apr 1, 2024 at 11:35 AM Gary O'Neall  wrote:

> Note: the spdx.dev website uses WordPress.  I'm not proficient in
> WordPress myself and I'm not sure how to implement a redirect (I suspect
> there is a plugin for this), but I do have access to make the changes if we
> want to have the official URL have the spdx.dev domain.
>
> Gary
>
> > -Original Message-
> > From: Spdx-tech@lists.spdx.org  On Behalf Of
> > Joshua Watt
> > Sent: Friday, March 29, 2024 7:34 AM
> > To: SPDX Technical Mailing List 
> > Subject: [spdx-tech] Pre meeting topic: SPDX Serialization URLs
> >
> > All,
> >
> > Since we are rapidly approaching the announcement date for SPDX 3, we
> need
> > to make sure that we are able to have users write valid serialized SPDX 3
> > documents on the day of announcement. In order for JSON-LD serialization
> to
> > work properly, we need to provide URLs for the JSON-LD context file, the
> JSON
> > schema to validate documents, and the RDF model. These are currently
> > hosted at https://spdx.github.io/spdx-spec/v3.0/model/ . This URL will
> be
> > encoded into serialized documents, so before we tell the masses that they
> > should write SPDX 3 documents, these URLs need to be finalized and host
> > actual content. I suspect that we will not want these URLs to live on
> GitHub,
> > and some URL on spdx.dev would be a better choice, but I do not know
> what
> > that URL would be or how to make it "live". I think that making the
> actual
> > URLs redirect to the GitHub ones will be sufficient until we are done
> finalizing
> > SPDX 3.0, as that might be easier than trying to have the current GitHub
> > Actions pipeline publish somewhere else, but I have no idea how to set
> this
> > up. This issue is captured in https://github.com/spdx/spdx-3-
> > model/issues/679, please comment there if possible.
> >
> > If we can sort this out before Tuesday's tech meeting, that would be
> great, but
> > if not we will discuss it there and try to reach a resolution. The two
> items we
> > need to solve are:
> > 1. What are the file URLs for these items 2. Who is going to do the work
> to
> > setup the redirects
> >
> > Thanks,
> > Joshua Watt
> >
> >
> >
>
>
>
>
> 
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5589): https://lists.spdx.org/g/Spdx-tech/message/5589
Mute This Topic: https://lists.spdx.org/mt/105216516/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Pre meeting topic: SPDX Serialization URLs

[Gary O'Neall]

Note: the spdx.dev website uses WordPress.  I'm not proficient in WordPress 
myself and I'm not sure how to implement a redirect (I suspect there is a 
plugin for this), but I do have access to make the changes if we want to have 
the official URL have the spdx.dev domain.

Gary

> -Original Message-
> From: Spdx-tech@lists.spdx.org  On Behalf Of
> Joshua Watt
> Sent: Friday, March 29, 2024 7:34 AM
> To: SPDX Technical Mailing List 
> Subject: [spdx-tech] Pre meeting topic: SPDX Serialization URLs
> 
> All,
> 
> Since we are rapidly approaching the announcement date for SPDX 3, we need
> to make sure that we are able to have users write valid serialized SPDX 3
> documents on the day of announcement. In order for JSON-LD serialization to
> work properly, we need to provide URLs for the JSON-LD context file, the JSON
> schema to validate documents, and the RDF model. These are currently
> hosted at https://spdx.github.io/spdx-spec/v3.0/model/ . This URL will be
> encoded into serialized documents, so before we tell the masses that they
> should write SPDX 3 documents, these URLs need to be finalized and host
> actual content. I suspect that we will not want these URLs to live on GitHub,
> and some URL on spdx.dev would be a better choice, but I do not know what
> that URL would be or how to make it "live". I think that making the actual
> URLs redirect to the GitHub ones will be sufficient until we are done 
> finalizing
> SPDX 3.0, as that might be easier than trying to have the current GitHub
> Actions pipeline publish somewhere else, but I have no idea how to set this
> up. This issue is captured in https://github.com/spdx/spdx-3-
> model/issues/679, please comment there if possible.
> 
> If we can sort this out before Tuesday's tech meeting, that would be great, 
> but
> if not we will discuss it there and try to reach a resolution. The two items 
> we
> need to solve are:
> 1. What are the file URLs for these items 2. Who is going to do the work to
> setup the redirects
> 
> Thanks,
> Joshua Watt
> 
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5588): https://lists.spdx.org/g/Spdx-tech/message/5588
Mute This Topic: https://lists.spdx.org/mt/105216516/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Questions about package checksum?

[Gary O'Neall]

Greetings,

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Yasutake 
Kurita
Sent: Thursday, March 28, 2024 7:52 PM
To: Spdx-tech@lists.spdx.org
Subject: [spdx-tech] Questions about package checksum?

 

Questions about the following items.

https://spdx.github.io/spdx-spec/v2.3/package-information/#710-package-checksum-field

 

Am I correct in understanding that if a package consists of a single file, such 
as a ZIP file, the checksum of that file is described?

[G.O.] Yes

If a package consists of multiple files that are not compressed, what should be 
written in the checksum?

[G.O.] In this case, the Package Verification Code should be used in place of 
the checksum.  See 
https://github.com/spdx/spdx-spec/blob/development/v2.3.1/chapters/how-to-use.md#k3-verifying-spdx-packages
 for a more complete description.

 

Regards,

Yasutake Kurita.

 





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5587): https://lists.spdx.org/g/Spdx-tech/message/5587
Mute This Topic: https://lists.spdx.org/mt/105210336/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] CISA document on identifiers

[Dick Brooks]

Venkat,

 

We are in agreement “I said - it is important for end-to-end security.”

 

IMO, the most important decision that must be made is to agree on a method to 
ensure uniqueness of Supplier Names.

 

Fortunately we have a built in mechanism in place that already does this with 
two IANA registered tags:

*   dns – identifies unique dns domain names that are owned by a legal 
entity (company or person)
*   mailto: email addresses are guaranteed to be unique; some open source 
developers are only identifiable by their email address, I have found.

 

Purl/swid is another good option, but will require mandating the currently 
optional owner tags that precede the product and version information in a 
purl/swid identifier. 



 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Venkatasubramaniam Ramakrishnan  
Sent: Friday, March 29, 2024 11:55 PM
To: d...@reliableenergyanalytics.com
Cc: Gary O'Neall ; spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] CISA document on identifiers

 

Hi Dick,

Your inputs are valid but come with a lot of IFs. It is tough

to follow-through and enforce if the suppliers are doing the right thing.
Even with a standard, it would be difficult, but CISA's document talks

about reward and penalty for not implementing the naming standard,

which is some hope.


If we work in SBOM silos, naming may not be a big deal, but considering

the end-to-end life cycle from design to vulnerability management and

licensing, naming is important to see if we are referring to the same

component.

 

Yesterday, Jonathan from CISA presented the naming standard proposal

at the EPSS meeting and shared how important naming is. I specifically

asked if naming is important for SBOMs, and he replied the same thing

I said - it is important for end-to-end security.

I would appreciate further inputs.

Thanks & Best Regards,
Venkat.

 

 

 

On Fri, Mar 29, 2024 at 5:18 PM Dick Brooks mailto:d...@reliableenergyanalytics.com> > wrote:

Naming is not an issue within SBOM’s so long as the Supplier Name is unique.

 

An SBOM includes a unique product identifier by combining Supplier Name + 
Package Name + Package Version

 

Each supplier maintains their own unique product name and version namespace.

 

This works perfectly if the Supplier Name is guaranteed to be unique and each 
supplier manages the uniqueness of their product namespaces. 

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of 
Venkat Ramakrishnan
Sent: Friday, March 29, 2024 6:33 AM
To: Gary O'Neall mailto:g...@sourceauditor.com> >
Cc: spdx-tech@lists.spdx.org <mailto:spdx-tech@lists.spdx.org> 
Subject: Re: [spdx-tech] CISA document on identifiers

 

Hi Gary,

I'm currently going through the CISA document and noting down my observations.
Although the commenting period is over, I was asked to give my feedback on the
document by one of the CISA's members. If you or anyone else are interested in
looking into this further and potentially give our feedback from SPDX 
perspective,
I am willing to work with them.

Naming is so important, and as I understand, it is a major blocking factor for
SBOMs/VEXs from being adopted (at least quickly. Otherwise, it may take several
years is what I heard). So, it would be worthwhile to spend some time on this.

Thanks & Best Regards,
Venkat.

 


 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
 

Virus-free. 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
 www.avg.com

 

On Fri, Jan 19, 2024 at 1:03 AM Gary O'Neall mailto:g...@sourceauditor.com> > wrote:

One of the proposed solutions for package verification is to use OMNIBor 
identifiers for verification purposes (see PR #602 
<https://github.com/spdx/spdx-3-model/pull/602>  for documentation on this 
approach).

 

Since it relates to identifiers, I thought it might be useful to review the 
recently release paper on identifiers fro

Re: [spdx-tech] CISA document on identifiers

[Venkat Ramakrishnan]

Hi Dick,

Your inputs are valid but come with a lot of IFs. It is tough
to follow-through and enforce if the suppliers are doing the right thing.
Even with a standard, it would be difficult, but CISA's document talks
about reward and penalty for not implementing the naming standard,
which is some hope.

If we work in SBOM silos, naming may not be a big deal, but considering
the end-to-end life cycle from design to vulnerability management and
licensing, naming is important to see if we are referring to the same
component.

Yesterday, Jonathan from CISA presented the naming standard proposal
at the EPSS meeting and shared how important naming is. I specifically
asked if naming is important for SBOMs, and he replied the same thing
I said - it is important for end-to-end security.

I would appreciate further inputs.

Thanks & Best Regards,
Venkat.



On Fri, Mar 29, 2024 at 5:18 PM Dick Brooks <
d...@reliableenergyanalytics.com> wrote:

> Naming is not an issue within SBOM’s so long as the Supplier Name is
> unique.
>
>
>
> An SBOM includes a unique product identifier by combining Supplier Name +
> Package Name + Package Version
>
>
>
> Each supplier maintains their own unique product name and version
> namespace.
>
>
>
> This works perfectly if the Supplier Name is guaranteed to be unique and
> each supplier manages the uniqueness of their product namespaces.
>
>
>
> 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!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: d...@reliableenergyanalytics.com
>
> Tel: +1 978-696-1788
>
>
>
>
>
> *From:* Spdx-tech@lists.spdx.org  *On Behalf Of
> *Venkat Ramakrishnan
> *Sent:* Friday, March 29, 2024 6:33 AM
> *To:* Gary O'Neall 
> *Cc:* spdx-tech@lists.spdx.org
> *Subject:* Re: [spdx-tech] CISA document on identifiers
>
>
>
> Hi Gary,
>
> I'm currently going through the CISA document and noting down my
> observations.
> Although the commenting period is over, I was asked to give my feedback on
> the
> document by one of the CISA's members. If you or anyone else are
> interested in
> looking into this further and potentially give our feedback from SPDX
> perspective,
> I am willing to work with them.
>
> Naming is so important, and as I understand, it is a major blocking factor
> for
> SBOMs/VEXs from being adopted (at least quickly. Otherwise, it may take
> several
> years is what I heard). So, it would be worthwhile to spend some time on
> this.
>
> Thanks & Best Regards,
> Venkat.
>
>
>
> [image: Image removed by sender.]
> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>
> Virus-free.www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>
>
>
> On Fri, Jan 19, 2024 at 1:03 AM Gary O'Neall 
> wrote:
>
> One of the proposed solutions for package verification is to use OMNIBor
> identifiers for verification purposes (see PR #602
> <https://github.com/spdx/spdx-3-model/pull/602> for documentation on this
> approach).
>
>
>
> Since it relates to identifiers, I thought it might be useful to review
> the recently release paper on identifiers from CISA
> <https://www.cisa.gov/sites/default/files/2023-10/Software-Identification-Ecosystem-Option-Analysis-508c.pdf>
> – there is a request for comment.
>
>
>
> Note that the goal of the paper seems focused on the correlation of
> package artifacts with vulnerability management systems.  There are other
> use cases which don’t seem to be considered (or at least mentioned) in the
> paper.
>
>
>
> A few things I noticed while scanning the paper related to the
> verification code discussion:
>
>- It sadly doesn’t reference Software Heritage ID’s, which I
>personally think is a well thought through identifier scheme.  I wonder how
>SWHID’s compare with OmniBOR in terms of some of the issues raised in the
>paper.
>- No mention of using the identifiers for verification purpose,
>although there is a mention of “Inherent Identifiers” whose properties
>include the ability to verify
>- One of the criteria is “grouping” – which is stated to be unsolved
>at this point
>- Section 2.5 “Path 5: Unidentified Software Descriptor to Augment
>Paths 2, 3, and 4” describes a path which seems quite implementable using
>our current SPDX 3.0 model
>
>
>
> Gary
>
> 
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5583): https://lists.spdx.org/g/Spdx-tech/message/5583
Mute This Topic: https://lists.spdx.org/mt/103815753/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] CISA document on identifiers

[Dick Brooks]

Naming is not an issue within SBOM’s so long as the Supplier Name is unique.

 

An SBOM includes a unique product identifier by combining Supplier Name + 
Package Name + Package Version

 

Each supplier maintains their own unique product name and version namespace.

 

This works perfectly if the Supplier Name is guaranteed to be unique and each 
supplier manages the uniqueness of their product namespaces. 

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Venkat 
Ramakrishnan
Sent: Friday, March 29, 2024 6:33 AM
To: Gary O'Neall 
Cc: spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] CISA document on identifiers

 

Hi Gary,

I'm currently going through the CISA document and noting down my observations.
Although the commenting period is over, I was asked to give my feedback on the
document by one of the CISA's members. If you or anyone else are interested in
looking into this further and potentially give our feedback from SPDX 
perspective,
I am willing to work with them.

Naming is so important, and as I understand, it is a major blocking factor for
SBOMs/VEXs from being adopted (at least quickly. Otherwise, it may take several
years is what I heard). So, it would be worthwhile to spend some time on this.

Thanks & Best Regards,
Venkat.

 


 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
 

Virus-free. 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
 www.avg.com

 

On Fri, Jan 19, 2024 at 1:03 AM Gary O'Neall mailto:g...@sourceauditor.com> > wrote:

One of the proposed solutions for package verification is to use OMNIBor 
identifiers for verification purposes (see PR #602 
<https://github.com/spdx/spdx-3-model/pull/602>  for documentation on this 
approach).

 

Since it relates to identifiers, I thought it might be useful to review the 
recently release paper on identifiers from CISA 
<https://www.cisa.gov/sites/default/files/2023-10/Software-Identification-Ecosystem-Option-Analysis-508c.pdf>
  – there is a request for comment.

 

Note that the goal of the paper seems focused on the correlation of package 
artifacts with vulnerability management systems.  There are other use cases 
which don’t seem to be considered (or at least mentioned) in the paper.

 

A few things I noticed while scanning the paper related to the verification 
code discussion:

*   It sadly doesn’t reference Software Heritage ID’s, which I personally 
think is a well thought through identifier scheme.  I wonder how SWHID’s 
compare with OmniBOR in terms of some of the issues raised in the paper.
*   No mention of using the identifiers for verification purpose, although 
there is a mention of “Inherent Identifiers” whose properties include the 
ability to verify
*   One of the criteria is “grouping” – which is stated to be unsolved at 
this point
*   Section 2.5 “Path 5: Unidentified Software Descriptor to Augment Paths 
2, 3, and 4” describes a path which seems quite implementable using our current 
SPDX 3.0 model

 

Gary





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5581): https://lists.spdx.org/g/Spdx-tech/message/5581
Mute This Topic: https://lists.spdx.org/mt/103815753/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] CISA document on identifiers

[Venkat Ramakrishnan]

Hi Gary,

I'm currently going through the CISA document and noting down my
observations.
Although the commenting period is over, I was asked to give my feedback on
the
document by one of the CISA's members. If you or anyone else are interested
in
looking into this further and potentially give our feedback from SPDX
perspective,
I am willing to work with them.

Naming is so important, and as I understand, it is a major blocking factor
for
SBOMs/VEXs from being adopted (at least quickly. Otherwise, it may take
several
years is what I heard). So, it would be worthwhile to spend some time on
this.

Thanks & Best Regards,
Venkat.



Virus-free.www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Jan 19, 2024 at 1:03 AM Gary O'Neall  wrote:

> One of the proposed solutions for package verification is to use OMNIBor
> identifiers for verification purposes (see PR #602
>  for documentation on this
> approach).
>
>
>
> Since it relates to identifiers, I thought it might be useful to review
> the recently release paper on identifiers from CISA
> 
> – there is a request for comment.
>
>
>
> Note that the goal of the paper seems focused on the correlation of
> package artifacts with vulnerability management systems.  There are other
> use cases which don’t seem to be considered (or at least mentioned) in the
> paper.
>
>
>
> A few things I noticed while scanning the paper related to the
> verification code discussion:
>
>- It sadly doesn’t reference Software Heritage ID’s, which I
>personally think is a well thought through identifier scheme.  I wonder how
>SWHID’s compare with OmniBOR in terms of some of the issues raised in the
>paper.
>- No mention of using the identifiers for verification purpose,
>although there is a mention of “Inherent Identifiers” whose properties
>include the ability to verify
>- One of the criteria is “grouping” – which is stated to be unsolved
>at this point
>- Section 2.5 “Path 5: Unidentified Software Descriptor to Augment
>Paths 2, 3, and 4” describes a path which seems quite implementable using
>our current SPDX 3.0 model
>
>
>
> Gary
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5580): https://lists.spdx.org/g/Spdx-tech/message/5580
Mute This Topic: https://lists.spdx.org/mt/103815753/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Serialization meeting agenda and context

[Sean Barnum]

I assert that the agreed requirements are not correct as asserted below.


To avoid re-opening old issues unless absolutely needed, below is a list of 
previous decisions on the handling of ID based on reviewing the notes 
(primarily based on the meeting minutes from 
2023-07-21<https://github.com/spdx/meetings/blob/main/serialisation/2023-07-21.md>,
 
2023-08-01<https://github.com/spdx/meetings/blob/main/tech/2023/2023-08-01.md>, 
2023-08-08<https://github.com/spdx/meetings/blob/main/tech/2023/2023-08-08.md>, 
2023-8-10<https://github.com/spdx/meetings/blob/main/serialisation/2023-08-10.md>):

· At a model/deserialized level every class will have a globally unique 
IRI  ID.  This includes both Element and non-Element classes (e.g. 
CreationInfo, Hash).

· Elements are required to have an ID which is a URI that can be shared 
across serializations (Note: Sean may not have agreed to this decision). It was 
agreed that ALL objects (Element and non-Element) are required at a 
model/deserialized level to have an ID which is a URI that can be shared across 
serializations

· Serializations are allowed to use anonymous ID’s / blank nodes (e.g. 
they can inline the checksum class in JSON-LD) for non-Element classes however, 
when deserializing they must be made unique within the internal model 
representation (e.g. 
Skolomized<https://en.wikipedia.org/wiki/Skolem_normal_form>).

· CreationInfo will use anonymous / blank node ID’s in JSON-LD as the 
compaction approach


The above corrections were the fundamental point of disagreement in the debate 
and the result of the debate resolved it as above which provides an approach 
that will work. It is the very point of the Skolemization discussion. The third 
bullet is actually based on the red corrections added above.
Without these above corrections the graph will not be practically useful for 
targeted use cases.

--
Sean Barnum
MITRE Corporation
703-473-8262

From: Gary O'Neall 
Date: Wednesday, March 20, 2024 at 5:14 PM
To: Spdx-tech@lists.spdx.org , Sean Barnum 
, 'Zavras, Alexios' , 'Joshua 
Watt' 
Subject: [EXT] Serialization meeting agenda and context
Greetings all, Our next serialization meeting is tomorrow (Thursday) at 8AM 
Pacific Time (3PM GMT). We will be continuing the discussion from the tech call 
on how we specify the handling of IDs for the serialized format (pull request 
622). 

Greetings all,

Our next serialization meeting is tomorrow (Thursday) at 8AM Pacific Time (3PM 
GMT).

We will be continuing the discussion from the tech call on how we specify the 
handling of IDs for the serialized format (pull request 622).

To avoid re-opening old issues unless absolutely needed, below is a list of 
previous decisions on the handling of ID based on reviewing the notes 
(primarily based on the meeting minutes from 
2023-07-21<https://github.com/spdx/meetings/blob/main/serialisation/2023-07-21.md>,
 
2023-08-01<https://github.com/spdx/meetings/blob/main/tech/2023/2023-08-01.md>, 
2023-08-08<https://github.com/spdx/meetings/blob/main/tech/2023/2023-08-08.md>, 
2023-8-10<https://github.com/spdx/meetings/blob/main/serialisation/2023-08-10.md>):

· Every class will have an ID.  This includes both Element and 
non-Element classes (e.g. CreationInfo, Hash).

· Elements are required to have an ID which is a URI that can be shared 
across serializations (Note: Sean may not have agreed to this decision)

· Serializations are allowed to use anonymous ID’s / blank nodes (e.g. 
they can inline the checksum class in JSON-LD) for non-Element classes however, 
when deserializing they must be made unique within the internal model 
representation (e.g. 
Skolomized<https://en.wikipedia.org/wiki/Skolem_normal_form>).

· CreationInfo will use anonymous / blank node ID’s in JSON-LD as the 
compaction approach

Additional references:

· Duplication of creation information was discussed on 
2023-05-16<https://github.com/spdx/meetings/blob/main/tech/2023/2023-05-16.md> 
and 
2023-06-27<https://github.com/spdx/meetings/blob/main/tech/2023/2023-06-27.md>

· Issue 
comment<https://github.com/spdx/spdx-3-model/issues/357#issuecomment-1656482951>
 indicating we agreed to use anonymous nodes in JSON-LD for creation info

· JSON example with significant comment / discussions on creation info 
– pull request 376<https://github.com/spdx/spdx-3-model/pull/376>

· Open issue describing various compaction algorithms

If anyone believe we did not make the above decisions, please raise this before 
we dive into solutions – preferably via email before the meeting.

I’ve made a couple of conclusions (or perhaps assumptions) based on the above – 
quite interested if others have come to different conclusions:


· I don’t recall if this was explicitly discussed, but based on the 
fact we have in the 

Re: [spdx-tech] Reminder - timezone change for SPDX tech call

[Gary O'Neall]

Just to clarify – the meeting is at 9AM PDT which is 30 minutes from now.

 

Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Venkat 
Ramakrishnan
Sent: Tuesday, March 12, 2024 7:54 AM
To: Martin, Robert A 
Cc: Spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] Reminder - timezone change for SPDX tech call

 

Hello all,

 

Currently the time in San Francisco is 7:53 AM. In how many minutes from now

would the meeting start? :)

 

Regards,

Venkat.

 

On Tue, Mar 12, 2024 at 5:30 PM Martin, Robert A mailto:ramar...@mitre.org> > wrote:

I beg to differ - the meeting is at 9am PDT - noon EDT.

Bob

Robert (Bob) Martin
Sr. Software and Supply Chain Assurance Principal Eng.
Cross Cutting Solutions and Innovation Dept
Cyber Solutions Innovation Center
MITRE Labs
MITRE Corporation
781-271-3001o
781-424-4095c

On 3/11/24 7:59 PM, Gary O'Neall wrote:

Just a reminder, the U. S. is now on daylight savings time, so the call may be 
an hour earlier depending on your location. The call is scheduled for 10AM PDT. 
Best regards, Gary _. _,_. _,_ Links: You receive all messages sent to this 
group. View/Reply 

Just a reminder, the U.S. is now on daylight savings time, so the call may be 
an hour earlier depending on your location.

 

The call is scheduled for 10AM PDT.

 

Best regards,

Gary





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5567): https://lists.spdx.org/g/Spdx-tech/message/5567
Mute This Topic: https://lists.spdx.org/mt/104875832/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Reminder - timezone change for SPDX tech call

[Gary O'Neall]

Correction: the call is at 9AM PDT - sorry for the extra confusion.

 

Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Gary
O'Neall
Sent: Monday, March 11, 2024 4:59 PM
To: spdx-tech@lists.spdx.org
Subject: [spdx-tech] Reminder - timezone change for SPDX tech call

 

Just a reminder, the U.S. is now on daylight savings time, so the call may
be an hour earlier depending on your location.

 

The call is scheduled for 10AM PDT.

 

Best regards,

Gary





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5566): https://lists.spdx.org/g/Spdx-tech/message/5566
Mute This Topic: https://lists.spdx.org/mt/104875832/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Reminder - timezone change for SPDX tech call

[Venkat Ramakrishnan]

Hello all,

Currently the time in San Francisco is 7:53 AM. In how many minutes from now
would the meeting start? :)

Regards,
Venkat.


On Tue, Mar 12, 2024 at 5:30 PM Martin, Robert A  wrote:

> I beg to differ - the meeting is at 9am PDT - noon EDT.
>
> Bob
>
> Robert (Bob) Martin
> Sr. Software and Supply Chain Assurance Principal Eng.
> Cross Cutting Solutions and Innovation Dept
> Cyber Solutions Innovation Center
> MITRE Labs
> MITRE Corporation
> 781-271-3001o
> 781-424-4095c
>
> On 3/11/24 7:59 PM, Gary O'Neall wrote:
>
> Just a reminder, the U. S. is now on daylight savings time, so the call
> may be an hour earlier depending on your location. The call is scheduled
> for 10AM PDT. Best regards, Gary _. _,_. _,_ Links: You receive all
> messages sent to this group. View/Reply
>
> Just a reminder, the U.S. is now on daylight savings time, so the call may
> be an hour earlier depending on your location.
>
>
>
> The call is scheduled for 10AM PDT.
>
>
>
> Best regards,
>
> Gary
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5565): https://lists.spdx.org/g/Spdx-tech/message/5565
Mute This Topic: https://lists.spdx.org/mt/104875832/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Reminder - timezone change for SPDX tech call

[Martin, Robert A]

  
  
I beg to differ - the
meeting is at 9am PDT - noon EDT.
Bob
  
Robert (Bob) Martin
Sr. Software and Supply Chain Assurance Principal Eng.
Cross Cutting Solutions and Innovation Dept
Cyber Solutions Innovation Center
MITRE Labs
MITRE Corporation
781-271-3001o
781-424-4095c
On 3/11/24 7:59 PM, Gary O'Neall wrote:


   Just a reminder, the U. S. is now on daylight savings time,
so the call may be an hour earlier depending on your location.
The call is scheduled for 10AM PDT. Best regards, Gary
_. _,_. _,_ Links: You receive all messages sent to this group.
View/Reply
  
  
  
  
Just a reminder, the U.S. is now on
  daylight savings time, so the call may be an hour earlier
  depending on your location.
 
The call is scheduled for 10AM PDT.
 
Best regards,
Gary
  
  

  



_._,_._,_



Links:


  
You receive all messages sent to this group.
  
  



View/Reply Online (#5564) |


  Reply To Sender
  
	
	| Reply To Group
	
  

|

  Mute This Topic


| New Topic






Your Subscription |
Contact Group Owner |

Unsubscribe

 [arch...@mail-archive.com]
_._,_._,_

Re: [spdx-tech] Tuesday's tech call

[Dick Brooks]

Thanks, Gary.

 

Do you know when the python parser will support Tag/Value?

 

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!
<https://reliableenergyanalytics.com/products>  T

http://www.reliableenergyanalytics.com
<http://www.reliableenergyanalytics.com/> 

Email: d...@reliableenergyanalytics.com
<mailto:d...@reliableenergyanalytics.com> 

Tel: +1 978-696-1788

 

 

From: Gary O'Neall  
Sent: Tuesday, March 5, 2024 2:50 PM
To: d...@reliableenergyanalytics.com; spdx-tech@lists.spdx.org
Subject: RE: [spdx-tech] Tuesday's tech call

 

Hi Dick - the Tag/Value discussion is definitely on the radar.  We will pick
this up in the serialization meetings once Kate is back online.

 

Thanks,

Gary

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of
Dick Brooks
Sent: Tuesday, March 5, 2024 3:40 AM
To: 'Gary O'Neall' mailto:g...@sourceauditor.com>
>; spdx-tech@lists.spdx.org <mailto:spdx-tech@lists.spdx.org> 
Subject: Re: [spdx-tech] Tuesday's tech call

 

Gary,

 

One additional request for us implementers;

 

Decide if Tag/Value serialization (and parsing) is supported or not. 

 

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!
<https://reliableenergyanalytics.com/products>  T

http://www.reliableenergyanalytics.com
<http://www.reliableenergyanalytics.com/> 

Email: d...@reliableenergyanalytics.com
<mailto:d...@reliableenergyanalytics.com> 

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of
Gary O'Neall
Sent: Monday, March 4, 2024 11:16 PM
To: spdx-tech@lists.spdx.org <mailto:spdx-tech@lists.spdx.org> 
Subject: [spdx-tech] Tuesday's tech call

 

For tomorrow's tech call, I have some topics I would like to discuss:

*   Issue 651 <https://github.com/spdx/spdx-3-model/issues/651> :
Conflicting property names prevents compaction
*   Issue 572 <https://github.com/spdx/spdx-3-model/issues/572> :
Confirm we have consensus on the data license - I think we can close this
issue

 

After reviewing all the open issues, there are a few candidates for
discussion on our call:

*   Issue 630 <https://github.com/spdx/spdx-3-model/issues/630> :
Consider extensibility for package "file" types
*   Integrity Method related issues and PR's - Issue 595
<https://github.com/spdx/spdx-3-model/issues/595> , 
*   Issue 561 <https://github.com/spdx/spdx-3-model/issues/561> : Add
Software Level of Support property to Software Package
*   Issue 522 <https://github.com/spdx/spdx-3-model/issues/522> :
Expressing conformance constraints - should this be moved to 3.1?

 

There are quite a few open issues and pull requests that we need to clean up
for the final SPDX 3.0 release (in addition to anything we find in the RC2
review).  I would encourage each of the profile teams to filter the open
issues and pull requests on the profile labels and review / resolve /
update.  If you decide to push the resolution to 3.1, please update the
milestone.

 

Best regards,
Gary





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5559): https://lists.spdx.org/g/Spdx-tech/message/5559
Mute This Topic: https://lists.spdx.org/mt/104738806/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Tuesday's tech call

[Gary O'Neall]

Hi Dick - the Tag/Value discussion is definitely on the radar.  We will pick
this up in the serialization meetings once Kate is back online.

 

Thanks,

Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Dick
Brooks
Sent: Tuesday, March 5, 2024 3:40 AM
To: 'Gary O'Neall' ; spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] Tuesday's tech call

 

Gary,

 

One additional request for us implementers;

 

Decide if Tag/Value serialization (and parsing) is supported or not. 

 

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!
<https://reliableenergyanalytics.com/products>  T

http://www.reliableenergyanalytics.com
<http://www.reliableenergyanalytics.com/> 

Email: d...@reliableenergyanalytics.com
<mailto:d...@reliableenergyanalytics.com> 

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of
Gary O'Neall
Sent: Monday, March 4, 2024 11:16 PM
To: spdx-tech@lists.spdx.org <mailto:spdx-tech@lists.spdx.org> 
Subject: [spdx-tech] Tuesday's tech call

 

For tomorrow's tech call, I have some topics I would like to discuss:

*   Issue 651 <https://github.com/spdx/spdx-3-model/issues/651> :
Conflicting property names prevents compaction
*   Issue 572 <https://github.com/spdx/spdx-3-model/issues/572> :
Confirm we have consensus on the data license - I think we can close this
issue

 

After reviewing all the open issues, there are a few candidates for
discussion on our call:

*   Issue 630 <https://github.com/spdx/spdx-3-model/issues/630> :
Consider extensibility for package "file" types
*   Integrity Method related issues and PR's - Issue 595
<https://github.com/spdx/spdx-3-model/issues/595> , 
*   Issue 561 <https://github.com/spdx/spdx-3-model/issues/561> : Add
Software Level of Support property to Software Package
*   Issue 522 <https://github.com/spdx/spdx-3-model/issues/522> :
Expressing conformance constraints - should this be moved to 3.1?

 

There are quite a few open issues and pull requests that we need to clean up
for the final SPDX 3.0 release (in addition to anything we find in the RC2
review).  I would encourage each of the profile teams to filter the open
issues and pull requests on the profile labels and review / resolve /
update.  If you decide to push the resolution to 3.1, please update the
milestone.

 

Best regards,
Gary





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5558): https://lists.spdx.org/g/Spdx-tech/message/5558
Mute This Topic: https://lists.spdx.org/mt/104738806/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Tuesday's tech call

[Dick Brooks]

Gary,

 

One additional request for us implementers;

 

Decide if Tag/Value serialization (and parsing) is supported or not. 

 

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!
  T

http://www.reliableenergyanalytics.com
 

Email: d...@reliableenergyanalytics.com
 

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Gary
O'Neall
Sent: Monday, March 4, 2024 11:16 PM
To: spdx-tech@lists.spdx.org
Subject: [spdx-tech] Tuesday's tech call

 

For tomorrow's tech call, I have some topics I would like to discuss:

*   Issue 651  :
Conflicting property names prevents compaction
*   Issue 572  :
Confirm we have consensus on the data license - I think we can close this
issue

 

After reviewing all the open issues, there are a few candidates for
discussion on our call:

*   Issue 630  :
Consider extensibility for package "file" types
*   Integrity Method related issues and PR's - Issue 595
 , 
*   Issue 561  : Add
Software Level of Support property to Software Package
*   Issue 522  :
Expressing conformance constraints - should this be moved to 3.1?

 

There are quite a few open issues and pull requests that we need to clean up
for the final SPDX 3.0 release (in addition to anything we find in the RC2
review).  I would encourage each of the profile teams to filter the open
issues and pull requests on the profile labels and review / resolve /
update.  If you decide to push the resolution to 3.1, please update the
milestone.

 

Best regards,
Gary





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#): https://lists.spdx.org/g/Spdx-tech/message/
Mute This Topic: https://lists.spdx.org/mt/104738806/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] JSON schema for spdx-3-model

[Norio Kobota]

Dear Gary-san and all,

> -Original Message-
> From: Gary O'Neall 
> 
> Thanks Kobota-san!
> 
> I like the visualizations and the schemas.  It will really help in the
> definition of the Lite profile.

It's my pleasure. 
I am also looking into spdx-spec issues and will see if I can help.
Please let me know if there's something that needs to be solved soon.

> 
> Originally, I was thinking of coupling the "Lite Profile" to the tag/value
> discussions, but I'm wondering if it may be more aligned with a "simple
> JSON" discussion.
> 
> Something we could discuss on the next Asia SPDX call and the next
> serialization call.

Thanks as always. I look forward to discussing on the next Asia call.

> 
> Should I go ahead and merge the pull request?  We could always create
> subsequent pull requests / issues to add / correct anything we find in
> reviews.

Of course. Please let me know if there's anything wrong for the contribution.

Best regards,
-- Kobota 

> 
> Best regards,
> Gary
> 
> > -Original Message-
> > From: Spdx-tech@lists.spdx.org  On Behalf Of
> > Norio Kobota
> > Sent: Sunday, February 25, 2024 8:41 PM
> > To: spdx-tech@lists.spdx.org
> > Subject: [spdx-tech] JSON schema for spdx-3-model
> >
> > Dear SPDX tech team,
> >
> > I tried to create and to visualize a JSON Schema for
> > INVALID URI REMOVED
> __;!!JmoZiZGBv3RvKRSx!9XN7rfxDD2iO_sBh9T2oJupX9ey-
> LedihGNdaQ2wyFLjk3yzX5LFfi-
> 1WZDfR01yS0jrhzdL9pecE6XZDdzmlGGqq6yi$ [github[.]com]
> > model/commit/ca9738bd0fa0f826f9cccac76ca18e326af84d35.
> > You can find my PR on
> INVALID URI REMOVED
> __;!!JmoZiZGBv3RvKRSx!9XN7rfxDD2iO_sBh9T2oJupX9ey-
> LedihGNdaQ2wyFLjk3yzX5LFfi-
> 1WZDfR01yS0jrhzdL9pecE6XZDdzmlEIYt9TV$ [github[.]com]
> > prototype-playground/pull/28 .
> > There may be mistakes, but I hope these diagrams helps you understand
> the
> > current specification.
> > Also, I could not correctly represent some things, such as Constraints,
> with
> > JSON schema.
> > I am not familiar with JSON LD, so if there is a way to solve with JSON
> LD, it
> > would be helpful if you could tell me those as well.
> >
> > Best, regards,
> >   -- Kobota
> >
> >
> >
> > 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5552): https://lists.spdx.org/g/Spdx-tech/message/5552
Mute This Topic: https://lists.spdx.org/mt/104577208/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] JSON schema for spdx-3-model

[Gary O'Neall]

Thanks Kobota-san!

I like the visualizations and the schemas.  It will really help in the
definition of the Lite profile.

Originally, I was thinking of coupling the "Lite Profile" to the tag/value
discussions, but I'm wondering if it may be more aligned with a "simple
JSON" discussion.

Something we could discuss on the next Asia SPDX call and the next
serialization call.

Should I go ahead and merge the pull request?  We could always create
subsequent pull requests / issues to add / correct anything we find in
reviews.

Best regards,
Gary

> -Original Message-
> From: Spdx-tech@lists.spdx.org  On Behalf Of
> Norio Kobota
> Sent: Sunday, February 25, 2024 8:41 PM
> To: spdx-tech@lists.spdx.org
> Subject: [spdx-tech] JSON schema for spdx-3-model
> 
> Dear SPDX tech team,
> 
> I tried to create and to visualize a JSON Schema for
> https://github.com/spdx/spdx-3-
> model/commit/ca9738bd0fa0f826f9cccac76ca18e326af84d35.
> You can find my PR on https://github.com/spdx/spdx-3-serialization-
> prototype-playground/pull/28 .
> There may be mistakes, but I hope these diagrams helps you understand the
> current specification.
> Also, I could not correctly represent some things, such as Constraints,
with
> JSON schema.
> I am not familiar with JSON LD, so if there is a way to solve with JSON
LD, it
> would be helpful if you could tell me those as well.
> 
> Best, regards,
>   -- Kobota
> 
> 
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5551): https://lists.spdx.org/g/Spdx-tech/message/5551
Mute This Topic: https://lists.spdx.org/mt/104577208/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Build Profile meeting invite pause

[Brandon Lum via lists.spdx.org]

thanks Gary!

On Mon, Feb 26, 2024 at 12:57 PM Gary O'Neall 
wrote:

> I just paused the meetings - we should not get any additional reminders
> after this.
>
> Gary
>
> > -Original Message-
> > From: Spdx-tech@lists.spdx.org  On Behalf Of
> > Joshua Watt
> > Sent: Monday, February 26, 2024 9:23 AM
> > To: l...@google.com
> > Cc: SPDX Technical Mailing List 
> > Subject: Re: [spdx-tech] Build Profile meeting invite pause
> >
> > Yes, AFAIK we are done now.
> >
> > On Mon, Feb 26, 2024 at 10:19 AM Brandon Lum via lists.spdx.org
> >  wrote:
> > >
> > > Hi,
> > >
> > > I believe the build profiles meeting is on pause right now, would it be
> > possible to cancel the meeting invites for now?
> > >
> > > Cheers
> > > Brandon
> > >
> >
> >
> > 
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5548): https://lists.spdx.org/g/Spdx-tech/message/5548
Mute This Topic: https://lists.spdx.org/mt/104586371/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Build Profile meeting invite pause

[Gary O'Neall]

I just paused the meetings - we should not get any additional reminders after 
this.

Gary

> -Original Message-
> From: Spdx-tech@lists.spdx.org  On Behalf Of
> Joshua Watt
> Sent: Monday, February 26, 2024 9:23 AM
> To: l...@google.com
> Cc: SPDX Technical Mailing List 
> Subject: Re: [spdx-tech] Build Profile meeting invite pause
> 
> Yes, AFAIK we are done now.
> 
> On Mon, Feb 26, 2024 at 10:19 AM Brandon Lum via lists.spdx.org
>  wrote:
> >
> > Hi,
> >
> > I believe the build profiles meeting is on pause right now, would it be
> possible to cancel the meeting invites for now?
> >
> > Cheers
> > Brandon
> >
> 
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5547): https://lists.spdx.org/g/Spdx-tech/message/5547
Mute This Topic: https://lists.spdx.org/mt/104586371/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Build Profile meeting invite pause

[Joshua Watt]

Yes, AFAIK we are done now.

On Mon, Feb 26, 2024 at 10:19 AM Brandon Lum via lists.spdx.org
 wrote:
>
> Hi,
>
> I believe the build profiles meeting is on pause right now, would it be 
> possible to cancel the meeting invites for now?
>
> Cheers
> Brandon
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5545): https://lists.spdx.org/g/Spdx-tech/message/5545
Mute This Topic: https://lists.spdx.org/mt/104586371/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX 3.0

[Gary O'Neall]

Hi Benedicte,

 

Responses inline below.

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of 
Benedicte Presse
Sent: Wednesday, February 21, 2024 6:33 AM
To: spdx-tech@lists.spdx.org
Subject: [spdx-tech] SPDX 3.0

 

Hi all,

 

I read some informations about SPDX, and especially that the 3.0 SPDX model 
will soon be released (I saw that a release candidate has been publied).

Could you tell me when it will be delivered ?

[G.O.] We just released the RC2 version of the model.  This is the version we 
will be taking through the OMG standards process and we expect there will be 
some feedback requiring (hopefully minor) changes.  That being said, we would 
encourage anyone interested in SPDX 3.0 to start evaluating/using the RC2 
version.  This would help provide valuable feedback if you run into any issues. 
 Also note that we separate the model from the full spec.  The 3.0-RC2 version 
of the spec should be out very soon – within a week or so.  The spec will 
provide a more readable version of the model plus various supporting 
documentation.  We’ll send out a message on this distribution list once it is 
ready.

Will it be possible to migrate from 2.0 to 3.0 ? 

[G.O.] Yes – There is a draft document describing the migration from SPDX 2.X 
to SPDX 3.0: 
https://docs.google.com/document/d/1-olHRnX1CssUS67Psv_sAq9Vd-pc81HF8MM0hA7M0hg/edit#heading=h.uzojmh0kkl
 – I’m in the process of updating the document for the RC2 release.

 

Thank in advance for your answer,

Best regards,

Benedicte Presse





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5540): https://lists.spdx.org/g/Spdx-tech/message/5540
Mute This Topic: https://lists.spdx.org/mt/104489065/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] FOSDEM face-to-face meeting

[Alexios Zavras]

Ah, thanks Philippe!

Everyone, we will meet for our face-to-face right at the end of the previous 
event (now in the new location of Hotel Bedford).

-- 
zvr
-Original Message-
From: Spdx-tech@lists.spdx.org  On Behalf Of Philippe 
Ombredanne
Sent: Friday, 26 January, 2024 14:57
To: Zavras, Alexios 
Cc: Spdx-tech@lists.spdx.org; Adam Herzog 
Subject: Re: [spdx-tech] FOSDEM face-to-face meeting

Hi Alexios:

We had to move the venue to Hotel Bedford and this was completed yesterday.
The key reason is we have many more registrations and wanted to make sure we 
could have a better spot with comfortable and enough space!

See https://www.hotelbedford.be/en/meetings-and-events/

We will be in the larger Galileo room:
See http://www.immodeposit.com/projects/bedford/panos.html?s=pano1019#pano1019

There are likely many more options there.
--
Cordially
Philippe



On Fri, Jan 26, 2024 at 12:18 PM Alexios Zavras  
wrote:
>
> Hi all,
>
>
>
> We are organizing a face-to-face meeting in Brussels, just before FOSDEM. As 
> many of us will be there, we thought it would be a great opportunity to 
> gather and engage in some insightful technical discussions.
>
>
>
> Since a number of us will be present at the event organized by Philippe on 
> Friday, our meeting will take place right after that one, at the same place.
>
> So, mark your calendars for meeting us on Friday 2 February 2024 at 17:00, at 
> La Tricoterie!
>
>
>
> The primary topic of our discussion will be automatically processing the 
> SPDXv3 RDF ontology to create classes for various programming languages. This 
> topic aims to explore ways to make implementations of SPDXv3 handling much 
> easier and efficient.
>
> However, the discussion is not limited to this topic alone. We encourage you 
> to bring up any other technical subjects that you believe would be of 
> interest to the group. Your input and expertise would be greatly appreciated 
> and beneficial to our collective learning.
>
>
>
> There is no need to register, or even inform anyone about attending; just 
> show up!
>
> Looking forward to seeing you there and having an engaging discussion.
>
>
>
> --
>
> zvr
>
> 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
>
> 



--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
AboutCode - Open source for open source - https://www.aboutcode.org 
VulnerableCode - the open code and open data vulnerability database - 
https://github.com/nexb/vulnerablecode
ScanCode - scan your code, for origin/license/vulnerabilities, report SBOMs - 
https://github.com/nexB/scancode-toolkit
https://github.com/nexB/scancode.io
package-url - the mostly universal SBOM identifier for packages - 
https://github.com/package-url DejaCode - What's in your code?! - 
http://www.dejacode.com nexB Inc. - http://www.nexb.com





Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5505): https://lists.spdx.org/g/Spdx-tech/message/5505
Mute This Topic: https://lists.spdx.org/mt/103974053/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] FOSDEM face-to-face meeting

[Philippe Ombredanne]

Hi Alexios:

We had to move the venue to Hotel Bedford and this was completed yesterday.
The key reason is we have many more registrations and wanted to make
sure we could have a better spot with comfortable and enough space!

See https://www.hotelbedford.be/en/meetings-and-events/

We will be in the larger Galileo room:
See http://www.immodeposit.com/projects/bedford/panos.html?s=pano1019#pano1019

There are likely many more options there.
--
Cordially
Philippe



On Fri, Jan 26, 2024 at 12:18 PM Alexios Zavras
 wrote:
>
> Hi all,
>
>
>
> We are organizing a face-to-face meeting in Brussels, just before FOSDEM. As 
> many of us will be there, we thought it would be a great opportunity to 
> gather and engage in some insightful technical discussions.
>
>
>
> Since a number of us will be present at the event organized by Philippe on 
> Friday, our meeting will take place right after that one, at the same place.
>
> So, mark your calendars for meeting us on Friday 2 February 2024 at 17:00, at 
> La Tricoterie!
>
>
>
> The primary topic of our discussion will be automatically processing the 
> SPDXv3 RDF ontology to create classes for various programming languages. This 
> topic aims to explore ways to make implementations of SPDXv3 handling much 
> easier and efficient.
>
> However, the discussion is not limited to this topic alone. We encourage you 
> to bring up any other technical subjects that you believe would be of 
> interest to the group. Your input and expertise would be greatly appreciated 
> and beneficial to our collective learning.
>
>
>
> There is no need to register, or even inform anyone about attending; just 
> show up!
>
> Looking forward to seeing you there and having an engaging discussion.
>
>
>
> --
>
> zvr
>
> 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
>
> 



-- 
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombreda...@nexb.com
AboutCode - Open source for open source - https://www.aboutcode.org
VulnerableCode - the open code and open data vulnerability database -
https://github.com/nexb/vulnerablecode
ScanCode - scan your code, for origin/license/vulnerabilities, report
SBOMs - https://github.com/nexB/scancode-toolkit
https://github.com/nexB/scancode.io
package-url - the mostly universal SBOM identifier for packages -
https://github.com/package-url
DejaCode - What's in your code?! - http://www.dejacode.com
nexB Inc. - http://www.nexb.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5504): https://lists.spdx.org/g/Spdx-tech/message/5504
Mute This Topic: https://lists.spdx.org/mt/103974053/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] FOSDEM face-to-face meeting

[Dick Brooks]

Unfortunately, I will not be able to attend the FOSDEM meeting and the paper
I presented didn't make the cut.

 

One enhancement I hope we can discuss in SPDX is the addition of an element
(external identifier) to identify, to a "Trust Registry" entry. This is
becoming more urgent, now that Apple has announced its intent to have a
"notarization service" for ios apps:

https://www.linkedin.com/posts/richard-dick-brooks-8078241_apple-announces-c
hanges-to-ios-safari-and-activity-7156404038719168512-CVEo?utm_source=share
 _medium=member_desktop

AND 

IETF SCITT has released its API draft to retrieve "signed statements" from a
Trust Registry/Transparency Service

 

https://datatracker.ietf.org/doc/draft-ietf-scitt-scrapi/

 

 

 

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!
  T

http://www.reliableenergyanalytics.com
 

Email: d...@reliableenergyanalytics.com
 

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of
Alexios Zavras
Sent: Friday, January 26, 2024 6:19 AM
To: Spdx-tech@lists.spdx.org
Subject: [spdx-tech] FOSDEM face-to-face meeting

 

Hi all,

 

We are organizing a face-to-face meeting in Brussels, just before FOSDEM. As
many of us will be there, we thought it would be a great opportunity to
gather and engage in some insightful technical discussions.

 

Since a number of us will be present at the event organized by Philippe on
Friday, our meeting will take place right after that one, at the same place.

So, mark your calendars for meeting us on Friday 2 February 2024 at 17:00,
at La Tricoterie!

 

The primary topic of our discussion will be automatically processing the
SPDXv3 RDF ontology to create classes for various programming languages.
This topic aims to explore ways to make implementations of SPDXv3 handling
much easier and efficient.

However, the discussion is not limited to this topic alone. We encourage you
to bring up any other technical subjects that you believe would be of
interest to the group. Your input and expertise would be greatly appreciated
and beneficial to our collective learning.

 

There is no need to register, or even inform anyone about attending; just
show up!

Looking forward to seeing you there and having an engaging discussion.

 

-- 

zvr

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





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5503): https://lists.spdx.org/g/Spdx-tech/message/5503
Mute This Topic: https://lists.spdx.org/mt/103974053/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] FYI - SPDX Online Tools Upgrade in progress

[Gary O'Neall]

The upgrade to the SPDX online tools is now complete.

 

The online tools has been updated to version 1.2.3.  See the release notes
  for a
summary of the changes.

 

There is one known issue where the "check license" button on the submit new
license page does not work (issue #527
 ).

 

If you run into any issues - please submit a new issue
  in the SPDX
online tools git repository.

 

Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Gary
O'Neall
Sent: Sunday, January 21, 2024 8:46 AM
To: spdx-tech@lists.spdx.org; 'SPDX-legal' 
Subject: [spdx-tech] FYI - SPDX Online Tools Upgrade in progress

 

FYI - I'll be upgrading the SPDX online tools over the next hour or two - it
may be temporarily unavailable.  I'll send a follow-up email once the
upgrade is complete.


Gary





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5496): https://lists.spdx.org/g/Spdx-tech/message/5496
Mute This Topic: https://lists.spdx.org/mt/103869268/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] CISA document on identifiers

[叶涛]

发自我的 iPad在 2024年1月19日，03:42，Dick Brooks  写道：I continue to believe that PURL/SWID, with a required namespace tag for software supplier identity, offers the most potential as an international unique software identifier. There are constraints that limit the viable options for unique software identifiers. 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.comEmail: d...@reliableenergyanalytics.comTel: +1 978-696-1788  From: Spdx-tech@lists.spdx.org  On Behalf Of Brandon Lum via lists.spdx.orgSent: Thursday, January 18, 2024 2:38 PMTo: Gary O'Neall Cc: spdx-tech@lists.spdx.orgSubject: Re: [spdx-tech] CISA document on identifiers I know there were quite a few responses to the RFC from CISA's paper (including ones i was involved with: Google, OpenSSF, GUAC). My gut feel to the CISA paper was more of a starting point for discussion than a guidance document. I am hoping that the responses will promote a forum for us to have these discussions with them and the broader community. On Thu, Jan 18, 2024 at 2:33 PM Gary O'Neall <g...@sourceauditor.com> wrote:One of the proposed solutions for package verification is to use OMNIBor identifiers for verification purposes (see PR #602 for documentation on this approach). Since it relates to identifiers, I thought it might be useful to review the recently release paper on identifiers from CISA – there is a request for comment. Note that the goal of the paper seems focused on the correlation of package artifacts with vulnerability management systems.  There are other use cases which don’t seem to be considered (or at least mentioned) in the paper. A few things I noticed while scanning the paper related to the verification code discussion:It sadly doesn’t reference Software Heritage ID’s, which I personally think is a well thought through identifier scheme.  I wonder how SWHID’s compare with OmniBOR in terms of some of the issues raised in the paper.No mention of using the identifiers for verification purpose, although there is a mention of “Inherent Identifiers” whose properties include the ability to verifyOne of the criteria is “grouping” – which is stated to be unsolved at this pointSection 2.5 “Path 5: Unidentified Software Descriptor to Augment Paths 2, 3, and 4” describes a path which seems quite implementable using our current SPDX 3.0 model Gary








_._,_._,_



Links:


  
You receive all messages sent to this group.
  
  



View/Reply Online (#5493) |


  Reply To Sender
  
	
	| Reply To Group
	
  

|

  Mute This Topic


| New Topic






Your Subscription |
Contact Group Owner |

Unsubscribe

 [arch...@mail-archive.com]
_._,_._,_

Re: [spdx-tech] CISA document on identifiers

[Dick Brooks]

I continue to believe that PURL/SWID, with a required namespace tag for 
software supplier identity, offers the most potential as an international 
unique software identifier.

 

There are constraints that limit the viable options for unique software 
identifiers.

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Brandon 
Lum via lists.spdx.org
Sent: Thursday, January 18, 2024 2:38 PM
To: Gary O'Neall 
Cc: spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] CISA document on identifiers

 

I know there were quite a few responses to the RFC from CISA's paper (including 
ones i was involved with: Google, OpenSSF, GUAC). My gut feel to the CISA paper 
was more of a starting point for discussion than a guidance document. I am 
hoping that the responses will promote a forum for us to have these discussions 
with them and the broader community.

 

On Thu, Jan 18, 2024 at 2:33 PM Gary O'Neall mailto:g...@sourceauditor.com> > wrote:

One of the proposed solutions for package verification is to use OMNIBor 
identifiers for verification purposes (see PR #602 
<https://github.com/spdx/spdx-3-model/pull/602>  for documentation on this 
approach).

 

Since it relates to identifiers, I thought it might be useful to review the 
recently release paper on identifiers from CISA 
<https://www.cisa.gov/sites/default/files/2023-10/Software-Identification-Ecosystem-Option-Analysis-508c.pdf>
  – there is a request for comment.

 

Note that the goal of the paper seems focused on the correlation of package 
artifacts with vulnerability management systems.  There are other use cases 
which don’t seem to be considered (or at least mentioned) in the paper.

 

A few things I noticed while scanning the paper related to the verification 
code discussion:

*   It sadly doesn’t reference Software Heritage ID’s, which I personally 
think is a well thought through identifier scheme.  I wonder how SWHID’s 
compare with OmniBOR in terms of some of the issues raised in the paper.
*   No mention of using the identifiers for verification purpose, although 
there is a mention of “Inherent Identifiers” whose properties include the 
ability to verify
*   One of the criteria is “grouping” – which is stated to be unsolved at 
this point
*   Section 2.5 “Path 5: Unidentified Software Descriptor to Augment Paths 
2, 3, and 4” describes a path which seems quite implementable using our current 
SPDX 3.0 model

 

Gary





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5492): https://lists.spdx.org/g/Spdx-tech/message/5492
Mute This Topic: https://lists.spdx.org/mt/103815753/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] CISA document on identifiers

[Brandon Lum via lists.spdx.org]

I know there were quite a few responses to the RFC from CISA's paper
(including ones i was involved with: Google, OpenSSF, GUAC). My gut feel to
the CISA paper was more of a starting point for discussion than a guidance
document. I am hoping that the responses will promote a forum for us to
have these discussions with them and the broader community.

On Thu, Jan 18, 2024 at 2:33 PM Gary O'Neall  wrote:

> One of the proposed solutions for package verification is to use OMNIBor
> identifiers for verification purposes (see PR #602
>  for documentation on this
> approach).
>
>
>
> Since it relates to identifiers, I thought it might be useful to review
> the recently release paper on identifiers from CISA
> 
> – there is a request for comment.
>
>
>
> Note that the goal of the paper seems focused on the correlation of
> package artifacts with vulnerability management systems.  There are other
> use cases which don’t seem to be considered (or at least mentioned) in the
> paper.
>
>
>
> A few things I noticed while scanning the paper related to the
> verification code discussion:
>
>- It sadly doesn’t reference Software Heritage ID’s, which I
>personally think is a well thought through identifier scheme.  I wonder how
>SWHID’s compare with OmniBOR in terms of some of the issues raised in the
>paper.
>- No mention of using the identifiers for verification purpose,
>although there is a mention of “Inherent Identifiers” whose properties
>include the ability to verify
>- One of the criteria is “grouping” – which is stated to be unsolved
>at this point
>- Section 2.5 “Path 5: Unidentified Software Descriptor to Augment
>Paths 2, 3, and 4” describes a path which seems quite implementable using
>our current SPDX 3.0 model
>
>
>
> Gary
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5491): https://lists.spdx.org/g/Spdx-tech/message/5491
Mute This Topic: https://lists.spdx.org/mt/103815753/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Licences Text - evolution

[Wayne Beaton via lists.spdx.org]

A lot of the answers you seek are here:

https://github.com/spdx/license-list-XML/blob/main/DOCS/license-inclusion-principles.md

Wayne

On Thu, Dec 21, 2023 at 6:40 AM Benedicte Presse <
pressebenedicte...@gmail.com> wrote:

> Dear all,
>
> I have 2 questions :
> Are licensing texts evolving ?
> Software authors may modify license conditions at any time.
> How can we ensure that the license texts on the spdx/licenses site are up
> to date?
>
> Why not list the commercial licences ?
>
> Thank in advance for your answer.
>
> Best regards,
> Bénédicte Presse
> 
>
>

-- 

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation


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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5464): https://lists.spdx.org/g/Spdx-tech/message/5464
Mute This Topic: https://lists.spdx.org/mt/103298759/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Commercial tools

[Gary O'Neall]

Hi Benedicte,

 

The SPDX outreach team maintains the website and the list of commercial tools.

 

Moving this email to the outreach team list.

 

I don’t believe there has been a request to add FNCI to the list.

 

To request the addition of the tool, an issue can be added to the outreach 
github repo: https://github.com/spdx/outreach/issues

 

Ideally, the request would be made by the owner of the tool.

 

The request should include all the necessary information for the tools (e.g. 
versions supported, scenarios).

 

Best regards,
Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of 
Benedicte Presse
Sent: Thursday, November 23, 2023 9:31 AM
To: spdx-tech@lists.spdx.org
Subject: [spdx-tech] Commercial tools

 

Hello,

 

On the spdx website, we can see several commercial tools : BlackDuck, ...

 

Why isn't FNCI (FlexNet Code Insight) from Renevera (or old name : Palamida) in 
this list ?

 

Thank in advance for your ansswer,

Best regards, 





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5442): https://lists.spdx.org/g/Spdx-tech/message/5442
Mute This Topic: https://lists.spdx.org/mt/102770291/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Clarification regarding spec 7.14 All licenses information from files field

[lukas.panni via lists.spdx.org]

Hi Alexios,

I must've missed the cardinality information, thank you for clarifying!


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5425): https://lists.spdx.org/g/Spdx-tech/message/5425
Mute This Topic: https://lists.spdx.org/mt/102461133/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Clarification regarding spec 7.14 All licenses information from files field

[Alexios Zavras]

Hi Lukas, thanks for asking.

Please note the cardinality of that field, which is 0..*, which means you can 
have multiple instances of this in your data.
Each one of them has to have the value (as you write) “NONE, NOASSERTION or a 
SPDX License Expression”, but you can have more than one.

The examples show three different licenses.
I admit, the typesetting of the Tag-Value example (Example 1) look split into 
three different ones, but it’s only one set with three lines.

--
zvr
From: Spdx-tech@lists.spdx.org  On Behalf Of 
lukas.panni via lists.spdx.org
Sent: Wednesday, 8 November, 2023 11:34
To: Spdx-tech@lists.spdx.org
Subject: [spdx-tech] Clarification regarding spec 7.14 All licenses information 
from files field

Hi all,

when working with different tools I noticed a difference in handling the All 
licenses information from files 
field.
The specification explicitly states the following:
The relationship between licenses (i.e., conjunctive, disjunctive) is not 
specified in this field - it is simply a listing of all licenses found
However, it is specified that this field should either contain NONE, 
NOASSERTION or a SPDX License Expression according to Annex 
D.
The syntax seemingly does not allow a simple 'listing of all licenses found', 
instead for multiple licenses it requires to use AND/OR to list multiple 
License-IDs.

So how to properly handle this field?
To pass syntax validation we would need to specify the relationships between 
licenses which would contradict the field's description.


Thanks in advance,
Lukas



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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5424): https://lists.spdx.org/g/Spdx-tech/message/5424
Mute This Topic: https://lists.spdx.org/mt/102461133/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Add some other informations about software components

[Kate Stewart]

Hi Benedicte,
Right now the recommendation in 2.X is to use the Package Comment field
(
https://spdx.github.io/spdx-spec/v2.3/package-information/#720-package-comment-field)
to record the information in a structured fashion, so you can reparse it
later.
SPDX 3.X will have an extension point that can be used to work with this
structured information.

 There are a group of others looking at recording this information in a
more standardized way for 3.1
and have some draft schemas under discussion.Hopefully we'll be able to
announce a working group
for this topic soon.   Do you want me to put you in touch in the interim?

Thanks,
Kate





On Fri, Nov 3, 2023 at 1:13 PM Benedicte Presse <
pressebenedicte...@gmail.com> wrote:

> Hello,
>
> We may require additional information for packages or third-party software
> components.
>
> For example, on export control (classification, country of origin,
> presence of cryptography, etc.).
>
> Where can we put this information?
> In externalRefs / Category : Other / Type : ? / Locator : ?
>
> Thank in advance for your support,
> Best regards,
> Bénédicte
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5417): https://lists.spdx.org/g/Spdx-tech/message/5417
Mute This Topic: https://lists.spdx.org/mt/102370043/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: 
https://lists.spdx.org/g/Spdx-tech/leave/2656181/21656/1901338254/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Conversion spdx files from 2.2 to 2.3

[Gary O'Neall]

Greetings Benedicte,

 

The SPDX Java Libraries used by tools-java and the SPDX online tools does 
support upgrading from 2.2 to 2.3.  I just realized, however, there is no UI or 
command line option to enable this ☹

 

I’ve added an issue to tools-java to implement this: 
https://github.com/spdx/tools-java/issues/146

 

Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Dick 
Brooks
Sent: Friday, November 3, 2023 7:57 AM
To: 'Benedicte Presse' ; spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] Conversion spdx files from 2.2 to 2.3

 

That could be difficult to achieve as V 2.2 file objects do not contain 
“version” information, making it difficult to determine the version info when 
changing from a file object into a V 2.3 Package Object with a Primary Purpose 
= “File”

 

I don’t think it would help much to convert Files to Package’s with a Primary 
Purpose = “File” if the version field always contains “NO ASSERTION”.

 

Just my 0.02.

 

At REA, we just decided to create SPDX V 2.3 SBOM’s from scratch, but we also 
found it very easy to convert a CycloneDX SBOM into an SPDX V 2.3 SBOM, and 
vice versa.

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of 
Benedicte Presse
Sent: Friday, November 3, 2023 10:40 AM
To: spdx-tech@lists.spdx.org <mailto:spdx-tech@lists.spdx.org> 
Subject: [spdx-tech] Conversion spdx files from 2.2 to 2.3

 

Hello,

 

Is there a tool that converts spdx files from 2.2 to 2.3 release ?

I find no tool in github.

 

Thank in advance for your answer,

Best regards,

Bénédicte





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5414): https://lists.spdx.org/g/Spdx-tech/message/5414
Mute This Topic: https://lists.spdx.org/mt/102365235/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Conversion spdx files from 2.2 to 2.3

[Dick Brooks]

That could be difficult to achieve as V 2.2 file objects do not contain 
“version” information, making it difficult to determine the version info when 
changing from a file object into a V 2.3 Package Object with a Primary Purpose 
= “File”

 

I don’t think it would help much to convert Files to Package’s with a Primary 
Purpose = “File” if the version field always contains “NO ASSERTION”.

 

Just my 0.02.

 

At REA, we just decided to create SPDX V 2.3 SBOM’s from scratch, but we also 
found it very easy to convert a CycloneDX SBOM into an SPDX V 2.3 SBOM, and 
vice versa.

 

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:   
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of 
Benedicte Presse
Sent: Friday, November 3, 2023 10:40 AM
To: spdx-tech@lists.spdx.org
Subject: [spdx-tech] Conversion spdx files from 2.2 to 2.3

 

Hello,

 

Is there a tool that converts spdx files from 2.2 to 2.3 release ?

I find no tool in github.

 

Thank in advance for your answer,

Best regards,

Bénédicte





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5413): https://lists.spdx.org/g/Spdx-tech/message/5413
Mute This Topic: https://lists.spdx.org/mt/102365235/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] RDF range problem in SHACL model

[Sean Barnum]

I do not see anything here that would constrain core:createdBy to exactly 
Agent. It should be fine for any subclass of Agent.


The first object in the JSON defines the core:CreationInfo class and associates 
a particular property shape ("@id": "_:N34622bbc773e4833a8e46851e0ed869c",
) with that class.

The third object in the JSON defines the core:createdBY property. It specifies 
its semantic relationship to the CreationInfo class with the domain assertion. 
BTW, I strongly suggest we avoid asserting domains on properties as this has 
complex semantic inferencing meaning in rdf/owl that I do not think we intend 
to assert or have thought/talked through yet. The rdfs:range on the property 
definition asserts that all values of the createdBy property should be of the 
class Agent. This means ANY instance of Agent which included instances of 
subclasses Agent are valid values.

The second object in the JSON defines a property shape to constrain how the 
createdBy property can exist as a property of CreationInfo. It have no effect 
of how createdBy could be used on any other class that is not CreationInfo or a 
subclass of CreationInfo. In this case, the sh:path property of the shape 
identifies which property we are dealing with, the sh:minCount asserts a 
cardinality constraint of 1 (there must be at least one) on the values of 
createdBy property on the CreationInfo class. The sh:class property of the 
shape asserts that any values of createdBy specifically on instances of the 
CreationInfo class must be Agent (or any subclass of agent).

The reason for specifying a rdfs:range on the property definition AND 
specifying an sh:class constraint on the property shape is that the sh:class 
could assert a narrower class constraint (e.g., Person) for the use of 
createdBy property specifically on the CreationInfo class than the broader 
constrain on its use in general.

BTW, the sh:property property on the definition of CreationInfo is a list of 
relevant property shapes for that class. It is present in the class definition 
because that definition is BOTH a class definition AND a SHACL NodeShape 
definition as expressed in

"@type": [

"owl:Class",

"sh:NodeShape"

  ],


Does this make sense?

Sean

From: Joshua Watt 
Date: Thursday, October 26, 2023 at 10:57 AM
To: Sean Barnum 
Cc: Alexios Zavras , Gary O'Neall 
, SPDX Technical Mailing List 
Subject: [EXT] Re: [spdx-tech] RDF range problem in SHACL model
I couldn't figure out how to get that example to work (because this is all very 
new to me, and the https: //shacl. org/playground/ didn't like it when I just 
copied and pasted it in there. . . . however I was looking through the model. 
jsonld and


I couldn't figure out how to get that example to work (because this is

all very new to me, and the https://shacl.org/playground/ didn't like

it when I just copied and pasted it in there however I was looking

through the model.jsonld and I think maybe I saw something suspicious.

The CreationInfo class is defined as:



{

  "@id": "core:CreationInfo",

  "@type": [

"owl:Class",

"sh:NodeShape"

  ],

  "sh:property": [

{

  "@id": "_:N34622bbc773e4833a8e46851e0ed869c"

},

  ]

},

{

  "@id": "_:N34622bbc773e4833a8e46851e0ed869c",

  "sh:class": {

"@id": "core:Agent"

  },

  "sh:minCount": 1,

  "sh:name": "createdBy",

  "sh:path": {

"@id": "core:createdBy"

  }

},

{

  "@id": "core:createdBy",

  "@type": "owl:ObjectProperty",

  "rdfs:domain": {

"@id": "core:CreationInfo"

  },

  "rdfs:range": {

"@id": "core:Agent"

  }

},



So, based on my reading, is is possible the property

(_:N34622bbc773e4833a8e46851e0ed869c) is placing an additional

constraint on the property via the "sh:class" that must exactly match

"core:Agent".



Also, strange to me (but again, I don't understand RDF) why the

"rdfs:range" only seems to be linked to the property via "sh:path"

instead of being in the "sh:property" itself ?





On Thu, Oct 26, 2023 at 8:48 AM Sean Barnum  wrote:

>

> I agree.

>

>

>

> From: Spdx-tech@lists.spdx.org  on behalf of 
> Alexios Zavras 

> Date: Thursday, October 26, 2023 at 10:32 AM

> To: Gary O'Neall , 'Joshua Watt' 
> , 'SPDX Technical Mailing List' 
> 

> Subject: [EXT] Re: [spdx-tech] RDF range problem in SHACL model

>

> I agree that all instances of a subclass (Organization) are also instances of 
&g

Re: [spdx-tech] RDF range problem in SHACL model

[Joshua Watt]

Will do.

 FWIW, it's also a problem when I use the ttl model, so I don't think
it's because of the JSON-LD translation

On Thu, Oct 26, 2023 at 9:14 AM Alexios Zavras  wrote:
>
> OK, so it's not a PySHACL issue/limitation.
> I saved my minimal example to a file named 'ex.ttl' (after adding '<' and '>' 
> around the URLs on the first lines that I'd missed), and:
>
> $ venv-pyshacl/bin/pyshacl ex.ttl
> Validation Report
> Conforms: True
>
> So the RDF is fine, and PySHACL does not complain.
>
>
> From what you've discovered, maybe it's the translation to JSON-LD that 
> introduces the problem.
>
> Since this is not something for email threads, do you mind opening an issue 
> on the spec-parser repo?
>
> --
> zvr
> -Original Message-
> From: Joshua Watt 
> Sent: Thursday, 26 October, 2023 16:57
> To: Sean Barnum 
> Cc: Zavras, Alexios ; Gary O'Neall 
> ; SPDX Technical Mailing List 
> 
> Subject: Re: [spdx-tech] RDF range problem in SHACL model
>
> I couldn't figure out how to get that example to work (because this is all 
> very new to me, and the https://shacl.org/playground/ didn't like it when I 
> just copied and pasted it in there however I was looking through the 
> model.jsonld and I think maybe I saw something suspicious.
> The CreationInfo class is defined as:
>
> {
>   "@id": "core:CreationInfo",
>   "@type": [
> "owl:Class",
> "sh:NodeShape"
>   ],
>   "sh:property": [
> {
>   "@id": "_:N34622bbc773e4833a8e46851e0ed869c"
> },
>   ]
> },
> {
>   "@id": "_:N34622bbc773e4833a8e46851e0ed869c",
>   "sh:class": {
> "@id": "core:Agent"
>   },
>   "sh:minCount": 1,
>   "sh:name": "createdBy",
>   "sh:path": {
> "@id": "core:createdBy"
>   }
> },
> {
>   "@id": "core:createdBy",
>   "@type": "owl:ObjectProperty",
>   "rdfs:domain": {
> "@id": "core:CreationInfo"
>   },
>   "rdfs:range": {
> "@id": "core:Agent"
>   }
> },
>
> So, based on my reading, is is possible the property
> (_:N34622bbc773e4833a8e46851e0ed869c) is placing an additional constraint on 
> the property via the "sh:class" that must exactly match "core:Agent".
>
> Also, strange to me (but again, I don't understand RDF) why the "rdfs:range" 
> only seems to be linked to the property via "sh:path"
> instead of being in the "sh:property" itself ?
>
>
> On Thu, Oct 26, 2023 at 8:48 AM Sean Barnum  wrote:
> >
> > I agree.
> >
> >
> >
> > From: Spdx-tech@lists.spdx.org  on behalf of
> > Alexios Zavras 
> > Date: Thursday, October 26, 2023 at 10:32 AM
> > To: Gary O'Neall , 'Joshua Watt'
> > , 'SPDX Technical Mailing List'
> > 
> > Subject: [EXT] Re: [spdx-tech] RDF range problem in SHACL model
> >
> > I agree that all instances of a subclass (Organization) are also
> > instances of the superclass (Agent), so there should not be any issue.
> > This is not even related to SHACL; it’s simple RDF. Minimal example to
> > try: @prefix rdfs: http: //www. w3. org/2000/01/rdf-schema#
> >
> > I agree that all instances of a subclass (Organization) are also instances 
> > of the superclass (Agent), so there should not be any issue.
> >
> > This is not even related to SHACL; it’s simple RDF.
> >
> >
> >
> > Minimal example to try:
> >
> > @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
> >
> > @prefix owl: http://www.w3.org/2002/07/owl# .
> >
> > @prefix ex: http://zvr.invalid/rdf .
> >
> >
> >
> > ex:CreationInfo a owl:Class .
> >
> > ex:createdBy a owl:ObjectProperty ;
> >
> >rdfs:domain ex:CreationInfo ;
> >
> >rdfs:range ex:Agent .
> >
> > ex:Agent a owl:Class .
> >
> > ex:Organization a owl:Class ;
> >
> > rdfs:subClassOf ex:Agent .
> >
> >
> >
> > ex:someOrganization a ex:Organization .
> >
> > ex:someCreationInfo a ex:CreationInfo .
> >
> > ex:someCreationInfo ex:createdBy ex:someOrganization .
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > zvr
> >
> > From: Spdx-t

Re: [spdx-tech] RDF range problem in SHACL model

[Alexios Zavras]

OK, so it's not a PySHACL issue/limitation.
I saved my minimal example to a file named 'ex.ttl' (after adding '<' and '>' 
around the URLs on the first lines that I'd missed), and:

$ venv-pyshacl/bin/pyshacl ex.ttl
Validation Report
Conforms: True

So the RDF is fine, and PySHACL does not complain.


From what you've discovered, maybe it's the translation to JSON-LD that 
introduces the problem.

Since this is not something for email threads, do you mind opening an issue on 
the spec-parser repo?

-- 
zvr
-Original Message-
From: Joshua Watt  
Sent: Thursday, 26 October, 2023 16:57
To: Sean Barnum 
Cc: Zavras, Alexios ; Gary O'Neall 
; SPDX Technical Mailing List 
Subject: Re: [spdx-tech] RDF range problem in SHACL model

I couldn't figure out how to get that example to work (because this is all very 
new to me, and the https://shacl.org/playground/ didn't like it when I just 
copied and pasted it in there however I was looking through the 
model.jsonld and I think maybe I saw something suspicious.
The CreationInfo class is defined as:

{
  "@id": "core:CreationInfo",
  "@type": [
"owl:Class",
"sh:NodeShape"
  ],
  "sh:property": [
{
  "@id": "_:N34622bbc773e4833a8e46851e0ed869c"
},
  ]
},
{
  "@id": "_:N34622bbc773e4833a8e46851e0ed869c",
  "sh:class": {
"@id": "core:Agent"
  },
  "sh:minCount": 1,
  "sh:name": "createdBy",
  "sh:path": {
"@id": "core:createdBy"
  }
},
{
  "@id": "core:createdBy",
  "@type": "owl:ObjectProperty",
  "rdfs:domain": {
"@id": "core:CreationInfo"
  },
  "rdfs:range": {
"@id": "core:Agent"
  }
},

So, based on my reading, is is possible the property
(_:N34622bbc773e4833a8e46851e0ed869c) is placing an additional constraint on 
the property via the "sh:class" that must exactly match "core:Agent".

Also, strange to me (but again, I don't understand RDF) why the "rdfs:range" 
only seems to be linked to the property via "sh:path"
instead of being in the "sh:property" itself ?


On Thu, Oct 26, 2023 at 8:48 AM Sean Barnum  wrote:
>
> I agree.
>
>
>
> From: Spdx-tech@lists.spdx.org  on behalf of 
> Alexios Zavras 
> Date: Thursday, October 26, 2023 at 10:32 AM
> To: Gary O'Neall , 'Joshua Watt' 
> , 'SPDX Technical Mailing List' 
> 
> Subject: [EXT] Re: [spdx-tech] RDF range problem in SHACL model
>
> I agree that all instances of a subclass (Organization) are also 
> instances of the superclass (Agent), so there should not be any issue. 
> This is not even related to SHACL; it’s simple RDF. Minimal example to 
> try: @prefix rdfs: http: //www. w3. org/2000/01/rdf-schema#
>
> I agree that all instances of a subclass (Organization) are also instances of 
> the superclass (Agent), so there should not be any issue.
>
> This is not even related to SHACL; it’s simple RDF.
>
>
>
> Minimal example to try:
>
> @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
>
> @prefix owl: http://www.w3.org/2002/07/owl# .
>
> @prefix ex: http://zvr.invalid/rdf .
>
>
>
> ex:CreationInfo a owl:Class .
>
> ex:createdBy a owl:ObjectProperty ;
>
>rdfs:domain ex:CreationInfo ;
>
>rdfs:range ex:Agent .
>
> ex:Agent a owl:Class .
>
> ex:Organization a owl:Class ;
>
> rdfs:subClassOf ex:Agent .
>
>
>
> ex:someOrganization a ex:Organization .
>
> ex:someCreationInfo a ex:CreationInfo .
>
> ex:someCreationInfo ex:createdBy ex:someOrganization .
>
>
>
>
>
>
>
> --
>
> zvr
>
> From: Spdx-tech@lists.spdx.org  On Behalf Of 
> Gary O'Neall
> Sent: Thursday, 26 October, 2023 14:19
> To: 'Joshua Watt' ; 'SPDX Technical Mailing 
> List' 
> Subject: Re: [spdx-tech] RDF range problem in SHACL model
>
>
>
> Hi Joshua,
>
>
>
> From the RDF spec definition of rdfs:SubclassOf, it looks like subclasses 
> should be allowed in the range since all instances of the subclass should 
> also be instances of the class.
>
>
>
> We could try a different validator to see if this is an issue with 
> PySHACL.  Here’s an online validator: https://shacl.org/playground/
>
>
>
> If you found any documentation to the contrary, let me know.
>
>
>
> Sean, Alexios – any thoughts?
>
> Gary
>
>
>
> > -Original Message-
>
> > From: Spdx-tech@lists.spdx.org  On Behalf 
> &g

Re: [spdx-tech] RDF range problem in SHACL model

[Joshua Watt]

I couldn't figure out how to get that example to work (because this is
all very new to me, and the https://shacl.org/playground/ didn't like
it when I just copied and pasted it in there however I was looking
through the model.jsonld and I think maybe I saw something suspicious.
The CreationInfo class is defined as:

{
  "@id": "core:CreationInfo",
  "@type": [
"owl:Class",
"sh:NodeShape"
  ],
  "sh:property": [
{
  "@id": "_:N34622bbc773e4833a8e46851e0ed869c"
},
  ]
},
{
  "@id": "_:N34622bbc773e4833a8e46851e0ed869c",
  "sh:class": {
"@id": "core:Agent"
  },
  "sh:minCount": 1,
  "sh:name": "createdBy",
  "sh:path": {
"@id": "core:createdBy"
  }
},
{
  "@id": "core:createdBy",
  "@type": "owl:ObjectProperty",
  "rdfs:domain": {
"@id": "core:CreationInfo"
  },
  "rdfs:range": {
"@id": "core:Agent"
  }
},

So, based on my reading, is is possible the property
(_:N34622bbc773e4833a8e46851e0ed869c) is placing an additional
constraint on the property via the "sh:class" that must exactly match
"core:Agent".

Also, strange to me (but again, I don't understand RDF) why the
"rdfs:range" only seems to be linked to the property via "sh:path"
instead of being in the "sh:property" itself ?


On Thu, Oct 26, 2023 at 8:48 AM Sean Barnum  wrote:
>
> I agree.
>
>
>
> From: Spdx-tech@lists.spdx.org  on behalf of 
> Alexios Zavras 
> Date: Thursday, October 26, 2023 at 10:32 AM
> To: Gary O'Neall , 'Joshua Watt' 
> , 'SPDX Technical Mailing List' 
> 
> Subject: [EXT] Re: [spdx-tech] RDF range problem in SHACL model
>
> I agree that all instances of a subclass (Organization) are also instances of 
> the superclass (Agent), so there should not be any issue. This is not even 
> related to SHACL; it’s simple RDF. Minimal example to try: @prefix rdfs: 
> http: //www. w3. org/2000/01/rdf-schema#
>
> I agree that all instances of a subclass (Organization) are also instances of 
> the superclass (Agent), so there should not be any issue.
>
> This is not even related to SHACL; it’s simple RDF.
>
>
>
> Minimal example to try:
>
> @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
>
> @prefix owl: http://www.w3.org/2002/07/owl# .
>
> @prefix ex: http://zvr.invalid/rdf .
>
>
>
> ex:CreationInfo a owl:Class .
>
> ex:createdBy a owl:ObjectProperty ;
>
>rdfs:domain ex:CreationInfo ;
>
>rdfs:range ex:Agent .
>
> ex:Agent a owl:Class .
>
> ex:Organization a owl:Class ;
>
> rdfs:subClassOf ex:Agent .
>
>
>
> ex:someOrganization a ex:Organization .
>
> ex:someCreationInfo a ex:CreationInfo .
>
> ex:someCreationInfo ex:createdBy ex:someOrganization .
>
>
>
>
>
>
>
> --
>
> zvr
>
> From: Spdx-tech@lists.spdx.org  On Behalf Of Gary 
> O'Neall
> Sent: Thursday, 26 October, 2023 14:19
> To: 'Joshua Watt' ; 'SPDX Technical Mailing List' 
> 
> Subject: Re: [spdx-tech] RDF range problem in SHACL model
>
>
>
> Hi Joshua,
>
>
>
> From the RDF spec definition of rdfs:SubclassOf, it looks like subclasses 
> should be allowed in the range since all instances of the subclass should 
> also be instances of the class.
>
>
>
> We could try a different validator to see if this is an issue with PySHACL.  
> Here’s an online validator: https://shacl.org/playground/
>
>
>
> If you found any documentation to the contrary, let me know.
>
>
>
> Sean, Alexios – any thoughts?
>
> Gary
>
>
>
> > -Original Message-
>
> > From: Spdx-tech@lists.spdx.org  On Behalf Of
>
> > Joshua Watt
>
> > Sent: Wednesday, October 25, 2023 12:06 PM
>
> > To: SPDX Technical Mailing List 
>
> > Subject: [spdx-tech] RDF range problem in SHACL model
>
> >
>
> > I dug further into trying to get my Yocto SPDX output to validate against 
> > the
>
> > JSON LD SHACL model. I've made some progress, but I think maybe I've come
>
> > up against a problem that don't know how to solve.
>
> >
>
> > Disclaimer: I'm not an SHACL, RDF or ontology expert so please excuse my
>
> > misuse of nomenclature.
>
> >
>
> > It looks like there might be a problem in the model in regard to the usage 
> > of
>
> > "rdfs

Re: [spdx-tech] RDF range problem in SHACL model

[Sean Barnum]

I agree.

From: Spdx-tech@lists.spdx.org  on behalf of Alexios 
Zavras 
Date: Thursday, October 26, 2023 at 10:32 AM
To: Gary O'Neall , 'Joshua Watt' 
, 'SPDX Technical Mailing List' 
Subject: [EXT] Re: [spdx-tech] RDF range problem in SHACL model
I agree that all instances of a subclass (Organization) are also instances of 
the superclass (Agent), so there should not be any issue. This is not even 
related to SHACL; it’s simple RDF. Minimal example to try: @prefix rdfs: http: 
//www. w3. org/2000/01/rdf-schema#

I agree that all instances of a subclass (Organization) are also instances of 
the superclass (Agent), so there should not be any issue.
This is not even related to SHACL; it’s simple RDF.

Minimal example to try:
@prefix rdfs: 
http://www.w3.org/2000/01/rdf-schema#<http://www.w3.org/2000/01/rdf-schema> .
@prefix owl: http://www.w3.org/2002/07/owl#<http://www.w3.org/2002/07/owl> .
@prefix ex: http://zvr.invalid/rdf .

ex:CreationInfo a owl:Class .
ex:createdBy a owl:ObjectProperty ;
   rdfs:domain ex:CreationInfo ;
   rdfs:range ex:Agent .
ex:Agent a owl:Class .
ex:Organization a owl:Class ;
rdfs:subClassOf ex:Agent .

ex:someOrganization a ex:Organization .
ex:someCreationInfo a ex:CreationInfo .
ex:someCreationInfo ex:createdBy ex:someOrganization .



--
zvr
From: Spdx-tech@lists.spdx.org  On Behalf Of Gary 
O'Neall
Sent: Thursday, 26 October, 2023 14:19
To: 'Joshua Watt' ; 'SPDX Technical Mailing List' 

Subject: Re: [spdx-tech] RDF range problem in SHACL model


Hi Joshua,



>From the RDF spec definition of 
>rdfs:SubclassOf<https://www.w3.org/TR/rdf12-schema/#ch_subclassof>, it looks 
>like subclasses should be allowed in the range since all instances of the 
>subclass should also be instances of the class.



We could try a different validator to see if this is an issue with PySHACL.  
Here’s an online validator: https://shacl.org/playground/



If you found any documentation to the contrary, let me know.



Sean, Alexios – any thoughts?

Gary



> -Original Message-

> From: Spdx-tech@lists.spdx.org<mailto:Spdx-tech@lists.spdx.org> 
> mailto:Spdx-tech@lists.spdx.org>> On Behalf Of

> Joshua Watt

> Sent: Wednesday, October 25, 2023 12:06 PM

> To: SPDX Technical Mailing List 
> mailto:Spdx-tech@lists.spdx.org>>

> Subject: [spdx-tech] RDF range problem in SHACL model

>

> I dug further into trying to get my Yocto SPDX output to validate against the

> JSON LD SHACL model. I've made some progress, but I think maybe I've come

> up against a problem that don't know how to solve.

>

> Disclaimer: I'm not an SHACL, RDF or ontology expert so please excuse my

> misuse of nomenclature.

>

> It looks like there might be a problem in the model in regard to the usage of

> "rdfs:range" to validate the type values of object properties. Based on my

> reading and experiments, it looks like that field requires that the referenced

> object be of _exactly_ one of the listed types, and cannot be a subclass

> derived from that type. As an example, the "createdBy" property of

> core:CreationInfo has "rdfs:range" of "core:Agent". Practically speaking, this

> means that only an _exact_ core:Agent is allowed in this field, and classes

> derived from that class (such as core:Organization) are not allowed (or at

> least, pyshacl indicates a violation).

>

>

>



Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de<http://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



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5400): https://lists.spdx.org/g/Spdx-tech/message/5400
Mute This Topic: https://lists.spdx.org/mt/102185295/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] RDF range problem in SHACL model

[Alexios Zavras]

I agree that all instances of a subclass (Organization) are also instances of 
the superclass (Agent), so there should not be any issue.
This is not even related to SHACL; it’s simple RDF.

Minimal example to try:
@prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@prefix owl: http://www.w3.org/2002/07/owl# .
@prefix ex: http://zvr.invalid/rdf .

ex:CreationInfo a owl:Class .
ex:createdBy a owl:ObjectProperty ;
   rdfs:domain ex:CreationInfo ;
   rdfs:range ex:Agent .
ex:Agent a owl:Class .
ex:Organization a owl:Class ;
rdfs:subClassOf ex:Agent .

ex:someOrganization a ex:Organization .
ex:someCreationInfo a ex:CreationInfo .
ex:someCreationInfo ex:createdBy ex:someOrganization .



--
zvr
From: Spdx-tech@lists.spdx.org  On Behalf Of Gary 
O'Neall
Sent: Thursday, 26 October, 2023 14:19
To: 'Joshua Watt' ; 'SPDX Technical Mailing List' 

Subject: Re: [spdx-tech] RDF range problem in SHACL model


Hi Joshua,



From the RDF spec definition of 
rdfs:SubclassOf<https://www.w3.org/TR/rdf12-schema/#ch_subclassof>, it looks 
like subclasses should be allowed in the range since all instances of the 
subclass should also be instances of the class.



We could try a different validator to see if this is an issue with PySHACL.  
Here’s an online validator: https://shacl.org/playground/



If you found any documentation to the contrary, let me know.



Sean, Alexios – any thoughts?

Gary



> -Original Message-

> From: Spdx-tech@lists.spdx.org<mailto:Spdx-tech@lists.spdx.org> 
> mailto:Spdx-tech@lists.spdx.org>> On Behalf Of

> Joshua Watt

> Sent: Wednesday, October 25, 2023 12:06 PM

> To: SPDX Technical Mailing List 
> mailto:Spdx-tech@lists.spdx.org>>

> Subject: [spdx-tech] RDF range problem in SHACL model

>

> I dug further into trying to get my Yocto SPDX output to validate against the

> JSON LD SHACL model. I've made some progress, but I think maybe I've come

> up against a problem that don't know how to solve.

>

> Disclaimer: I'm not an SHACL, RDF or ontology expert so please excuse my

> misuse of nomenclature.

>

> It looks like there might be a problem in the model in regard to the usage of

> "rdfs:range" to validate the type values of object properties. Based on my

> reading and experiments, it looks like that field requires that the referenced

> object be of _exactly_ one of the listed types, and cannot be a subclass

> derived from that type. As an example, the "createdBy" property of

> core:CreationInfo has "rdfs:range" of "core:Agent". Practically speaking, this

> means that only an _exact_ core:Agent is allowed in this field, and classes

> derived from that class (such as core:Organization) are not allowed (or at

> least, pyshacl indicates a violation).

>

>

>



Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5399): https://lists.spdx.org/g/Spdx-tech/message/5399
Mute This Topic: https://lists.spdx.org/mt/102185295/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] RDF range problem in SHACL model

[Gary O'Neall]

Hi Joshua,

 

>From the RDF spec definition of rdfs:SubclassOf 
> , it looks like subclasses 
>should be allowed in the range since all instances of the subclass should also 
>be instances of the class.

 

We could try a different validator to see if this is an issue with PySHACL.  
Here’s an online validator: https://shacl.org/playground/

 

If you found any documentation to the contrary, let me know.

 

Sean, Alexios – any thoughts?

Gary

 

> -Original Message-

> From: Spdx-tech@lists.spdx.org  On Behalf Of

> Joshua Watt

> Sent: Wednesday, October 25, 2023 12:06 PM

> To: SPDX Technical Mailing List 

> Subject: [spdx-tech] RDF range problem in SHACL model

> 

> I dug further into trying to get my Yocto SPDX output to validate against the

> JSON LD SHACL model. I've made some progress, but I think maybe I've come

> up against a problem that don't know how to solve.

> 

> Disclaimer: I'm not an SHACL, RDF or ontology expert so please excuse my

> misuse of nomenclature.

> 

> It looks like there might be a problem in the model in regard to the usage of

> "rdfs:range" to validate the type values of object properties. Based on my

> reading and experiments, it looks like that field requires that the referenced

> object be of _exactly_ one of the listed types, and cannot be a subclass

> derived from that type. As an example, the "createdBy" property of

> core:CreationInfo has "rdfs:range" of "core:Agent". Practically speaking, this

> means that only an _exact_ core:Agent is allowed in this field, and classes

> derived from that class (such as core:Organization) are not allowed (or at

> least, pyshacl indicates a violation).

> 

> 

> 

 



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5398): https://lists.spdx.org/g/Spdx-tech/message/5398
Mute This Topic: https://lists.spdx.org/mt/102185295/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] How and where (in spdx files) write the choosen licence ?

[Gary O'Neall]

Hi Bénédicte,

 

For the redistributed package, you can put your chosen license in the concluded 
license field.  The declared license should remain as described by the 
originator of the package.  I would also recommend that you add a license 
comment stating that the license was chosen for the redistribution.

 

Best,
Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of 
Benedicte Presse
Sent: Thursday, October 26, 2023 12:26 AM
To: spdx-tech@lists.spdx.org
Subject: [spdx-tech] How and where (in spdx files) write the choosen licence ?

 

Hello,

 

As you know, a software component can have several licenses.

The SPDX standard defines 2 attributes

- One for the declared license

- One for the concluded license

 

When a person redistribute a package, he can choice the applicable license.

For example ("caricatural" example) : A software component is under GPL or MIT. 
He can choice the MIT license, he has to declare the MIT licence redistribution 
to avoid being required to provide the source files required by the GPL v3 
license.

 

How declare in spdx files the choosen licence : MIT, whereas the "declared 
licence can be "GPL v3 OR MIT" (caricatiral example) ?

 

Thank in advance for your answer,

Best regards,

Bénédicte





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5397): https://lists.spdx.org/g/Spdx-tech/message/5397
Mute This Topic: https://lists.spdx.org/mt/102195631/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] How and where (in spdx files) write the choosen licence ?

[Karsten Klein]

Hi Benedicte,

 

if you follow the spec the type for declared and concluded licenses can contain 
a license expression. 

 

https://spdx.github.io/spdx-spec/v2.3/package-information/#713-concluded-license-field

https://spdx.github.io/spdx-spec/v2.3/package-information/#715-declared-license-field

 

See also the SPDX FAQ https://wiki.spdx.org/view/SPDX_FAQ for basic questions:

“SPDX license information can be represented using conjunctive or disjunctive 
regular expressions. For example, a file that is dual licensed under either the 
GPL-2.0 or MIT would be represented using the following disjunctive expression: 
(GPL-2.0 or MIT).”

 

 

Kind regards,

Karsten

 

metaeffekt GmbH

Firmensitz: Renettenweg 6/1, 69124 Heidelberg

Registergericht: Amtsgericht Mannheim, HRB 725313

Geschäftsführer: Karsten Klein

USt.-IdNr.: DE307084554

 

Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen 
beinhalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, informieren Sie 
bitte den Absender und löschen Sie diese E-Mail und alle Kopien umgehend. Eine 
unbefugte Weitergabe der E-Mail oder deren Inhalte und Anhänge ist nicht 
gestattet.

 

Möchten Sie als Empfänger keine Informationen dieser Art erhalten, setzen Sie 
sich bitte unmittelbar mit dem Absender der E-Mail in Verbindung. Die 
metaeffekt GmbH unterstützt Ihre Datenhoheit und informationelle 
Selbstbestimmung und übermittelt Informationen ausschließlich auf der 
Rechtsgrundlage der europäischen Datenschutzgrundverordnung (DSGVO). Weitere 
Informationen zu den Datenverarbeitungsvorgängen und insbesondere Ihrer Rechte 
entnehmen Sie der Datenschutzerklärung der metaeffekt GmbH.

 

 

From:  on behalf of Benedicte Presse 

Date: Thursday, October 26, 2023 at 09:26
To: 
Subject: [spdx-tech] How and where (in spdx files) write the choosen licence ?

 

Hello,

 

As you know, a software component can have several licenses.

The SPDX standard defines 2 attributes

- One for the declared license

- One for the concluded license

 

When a person redistribute a package, he can choice the applicable license.

For example ("caricatural" example) : A software component is under GPL or MIT. 
He can choice the MIT license, he has to declare the MIT licence redistribution 
to avoid being required to provide the source files required by the GPL v3 
license.

 

How declare in spdx files the choosen licence : MIT, whereas the "declared 
licence can be "GPL v3 OR MIT" (caricatiral example) ?

 

Thank in advance for your answer,

Best regards,

Bénédicte





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5396): https://lists.spdx.org/g/Spdx-tech/message/5396
Mute This Topic: https://lists.spdx.org/mt/102195631/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] [spdx] Date model for SPDX

[Gary O'Neall]

Hi Bénédicte,

 

We have an object model and a few schema’s which I’ll detail below.

 

I’m cc’ing the tech mailing list – if you have any follow-on questions, I would 
recommend posting those to the tech team since this list is more general in 
nature.

 

For SPDX 2.3:

*   Object model diagram: 
https://github.com/spdx/spdx-spec/blob/master/ontology/SPDX-2.3-simplified.png 
*   Various ontology RDF OWL schema files (used to generate the above 
object model diagram): https://github.com/spdx/spdx-spec/tree/master/ontology
*   JSON Schema: 
https://github.com/spdx/spdx-spec/blob/master/schemas/spdx-schema.json

 

For SPDX 3.0 (under development for RC2):

*   Generated model HTML files: 
https://spdx.github.io/spdx-3-model/auto-generated/
*   SHACL / OWL: https://spdx.github.io/spdx-3-model/model.ttl
*   Source markdown files for the model: 
https://github.com/spdx/spdx-3-model

 

Best,
Gary

 

 

From: s...@lists.spdx.org  On Behalf Of Benedicte Presse
Sent: Wednesday, October 18, 2023 5:13 AM
To: s...@lists.spdx.org
Subject: [spdx] Date model for SPDX

 

Dear all,

 

Is there a data model for the SPDX format ?

 

Thank in advance for your answer.

Best regards,

 

Bénédicte





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5385): https://lists.spdx.org/g/Spdx-tech/message/5385
Mute This Topic: https://lists.spdx.org/mt/102041797/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Significant announcement from DOD regarding SBOM

[Dick Brooks]

Thanks for clarifying Bob. The Federal Register announcement also contains some 
interesting requests for feedback to some questions the SBOM community has been 
discussing for years:

 

How should SBOMs be collected

from contractors? What specific

protections are necessary for the

information contained within an

SBOM?

* How should the Government think

about the appropriate scope of the

requirement on contractors to provide

SBOMs to ensure appropriate security?

* What challenges will contractors

face in the development of SBOMs?

What challenges are unique to software

resellers? What challenges exist

regarding legacy software?

* What are the appropriate means of

evaluating when an SBOM must be

updated based on changes in a new

build or major release?

* What is the appropriate balance

between the Government and the

contractor, when monitoring SBOMs for

embedded software vulnerabilities as

they are discovered?

 

FYI: IETF SCITT successfully demonstrated one solution for SBOM distribution 
during the Hackathon in July: 

https://energycentral.com/c/iu/international-trust-registry-demonstration-success

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Martin, 
Robert A
Sent: Tuesday, October 3, 2023 11:36 AM
To: Spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] Significant announcement from DOD regarding SBOM

 

Hi Dick,

Little clarification - this is a proposed FAR change coming from DoD, GSA, and 
NASA.

If implemented after the public comment period this would be in affect for all 
government procurements in both the military and civilian sides of government.

Comments due 4 December 2023 here 
<http://www.regulations.gov/commenton/FAR-2021-0017-0001> .

Bob

Robert (Bob) Martin
Sr. Software and Supply Chain Assurance Principal Eng.
Cross Cutting Solutions and Innovation Dept
Cyber Solutions Innovation Center
MITRE Labs
MITRE Corporation
781-271-3001o
781-424-4095c

On 10/3/23 11:10 AM, Dick Brooks wrote:

FYI: Today, DoD issued guidance regarding SBOM requirements and vulnerability 
reporting: https: //www. federalregister. 
gov/documents/2023/10/03/2023-21328/federal-acquisition-regulation-cyber-threat-and-incident-reporting-and-information-sharing

FYI: Today, DoD issued guidance regarding SBOM requirements and vulnerability 
reporting:

https://www.federalregister.gov/documents/2023/10/03/2023-21328/federal-acquisition-regulation-cyber-threat-and-incident-reporting-and-information-sharing

 

 

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! 
<https://reliableenergyanalytics.com/products>  ™

http://www.reliableenergyanalytics.com 
<http://www.reliableenergyanalytics.com/> 

Email: d...@reliableenergyanalytics.com 
<mailto:d...@reliableenergyanalytics.com> 

Tel: +1 978-696-1788

 

 





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5369): https://lists.spdx.org/g/Spdx-tech/message/5369
Mute This Topic: https://lists.spdx.org/mt/101735802/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Significant announcement from DOD regarding SBOM

[Martin, Robert A]

  
  
Hi Dick,
Little clarification -
this is a proposed FAR change coming from DoD, GSA, and NASA.
If implemented after
the public comment period this would be in affect for all
government procurements in both the military and civilian sides
of government.
Comments due 4 December
2023 here.
Bob
  
Robert (Bob) Martin
Sr. Software and Supply Chain Assurance Principal Eng.
Cross Cutting Solutions and Innovation Dept
Cyber Solutions Innovation Center
MITRE Labs
MITRE Corporation
781-271-3001o
781-424-4095c
On 10/3/23 11:10 AM, Dick Brooks wrote:


   FYI: Today, DoD issued guidance regarding SBOM requirements
and vulnerability reporting:
https: //www. federalregister. gov/documents/2023/10/03/2023-21328/federal-acquisition-regulation-cyber-threat-and-incident-reporting-and-information-sharing
  
  
  
FYI: Today, DoD issued guidance regarding
  SBOM requirements and vulnerability reporting:
https://www.federalregister.gov/documents/2023/10/03/2023-21328/federal-acquisition-regulation-cyber-threat-and-incident-reporting-and-information-sharing
 
 
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: d...@reliableenergyanalytics.com
Tel: +1 978-696-1788
 
 
  
  

  



_._,_._,_



Links:


  
You receive all messages sent to this group.
  
  



View/Reply Online (#5368) |


  Reply To Sender
  
	
	| Reply To Group
	
  

|

  Mute This Topic


| New Topic






Your Subscription |
Contact Group Owner |

Unsubscribe

 [arch...@mail-archive.com]
_._,_._,_

Re: [spdx-tech] Was there an implementers and serialization meeting this week?

[Rose Judge via lists.spdx.org]

You’re not the only person who has complained about this recently. I’ll take a 
look and see what might be the issue. I’m guessing something changed in Jitsi.

-Rose

From: Spdx-tech@lists.spdx.org  on behalf of Nisha 
Kumar via lists.spdx.org 
Date: Thursday, September 7, 2023 at 9:00 AM
To: SPDX Technical Mailing List 
Subject: [spdx-tech] Was there an implementers and serialization meeting this 
week?
!! External Email

Hey folks,

I seem to be having trouble joining Jitsi meetings - It says a moderator
will let me into the meeting and I am left on hold. I did try to log
into the meetings but when I did, nobody was there. Have the meetings
moved elsewhere?

--
nisha







!! External Email: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5345): https://lists.spdx.org/g/Spdx-tech/message/5345
Mute This Topic: https://lists.spdx.org/mt/101217592/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Was there an implementers and serialization meeting this week?

[Dick Brooks]

Gary and I attended the implementers meeting, but we were the only two present 
so we ended early.

 

Rose had given warning that she could not attend, beforehand.

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Brandon 
Lum via lists.spdx.org
Sent: Thursday, September 7, 2023 1:04 PM
To: Nisha Kumar 
Cc: SPDX Technical Mailing List 
Subject: Re: [spdx-tech] Was there an implementers and serialization meeting 
this week?

 

I also ran into the issue but didn't login.. 

 

On Thu, Sep 7, 2023 at 12:00 PM Nisha Kumar mailto:ni...@ctlfsh.tech> > wrote:

Hey folks,

I seem to be having trouble joining Jitsi meetings - It says a moderator 
will let me into the meeting and I am left on hold. I did try to log 
into the meetings but when I did, nobody was there. Have the meetings 
moved elsewhere?

-- 
nisha











-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5343): https://lists.spdx.org/g/Spdx-tech/message/5343
Mute This Topic: https://lists.spdx.org/mt/101217592/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Was there an implementers and serialization meeting this week?

[Brandon Lum via lists.spdx.org]

I also ran into the issue but didn't login..

On Thu, Sep 7, 2023 at 12:00 PM Nisha Kumar  wrote:

> Hey folks,
>
> I seem to be having trouble joining Jitsi meetings - It says a moderator
> will let me into the meeting and I am left on hold. I did try to log
> into the meetings but when I did, nobody was there. Have the meetings
> moved elsewhere?
>
> --
> nisha
>
>
>
> 
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5342): https://lists.spdx.org/g/Spdx-tech/message/5342
Mute This Topic: https://lists.spdx.org/mt/101217592/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Question about FileName syntaxe

[Dick Brooks]

Thank you, Gary. This is consistent with what we saw in some of the DocFest
submissions too.

 

End consumers that are only interested in performing “risk assessments”
don’t need (or want) the relative path info on component (file) names, as it
serves no purpose during a NIST NVD search for vulnerabilities in
components. 

 

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!
<https://reliableenergyanalytics.com/products>  ™

http://www.reliableenergyanalytics.com
<http://www.reliableenergyanalytics.com/> 

Email: d...@reliableenergyanalytics.com
<mailto:d...@reliableenergyanalytics.com> 

Tel: +1 978-696-1788

 

 

From: Gary O'Neall  
Sent: Tuesday, September 5, 2023 2:14 PM
To: d...@reliableenergyanalytics.com; 'Marc-Etienne Vargenau (Nokia)'
; 'spdx-tech' 
Subject: RE: [spdx-tech] Question about FileName syntaxe

 

Based on the recommendations in this thread, I’ll update the validation to
not allow file names starting with “/” to be consistent with the spec and
the Python libraries.  I will not require all names start with “./”.

 

It will probably be a month or so before this rolls out to the online
validation tool.

 

Thanks,
Gary

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of
Dick Brooks
Sent: Tuesday, September 5, 2023 9:09 AM
To: 'Marc-Etienne Vargenau (Nokia)' mailto:marc-etienne.varge...@nokia.com> >; 'spdx-tech'
mailto:Spdx-tech@lists.spdx.org> >
Subject: Re: [spdx-tech] Question about FileName syntaxe

 

Marc,

 

REA uses the online validation tool to determine if an SBOM can be
“successfully parsed”:

https://tools.spdx.org/app/validate/

 

We had trouble early on with the Python tools and opted to write our own
SPDX generator and parser instead. We only support JSON and Tag/Value
formats.

 

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!
<https://reliableenergyanalytics.com/products>  ™

http://www.reliableenergyanalytics.com
<http://www.reliableenergyanalytics.com/> 

Email: d...@reliableenergyanalytics.com
<mailto:d...@reliableenergyanalytics.com> 

Tel: +1 978-696-1788

 

 

From: Marc-Etienne Vargenau (Nokia) mailto:marc-etienne.varge...@nokia.com> > 
Sent: Tuesday, September 5, 2023 11:39 AM
To: d...@reliableenergyanalytics.com
<mailto:d...@reliableenergyanalytics.com> ; 'spdx-tech'
mailto:Spdx-tech@lists.spdx.org> >
Subject: Re: [spdx-tech] Question about FileName syntaxe

 

Hi Dick,

 

Currently, the Python tools complain when the path is absolute (beginning
with “/”).

The Java tools (used by the online tools) currently do not complain.

The ticket below is for implementing the same control in Java as in Python.

 

We will issue an error if the path starts with “/”.

But the precise question was: should we issue an error if the path does not
start with “./” ?

 

Marc-Etienne Vargenau

 

-- 
Marc-Etienne Vargenau  <mailto:marc-etienne.varge...@nokia.com>
marc-etienne.varge...@nokia.com
Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
Mobile:   +33 6 24 49 78 68

Senior Specialist Open Source
Planned absence: none

 

 

De : Dick Brooks mailto:d...@reliableenergyanalytics.com> >
Date : mardi, 5 septembre 2023 à 13:12
À : Marc-Etienne Vargenau (Nokia) mailto:marc-etienne.varge...@nokia.com> >, 'spdx-tech'
mailto:Spdx-tech@lists.spdx.org> >
Objet : RE: [spdx-tech] Question about FileName syntaxe

 

Many of the implementations that participated in the DocFest did not include
the “relative path” (/) syntax. The online validation tool will pass an SBOM
that does not contain the relative path filename syntax. 

 

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!
<https://reliableenergyanalytics.com/products>  ™

http://www.reliableenergyanalytics.com
<http://www.reliableenergyanalytics.com/> 

Email: d...@reliableenergyanalytics.com
<mailto:d...@reliableenergyanalytics.com> 

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of
Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)
Sent: Tuesday, September 5, 2023 6:44 AM
To: spdx-tech mailto:Spdx-tech@lists.spdx.org> >
Subject: [spdx-tech] Question about FileName syntaxe

 

Hello,

 

This is related to  <https://github.com/spdx/Spdx-Java-Library/issues/195>
https://github.com/spdx/Spdx-Java-Library/issues/195

 

FileName is defined in the spec as “a relative filename”.

 

So, we sho

Re: [spdx-tech] Question about FileName syntaxe

[Dick Brooks]

Marc,

 

REA uses the online validation tool to determine if an SBOM can be
“successfully parsed”:

https://tools.spdx.org/app/validate/

 

We had trouble early on with the Python tools and opted to write our own
SPDX generator and parser instead. We only support JSON and Tag/Value
formats.

 

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!
<https://reliableenergyanalytics.com/products>  ™

http://www.reliableenergyanalytics.com
<http://www.reliableenergyanalytics.com/> 

Email: d...@reliableenergyanalytics.com
<mailto:d...@reliableenergyanalytics.com> 

Tel: +1 978-696-1788

 

 

From: Marc-Etienne Vargenau (Nokia)  
Sent: Tuesday, September 5, 2023 11:39 AM
To: d...@reliableenergyanalytics.com; 'spdx-tech' 
Subject: Re: [spdx-tech] Question about FileName syntaxe

 

Hi Dick,

 

Currently, the Python tools complain when the path is absolute (beginning
with “/”).

The Java tools (used by the online tools) currently do not complain.

The ticket below is for implementing the same control in Java as in Python.

 

We will issue an error if the path starts with “/”.

But the precise question was: should we issue an error if the path does not
start with “./” ?

 

Marc-Etienne Vargenau

 

-- 
Marc-Etienne Vargenau  <mailto:marc-etienne.varge...@nokia.com>
marc-etienne.varge...@nokia.com
Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
Mobile:   +33 6 24 49 78 68

Senior Specialist Open Source
Planned absence: none

 

 

De : Dick Brooks mailto:d...@reliableenergyanalytics.com> >
Date : mardi, 5 septembre 2023 à 13:12
À : Marc-Etienne Vargenau (Nokia) mailto:marc-etienne.varge...@nokia.com> >, 'spdx-tech'
mailto:Spdx-tech@lists.spdx.org> >
Objet : RE: [spdx-tech] Question about FileName syntaxe

 

Many of the implementations that participated in the DocFest did not include
the “relative path” (/) syntax. The online validation tool will pass an SBOM
that does not contain the relative path filename syntax. 

 

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!
<https://reliableenergyanalytics.com/products>  ™

http://www.reliableenergyanalytics.com
<http://www.reliableenergyanalytics.com/> 

Email: d...@reliableenergyanalytics.com
<mailto:d...@reliableenergyanalytics.com> 

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of
Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)
Sent: Tuesday, September 5, 2023 6:44 AM
To: spdx-tech mailto:Spdx-tech@lists.spdx.org> >
Subject: [spdx-tech] Question about FileName syntaxe

 

Hello,

 

This is related to  <https://github.com/spdx/Spdx-Java-Library/issues/195>
https://github.com/spdx/Spdx-Java-Library/issues/195

 

FileName is defined in the spec as “a relative filename”.

 

So, we should reject as invalid a FileName starting with “/”.

 

The spec then says “In general, every filename is preceded with a ./”

Is this mandatory?

 

In other words, should we reject:

FileName: package/foo.c

 

What is your opinion?

 

Best regards,

 

Marc-Etienne Vargenau

 

-- 
Marc-Etienne Vargenau  <mailto:marc-etienne.varge...@nokia.com>
marc-etienne.varge...@nokia.com
Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
Mobile:   +33 6 24 49 78 68

Senior Specialist Open Source
Planned absence: none

 





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5337): https://lists.spdx.org/g/Spdx-tech/message/5337
Mute This Topic: https://lists.spdx.org/mt/101166533/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Question about FileName syntaxe

[William Bartholomew (CELA) via lists.spdx.org]

There's a couple of reasons why this is helpful:

  1.  Since the path is relative to the root of the package a relative path in 
an image is equivalent to an absolute path.
  2.  We don't want paths to refer to things outside of the package 
(particularly for package managers that don't have as strict of a boundary as 
images do), e.g. no "/home/william/my-secret-stuff".
  3.  If you have the same set of files embedded in multiple packages you can 
reuse the file elements, this is useful for example if you want to represent a 
directory of files within an archive and then to represent that same directory 
of files when it's extracted to a different location.

Makes sense re: RFC-3986, thanks for calling that out (I had it in my mind that 
this was a plain string, not a URI).

William

From: Spdx-tech@lists.spdx.org  on behalf of Keith 
Zantow via lists.spdx.org 
Sent: Tuesday, September 5, 2023 8:56 AM
To: spdx-tech 
Subject: [EXTERNAL] Re: [spdx-tech] Question about FileName syntaxe

You don't often get email from keith.zantow=anchore@lists.spdx.org. Learn 
why this is important<https://aka.ms/LearnAboutSenderIdentification>
I'm curious what the motivation is for paths being relative. If I scan an 
image, for example, I would expect to see absolute paths to the files within 
the image filesystem, rather than those being translated to relative paths.

Cheers,
-Keith

On Tue, Sep 5, 2023 at 11:48 AM Vargenau, Marc-Etienne (Nokia - 
FR/Paris-Saclay) 
mailto:marc-etienne.varge...@nokia.com>> wrote:

Hi William,



I think https://www.ietf.org/rfc/rfc3986.txt only allows “/”, not “\”.



Marc-Etienne



--
Marc-Etienne Vargenau 
marc-etienne.varge...@nokia.com<mailto:marc-etienne.varge...@nokia.com>
Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
Mobile: +33 6 24 49 78 68

Senior Specialist Open Source
Planned absence: none





De : William Bartholomew (CELA) 
mailto:will...@microsoft.com>>
Date : mardi, 5 septembre 2023 à 17:43
À : Marc-Etienne Vargenau (Nokia) 
mailto:marc-etienne.varge...@nokia.com>>, 
'spdx-tech' mailto:Spdx-tech@lists.spdx.org>>, 
Richard Brooks 
mailto:d...@reliableenergyanalytics.com>>
Objet : Re: [EXTERNAL] Re: [spdx-tech] Question about FileName syntaxe

I would recommend against requiring the "./" prefix, but still require that the 
path be relative (and clarifying that is relative to the location of the 
package that the file is contained in). We may also want to clarify whether you 
can use Windows-style path separators ("\") or only Linux-style ones ("/"), and 
we should say that a relative path can't backtrack (i.e. no "..").



William



From: Spdx-tech@lists.spdx.org<mailto:Spdx-tech@lists.spdx.org> 
mailto:Spdx-tech@lists.spdx.org>> on behalf of Dick 
Brooks via lists.spdx.org<http://lists.spdx.org/> 
mailto:reliableenergyanalytics@lists.spdx.org>>
Sent: Tuesday, September 5, 2023 4:12 AM
To: 'Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)' 
mailto:marc-etienne.varge...@nokia.com>>; 
'spdx-tech' mailto:Spdx-tech@lists.spdx.org>>
Subject: [EXTERNAL] Re: [spdx-tech] Question about FileName syntaxe



Many of the implementations that participated in the DocFest did not include 
the “relative path” (/) syntax. The online validation tool will pass an SBOM 
that does not contain the relative path filename syntax.



Thanks,



Dick Brooks

[cid:image001.png@01D9DFC8.4DBFF7E0]  [cid:image004.png@01D9DFC8.54DD68F0]

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership



Never trust software, always verify and 
report!<https://reliableenergyanalytics.com/products> ™

http://www.reliableenergyanalytics.com<http://www.reliableenergyanalytics.com/>

Email: d...@reliableenergyanalytics.com<mailto:d...@reliableenergyanalytics.com>

Tel: +1 978-696-1788





From: Spdx-tech@lists.spdx.org<mailto:Spdx-tech@lists.spdx.org> 
mailto:Spdx-tech@lists.spdx.org>> On Behalf Of 
Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)
Sent: Tuesday, September 5, 2023 6:44 AM
To: spdx-tech mailto:Spdx-tech@lists.spdx.org>>
Subject: [spdx-tech] Question about FileName syntaxe



Hello,



This is related to https://github.com/spdx/Spdx-Java-Library/issues/195



FileName is defined in the spec as “a relative filename”.



So, we should reject as invalid a FileName starting with “/”.



The spec then says “In general, every filename is preceded with a ./”

Is this mandatory?



In other words, should we reject:

FileName: package/foo.c



What is your opinion?



Best regards,



Marc-Etienne Vargenau



--
Marc-Etienne Vargenau 
marc-etienne.varge...@nokia.com<mailto:marc-etienne.varge...@nokia.com>
Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
Mobile: +33 6 24 49 78 68

Senior Specialist Open Source
Pla

Re: [spdx-tech] Question about FileName syntaxe

[Keith Zantow via lists.spdx.org]

I'm curious what the motivation is for paths being relative. If I scan an
image, for example, I would expect to see absolute paths to the files
within the image filesystem, rather than those being translated to relative
paths.

Cheers,
-Keith

On Tue, Sep 5, 2023 at 11:48 AM Vargenau, Marc-Etienne (Nokia -
FR/Paris-Saclay)  wrote:

> Hi William,
>
>
>
> I think https://www.ietf.org/rfc/rfc3986.txt only allows “/”, not “\”.
>
>
>
> Marc-Etienne
>
>
>
> --
> Marc-Etienne Vargenau marc-etienne.varge...@nokia.com
> Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
> Mobile: +33 6 24 49 78 68 <+33624497868>
>
> Senior Specialist Open Source
> Planned absence: *none*
>
>
>
>
>
> *De : *William Bartholomew (CELA) 
> *Date : *mardi, 5 septembre 2023 à 17:43
> *À : *Marc-Etienne Vargenau (Nokia) ,
> 'spdx-tech' , Richard Brooks <
> d...@reliableenergyanalytics.com>
> *Objet : *Re: [EXTERNAL] Re: [spdx-tech] Question about FileName syntaxe
>
> I would recommend against requiring the "./" prefix, but still require
> that the path be relative (and clarifying that is relative to the location
> of the package that the file is contained in). We may also want to clarify
> whether you can use Windows-style path separators ("\") or only Linux-style
> ones ("/"), and we should say that a relative path can't backtrack (i.e. no
> "..").
>
>
>
> William
> --
>
> *From:* Spdx-tech@lists.spdx.org  on behalf of
> Dick Brooks via lists.spdx.org  reliableenergyanalytics@lists.spdx.org>
> *Sent:* Tuesday, September 5, 2023 4:12 AM
> *To:* 'Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)' <
> marc-etienne.varge...@nokia.com>; 'spdx-tech' 
> *Subject:* [EXTERNAL] Re: [spdx-tech] Question about FileName syntaxe
>
>
>
> Many of the implementations that participated in the DocFest did not
> include the “relative path” (/) syntax. The online validation tool will
> pass an SBOM that does not contain the relative path filename syntax.
>
>
>
> 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!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: d...@reliableenergyanalytics.com
>
> Tel: +1 978-696-1788
>
>
>
>
>
> *From:* Spdx-tech@lists.spdx.org  *On Behalf Of
> *Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)
> *Sent:* Tuesday, September 5, 2023 6:44 AM
> *To:* spdx-tech 
> *Subject:* [spdx-tech] Question about FileName syntaxe
>
>
>
> Hello,
>
>
>
> This is related to https://github.com/spdx/Spdx-Java-Library/issues/195
>
>
>
> FileName is defined in the spec as “a relative filename”.
>
>
>
> So, we should reject as invalid a FileName starting with “/”.
>
>
>
> The spec then says “In general, every filename is preceded with a ./”
>
> Is this mandatory?
>
>
>
> In other words, should we reject:
>
> FileName: package/foo.c
>
>
>
> What is your opinion?
>
>
>
> Best regards,
>
>
>
> Marc-Etienne Vargenau
>
>
>
> --
> Marc-Etienne Vargenau marc-etienne.varge...@nokia.com
> Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
> Mobile: +33 6 24 49 78 68 <+33624497868>
>
> Senior Specialist Open Source
> Planned absence: *none*
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5334): https://lists.spdx.org/g/Spdx-tech/message/5334
Mute This Topic: https://lists.spdx.org/mt/101166533/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Question about FileName syntaxe

[Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)]

Hi William,

I think https://www.ietf.org/rfc/rfc3986.txt only allows “/”, not “\”.

Marc-Etienne

--
Marc-Etienne Vargenau 
marc-etienne.varge...@nokia.com<mailto:marc-etienne.varge...@nokia.com>
Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
Mobile: +33 6 24 49 78 68
Senior Specialist Open Source
Planned absence: none


De : William Bartholomew (CELA) 
Date : mardi, 5 septembre 2023 à 17:43
À : Marc-Etienne Vargenau (Nokia) , 
'spdx-tech' , Richard Brooks 

Objet : Re: [EXTERNAL] Re: [spdx-tech] Question about FileName syntaxe
I would recommend against requiring the "./" prefix, but still require that the 
path be relative (and clarifying that is relative to the location of the 
package that the file is contained in). We may also want to clarify whether you 
can use Windows-style path separators ("\") or only Linux-style ones ("/"), and 
we should say that a relative path can't backtrack (i.e. no "..").

William

From: Spdx-tech@lists.spdx.org  on behalf of Dick 
Brooks via lists.spdx.org 
Sent: Tuesday, September 5, 2023 4:12 AM
To: 'Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)' 
; 'spdx-tech' 
Subject: [EXTERNAL] Re: [spdx-tech] Question about FileName syntaxe


Many of the implementations that participated in the DocFest did not include 
the “relative path” (/) syntax. The online validation tool will pass an SBOM 
that does not contain the relative path filename syntax.



Thanks,



Dick Brooks

[cid:image001.png@01D9DFC8.4DBFF7E0]  [cid:image004.png@01D9DFC8.54DD68F0]

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership



Never trust software, always verify and 
report!<https://reliableenergyanalytics.com/products> ™

http://www.reliableenergyanalytics.com<http://www.reliableenergyanalytics.com/>

Email: d...@reliableenergyanalytics.com<mailto:d...@reliableenergyanalytics.com>

Tel: +1 978-696-1788





From: Spdx-tech@lists.spdx.org  On Behalf Of 
Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)
Sent: Tuesday, September 5, 2023 6:44 AM
To: spdx-tech 
Subject: [spdx-tech] Question about FileName syntaxe



Hello,



This is related to https://github.com/spdx/Spdx-Java-Library/issues/195



FileName is defined in the spec as “a relative filename”.



So, we should reject as invalid a FileName starting with “/”.



The spec then says “In general, every filename is preceded with a ./”

Is this mandatory?



In other words, should we reject:

FileName: package/foo.c



What is your opinion?



Best regards,



Marc-Etienne Vargenau



--
Marc-Etienne Vargenau 
marc-etienne.varge...@nokia.com<mailto:marc-etienne.varge...@nokia.com>
Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
Mobile: +33 6 24 49 78 68

Senior Specialist Open Source
Planned absence: none





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5332): https://lists.spdx.org/g/Spdx-tech/message/5332
Mute This Topic: https://lists.spdx.org/mt/101166533/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Question about FileName syntaxe

[William Bartholomew (CELA) via lists.spdx.org]

I would recommend against requiring the "./" prefix, but still require that the 
path be relative (and clarifying that is relative to the location of the 
package that the file is contained in). We may also want to clarify whether you 
can use Windows-style path separators ("\") or only Linux-style ones ("/"), and 
we should say that a relative path can't backtrack (i.e. no "..").

William

From: Spdx-tech@lists.spdx.org  on behalf of Dick 
Brooks via lists.spdx.org 
Sent: Tuesday, September 5, 2023 4:12 AM
To: 'Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)' 
; 'spdx-tech' 
Subject: [EXTERNAL] Re: [spdx-tech] Question about FileName syntaxe


Many of the implementations that participated in the DocFest did not include 
the “relative path” (/) syntax. The online validation tool will pass an SBOM 
that does not contain the relative path filename syntax.



Thanks,



Dick Brooks

[cid:image001.png@01D9DFC8.4DBFF7E0]  [cid:image004.png@01D9DFC8.54DD68F0]

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership



Never trust software, always verify and 
report!<https://reliableenergyanalytics.com/products> ™

http://www.reliableenergyanalytics.com<http://www.reliableenergyanalytics.com/>

Email: d...@reliableenergyanalytics.com<mailto:d...@reliableenergyanalytics.com>

Tel: +1 978-696-1788





From: Spdx-tech@lists.spdx.org  On Behalf Of 
Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)
Sent: Tuesday, September 5, 2023 6:44 AM
To: spdx-tech 
Subject: [spdx-tech] Question about FileName syntaxe



Hello,



This is related to https://github.com/spdx/Spdx-Java-Library/issues/195



FileName is defined in the spec as “a relative filename”.



So, we should reject as invalid a FileName starting with “/”.



The spec then says “In general, every filename is preceded with a ./”

Is this mandatory?



In other words, should we reject:

FileName: package/foo.c



What is your opinion?



Best regards,



Marc-Etienne Vargenau



--
Marc-Etienne Vargenau 
marc-etienne.varge...@nokia.com<mailto:marc-etienne.varge...@nokia.com>
Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
Mobile: +33 6 24 49 78 68

Senior Specialist Open Source
Planned absence: none






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5331): https://lists.spdx.org/g/Spdx-tech/message/5331
Mute This Topic: https://lists.spdx.org/mt/101166533/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Question about FileName syntaxe

[Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)]

Hi Dick,

Currently, the Python tools complain when the path is absolute (beginning with 
“/”).
The Java tools (used by the online tools) currently do not complain.
The ticket below is for implementing the same control in Java as in Python.

We will issue an error if the path starts with “/”.
But the precise question was: should we issue an error if the path does not 
start with “./” ?

Marc-Etienne Vargenau

--
Marc-Etienne Vargenau 
marc-etienne.varge...@nokia.com<mailto:marc-etienne.varge...@nokia.com>
Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
Mobile: +33 6 24 49 78 68
Senior Specialist Open Source
Planned absence: none


De : Dick Brooks 
Date : mardi, 5 septembre 2023 à 13:12
À : Marc-Etienne Vargenau (Nokia) , 
'spdx-tech' 
Objet : RE: [spdx-tech] Question about FileName syntaxe


Many of the implementations that participated in the DocFest did not include 
the “relative path” (/) syntax. The online validation tool will pass an SBOM 
that does not contain the relative path filename syntax.

Thanks,

Dick Brooks
[cid:image001.png@01D9DFC8.4DBFF7E0]  [cid:image004.png@01D9DFC8.54DD68F0]
Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council – A Public-Private Partnership

Never trust software, always verify and 
report!<https://reliableenergyanalytics.com/products> ™
http://www.reliableenergyanalytics.com<http://www.reliableenergyanalytics.com/>
Email: d...@reliableenergyanalytics.com<mailto:d...@reliableenergyanalytics.com>
Tel: +1 978-696-1788


From: Spdx-tech@lists.spdx.org  On Behalf Of 
Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)
Sent: Tuesday, September 5, 2023 6:44 AM
To: spdx-tech 
Subject: [spdx-tech] Question about FileName syntaxe

Hello,

This is related to https://github.com/spdx/Spdx-Java-Library/issues/195

FileName is defined in the spec as “a relative filename”.

So, we should reject as invalid a FileName starting with “/”.

The spec then says “In general, every filename is preceded with a ./”
Is this mandatory?

In other words, should we reject:
FileName: package/foo.c

What is your opinion?

Best regards,

Marc-Etienne Vargenau

--
Marc-Etienne Vargenau 
marc-etienne.varge...@nokia.com<mailto:marc-etienne.varge...@nokia.com>
Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
Mobile: +33 6 24 49 78 68
Senior Specialist Open Source
Planned absence: none




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5330): https://lists.spdx.org/g/Spdx-tech/message/5330
Mute This Topic: https://lists.spdx.org/mt/101166533/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Homework for this week's tech call

[Gary O'Neall]

Just a bit more background on the namespace map, there were two previous
PR's attempting to solve the NamespaceMap problem - at the start of our tech
call, we can decide if we want to include either of these in the solutions
to be considered.  Send this out before the call so you have a chance to
review in case they do come up on the call:

 

*   Original solution proposal moving NamespaceMap to Document:
https://github.com/spdx/spdx-3-model/pull/403/files
*   Proposal to create a separate profile for serialization information:
https://github.com/spdx/spdx-3-model/pull/479

 

Gary

 

From: Gary O'Neall  
Sent: Monday, September 4, 2023 5:31 PM
To: 'SPDX Technical Mailing List' 
Subject: Homework for this week's tech call

 

Greetings all,

 

I would like to ask before the tech call this week you review the following
before participating in the discussion on namespace maps:

*   Last tech call minutes - around line 58 in
https://spdx.swinslow.net/p/spdx-tech-minutes 
*   Last week's serialization team minutes around line 23 in
https://spdx.swinslow.net/p/spdx-tech-minutes 
*   Sean's PR containing a proposed solution using the namespace map
https://github.com/spdx/spdx-3-model/pull/490 
*   My attempt at creating a PR implementation of Max's proposed
solution (If Max has time before the call, he may update the PR to better
reflect the proposal) https://github.com/spdx/spdx-3-model/pull/491 

 

Please note: the class named "X" is temporary.  We agreed on a prior
serialization call not to name the class until we finished defining the
semantics.

 

On the tech call, we plan to choose between these 2 proposals.  We will base
our decision on how well it supports the use cases we discussed in previous
calls and other criteria such as complexity to understand and complexity to
implement.

 

Thanks,
Gary



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5329): https://lists.spdx.org/g/Spdx-tech/message/5329
Mute This Topic: https://lists.spdx.org/mt/101160591/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Question about FileName syntaxe

[Dick Brooks]

Many of the implementations that participated in the DocFest did not include
the "relative path" (/) syntax. The online validation tool will pass an SBOM
that does not contain the relative path filename syntax. 

 

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!
  T

http://www.reliableenergyanalytics.com
 

Email: d...@reliableenergyanalytics.com
 

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of
Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay)
Sent: Tuesday, September 5, 2023 6:44 AM
To: spdx-tech 
Subject: [spdx-tech] Question about FileName syntaxe

 

Hello,

 

This is related to  
https://github.com/spdx/Spdx-Java-Library/issues/195

 

FileName is defined in the spec as "a relative filename".

 

So, we should reject as invalid a FileName starting with "/".

 

The spec then says "In general, every filename is preceded with a ./"

Is this mandatory?

 

In other words, should we reject:

FileName: package/foo.c

 

What is your opinion?

 

Best regards,

 

Marc-Etienne Vargenau

 

-- 
Marc-Etienne Vargenau  
marc-etienne.varge...@nokia.com
Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE
Mobile:   +33 6 24 49 78 68

Senior Specialist Open Source
Planned absence: none

 





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5328): https://lists.spdx.org/g/Spdx-tech/message/5328
Mute This Topic: https://lists.spdx.org/mt/101166533/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Dick Brooks]

Alexios,

 

Regarding this assertion,  “having a value of NOASSERTION as packageVersion 
means that the SBOM including this does NOT meet NTIA’s minimum requirements”

 

I disagree with this assertion, Alexios. The NTIA SBOM framing document 
provides guidance with regard to missing data:

 

SBOMs must gracefully handle cases of missing or non-applicable attributes. A 
basic

recommendation is to always provide all of the baseline attributes but 
explicitly define values

that differentiate between “no assertion” (i.e., data is missing), and “no 
value” (i.e., the attribute

is not applicable for this specific SBOM). Alternatively, an SBOM format can 
permit missing

baseline attributes and treat them as default values (i.e., “no assertion” or 
“no value”).

 

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Eliot 
Lear
Sent: Monday, August 21, 2023 9:33 AM
To: Alexios Zavras ; Gary O'Neall 
; l...@google.com
Cc: d...@reliableenergyanalytics.com; 'SPDX Technical Mailing List' 
; 'Emrick Donadei' ; 'Tyler 
Pirtle' 
Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field

 

So I know the following is the case:

On 21.08.23 12:05, Alexios Zavras wrote:

Regardless of this, I hope that we all agree that having a value of NOASSERTION 
as packageVersion means that the SBOM including this does NOT meet NTIA’s 
minimum requirements.

I do wonder if people will get around this by simply Making Stuff Up.  Not 
suggesting that as an approach, mind you.

Eliot





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5313): https://lists.spdx.org/g/Spdx-tech/message/5313
Mute This Topic: https://lists.spdx.org/mt/100823660/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Eliot Lear]

So I know the following is the case:

On 21.08.23 12:05, Alexios Zavras wrote:


Regardless of this, I hope that we all agree that having a value of 
NOASSERTION as packageVersion means that the SBOM including this does 
NOT meet NTIA’s minimum requirements.


I do wonder if people will get around this by simply Making Stuff Up.  
Not suggesting that as an approach, mind you.


Eliot


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5312): https://lists.spdx.org/g/Spdx-tech/message/5312
Mute This Topic: https://lists.spdx.org/mt/100823660/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Eliot Lear]

Hi Dick

That makes a lot of sense.  One might layer on top of the binary scan 
some sort of declaration... I don't know if people do that.


Eliot

On 21.08.23 15:28, Dick Brooks wrote:


Eliot,

With help from Keith at Anchore during some recent testing I was able 
to explain the difficulties REA has experienced with identifying 
enforceable License information during a binary analysis.


Fortunately, licensing information is optional under SPDX V 2.3; 
Licensing information is not a “minimal element” under the NTIA SBOM 
minimum elements recommendations for EO 14028.


https://spdx.github.io/spdx-spec/v2.3/package-information/#713-concluded-license-field 



https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/

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! 
<https://reliableenergyanalytics.com/products>/*™


http://www.reliableenergyanalytics.com 
<http://www.reliableenergyanalytics.com/>


Email: d...@reliableenergyanalytics.com 
<mailto:d...@reliableenergyanalytics.com>


Tel: +1 978-696-1788

*From:* Spdx-tech@lists.spdx.org  *On Behalf 
Of *Eliot Lear

*Sent:* Monday, August 21, 2023 9:18 AM
*To:* keith.zan...@anchore.com; l...@google.com
*Cc:* SPDX Technical Mailing List ; Emrick 
Donadei ; Tyler Pirtle 

*Subject:* Re: [spdx-tech] NOASSERTION on PackageVersion field

I could understand why Syft would want to do NOASSERTION, and even a 
manufacturer might need to do something like this if we are receiving 
binaries from suppliers.   Licensing probably doesn't care about 
versioning so long as a license is declared.  But cybersecurity 
cares.  Is it a show stopper? Not for a manufacturer because we can 
issue VEX statements. But for Syft, it may be more problematic because 
Syft may not be in a position to create a VEX (I don't know).


Eliot

On 18.08.23 18:34, Keith Zantow via lists.spdx.org wrote:

We just had a talk about this yesterday due to a Syft issue that
came in: https://github.com/anchore/syft/issues/2038 (from
Emrick). Currently, we're thinking about excluding packages
without name and version information, but the NOASSERTION idea is
also something that seems to solve the problem fairly well.

I suppose I'm giving a plus-one on adding this as a specific value
for the version when we cannot determine it, but also welcome
thoughts on how best to handle this situation.

Cheers,

-Keith

On Fri, Aug 18, 2023 at 12:15 PM Brandon Lum via lists.spdx.org
<http://lists.spdx.org>  wrote:

Hi,

In generating some of our SPDX documents, we've (Tyler/Emrick
CC'ed) run into situations where the version information of a
package is unknown. What comes to mind is to set the version
to NOASSERTION. However, this is not currently spelt out in
the spec

(https://spdx.github.io/spdx-spec/v2.3/package-information/#73-package-version-field).


Although semantically, in terms of usage of information, it
should be similar, it still lacks the ability to say that
"This information is incomplete", with exception of having
NOASSERTION be set on the DEPENDS_ON relationship more broadly
- which may perhaps be a different discussion altogether.

Wanted to get thoughts on this.

Cheers

Brandon





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5311): https://lists.spdx.org/g/Spdx-tech/message/5311
Mute This Topic: https://lists.spdx.org/mt/100823660/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Dick Brooks]

Eliot,

 

With help from Keith at Anchore during some recent testing I was able to 
explain the difficulties REA has experienced with identifying enforceable 
License information during a binary analysis. 

 

Fortunately, licensing information is optional under SPDX V 2.3; Licensing 
information is not a “minimal element” under the NTIA SBOM minimum elements 
recommendations for EO 14028. 

https://spdx.github.io/spdx-spec/v2.3/package-information/#713-concluded-license-field
 

https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Eliot 
Lear
Sent: Monday, August 21, 2023 9:18 AM
To: keith.zan...@anchore.com; l...@google.com
Cc: SPDX Technical Mailing List ; Emrick Donadei 
; Tyler Pirtle 
Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field

 

 

I could understand why Syft would want to do NOASSERTION, and even a 
manufacturer might need to do something like this if we are receiving binaries 
from suppliers.   Licensing probably doesn't care about versioning so long as a 
license is declared.  But cybersecurity cares.  Is it a show stopper?  Not for 
a manufacturer because we can issue VEX statements.  But for Syft, it may be 
more problematic because Syft may not be in a position to create a VEX (I don't 
know).

Eliot

On 18.08.23 18:34, Keith Zantow via lists.spdx.org wrote:

We just had a talk about this yesterday due to a Syft issue that came in: 
https://github.com/anchore/syft/issues/2038 (from Emrick). Currently, we're 
thinking about excluding packages without name and version information, but the 
NOASSERTION idea is also something that seems to solve the problem fairly well. 

 

I suppose I'm giving a plus-one on adding this as a specific value for the 
version when we cannot determine it, but also welcome thoughts on how best to 
handle this situation.

 

Cheers,

-Keith

 

On Fri, Aug 18, 2023 at 12:15 PM Brandon Lum via lists.spdx.org 
<http://lists.spdx.org>  mailto:google@lists.spdx.org> > wrote:

Hi, 

 

In generating some of our SPDX documents, we've (Tyler/Emrick CC'ed) run into 
situations where the version information of a package is unknown. What comes to 
mind is to set the version to NOASSERTION. However, this is not currently spelt 
out in the spec 
(https://spdx.github.io/spdx-spec/v2.3/package-information/#73-package-version-field).
 

 

Although semantically, in terms of usage of information, it should be similar, 
it still lacks the ability to say that "This information is incomplete", with 
exception of having NOASSERTION be set on the DEPENDS_ON relationship more 
broadly - which may perhaps be a different discussion altogether. 

 

Wanted to get thoughts on this.

 

Cheers

Brandon





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5310): https://lists.spdx.org/g/Spdx-tech/message/5310
Mute This Topic: https://lists.spdx.org/mt/100823660/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Eliot Lear]

I could understand why Syft would want to do NOASSERTION, and even a 
manufacturer might need to do something like this if we are receiving 
binaries from suppliers.   Licensing probably doesn't care about 
versioning so long as a license is declared.  But cybersecurity cares.  
Is it a show stopper?  Not for a manufacturer because we can issue VEX 
statements.  But for Syft, it may be more problematic because Syft may 
not be in a position to create a VEX (I don't know).


Eliot

On 18.08.23 18:34, Keith Zantow via lists.spdx.org wrote:
We just had a talk about this yesterday due to a Syft issue that came 
in: https://github.com/anchore/syft/issues/2038 (from Emrick). 
Currently, we're thinking about excluding packages without name and 
version information, but the NOASSERTION idea is also something that 
seems to solve the problem fairly well.


I suppose I'm giving a plus-one on adding this as a specific value for 
the version when we cannot determine it, but also welcome thoughts on 
how best to handle this situation.


Cheers,
-Keith

On Fri, Aug 18, 2023 at 12:15 PM Brandon Lum via lists.spdx.org 
  wrote:


Hi,

In generating some of our SPDX documents, we've (Tyler/Emrick
CC'ed) run into situations where the version information of a
package is unknown. What comes to mind is to set the version to
NOASSERTION. However, this is not currently spelt out in the spec

(https://spdx.github.io/spdx-spec/v2.3/package-information/#73-package-version-field).


Although semantically, in terms of usage of information, it should
be similar, it still lacks the ability to say that "This
information is incomplete", with exception of having
NOASSERTION be set on the DEPENDS_ON relationship more broadly -
which may perhaps be a different discussion altogether.

Wanted to get thoughts on this.

Cheers
Brandon





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5309): https://lists.spdx.org/g/Spdx-tech/message/5309
Mute This Topic: https://lists.spdx.org/mt/100823660/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Dick Brooks]

Please be aware that component version (Package Version) is a minimum element 
within the NTIA SBOM requirements.

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Zavras, Alexios  
Sent: Monday, August 21, 2023 6:05 AM
To: Gary O'Neall ; l...@google.com
Cc: d...@reliableenergyanalytics.com; 'SPDX Technical Mailing List' 
; 'Emrick Donadei' ; 'Tyler 
Pirtle' 
Subject: RE: [spdx-tech] NOASSERTION on PackageVersion field

 

In both SPDXv2 (which the initial email pointed to) and SPDXv3, the license 
version information is optional.

Therefore, when someone does not know a package version, the property/field can 
be omitted.

 

What would the meaning of “NOASSERTION” be? In other words, what is the “known 
unknown” case that Gary speaks about?

I should point that in current SPDXv2, in similar fields like concludedLicense, 
we already have that “If the field is not present in a package, it implies an 
equivalent meaning to NOASSERTION ”

 

 

Regardless of this, I hope that we all agree that having a value of NOASSERTION 
as packageVersion means that the SBOM including this does NOT meet NTIA’s 
minimum requirements.

 

 

-- zvr 

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of Gary 
O'Neall
Sent: Saturday, 19 August, 2023 00:34
To: l...@google.com <mailto:l...@google.com> 
Cc: d...@reliableenergyanalytics.com <mailto:d...@reliableenergyanalytics.com> 
; 'SPDX Technical Mailing List' mailto:Spdx-tech@lists.spdx.org> >; 'Emrick Donadei' mailto:edona...@google.com> >; 'Tyler Pirtle' mailto:r...@google.com> >
Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field

 

My initial thought is that NOASSERTION should only be applicable to certain 
fields where a “known unknown” assertion is valuable.

 

In the RDF / OWL / semantic web SPDX spec., we would add a NOASSERTION value in 
the range of possible values for that property.  This would allow computer 
semantic reasoning to answer questions like “what packages in this distribution 
have ‘known unknown’ version?”.

 

The downside is that we would need to do more updates to the spec. 

 

Best,
Gary

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of 
Brandon Lum via lists.spdx.org
Sent: Friday, August 18, 2023 10:38 AM
To: Gary O'Neall mailto:g...@sourceauditor.com> >
Cc: d...@reliableenergyanalytics.com <mailto:d...@reliableenergyanalytics.com> 
; SPDX Technical Mailing List mailto:Spdx-tech@lists.spdx.org> >; Emrick Donadei mailto:edona...@google.com> >; Tyler Pirtle mailto:r...@google.com> >
Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field

 

I think one follow-up question is around whether it is recognized in the 
specification.. For example, package supplier 
(https://spdx.github.io/spdx-spec/v2.3/package-information/#75-package-supplier-field)
 it is stated clearly that NOASSERTION is within the format, but not in the 
case of VersionInfo

 

I think the question is NOASSERTION usable in any text field? Or does there 
need to be explicit indication within the spec where a NOASSERTION can be used?

 

On Fri, Aug 18, 2023 at 1:22 PM Gary O'Neall mailto:g...@sourceauditor.com> > wrote:

My opinion is that it would be useful to be able to express a “known unknown” 
on the version if the version can’t be determined.

 

I also agree we should strive to always have a version available.  This is 
especially important in tracking vulnerability information.  I just know that 
there are several situations where this just isn’t possible (e.g. source files 
copied from an upstream project where no one kept track of the original 
version).  It would be better to have the imperfect package information than no 
information at all.

 

The NOASSERTION approach seems like a consistent way to represent the “known 
unknown”.

 

Gary

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of Dick 
Brooks
Sent: Friday, August 18, 2023 9:53 AM
To: l...@google.com <mailto:l...@google.com> ; 'SPDX Technical Mailing List' 
mailto:Spdx-tech@lists.spdx.org> >
Cc: 'Emrick Donadei' mailto:edona...@google.com> >; 
'Tyler Pirtle' mailto:r...@google.com> >
Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field

 

Brandon,

 

REA applies the NOASSERTION value when a PackageVersion is indeterminant, based 
on guidanc

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Alexios Zavras]

In both SPDXv2 (which the initial email pointed to) and SPDXv3, the license 
version information is optional.
Therefore, when someone does not know a package version, the property/field can 
be omitted.

What would the meaning of “NOASSERTION” be? In other words, what is the “known 
unknown” case that Gary speaks about?
I should point that in current SPDXv2, in similar fields like concludedLicense, 
we already have that “If the field is not present in a package, it implies an 
equivalent meaning to NOASSERTION ”


Regardless of this, I hope that we all agree that having a value of NOASSERTION 
as packageVersion means that the SBOM including this does NOT meet NTIA’s 
minimum requirements.


-- zvr

From: Spdx-tech@lists.spdx.org  On Behalf Of Gary 
O'Neall
Sent: Saturday, 19 August, 2023 00:34
To: l...@google.com
Cc: d...@reliableenergyanalytics.com; 'SPDX Technical Mailing List' 
; 'Emrick Donadei' ; 'Tyler 
Pirtle' 
Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field

My initial thought is that NOASSERTION should only be applicable to certain 
fields where a “known unknown” assertion is valuable.

In the RDF / OWL / semantic web SPDX spec., we would add a NOASSERTION value in 
the range of possible values for that property.  This would allow computer 
semantic reasoning to answer questions like “what packages in this distribution 
have ‘known unknown’ version?”.

The downside is that we would need to do more updates to the spec.

Best,
Gary

From: Spdx-tech@lists.spdx.org<mailto:Spdx-tech@lists.spdx.org> 
mailto:Spdx-tech@lists.spdx.org>> On Behalf Of 
Brandon Lum via lists.spdx.org
Sent: Friday, August 18, 2023 10:38 AM
To: Gary O'Neall mailto:g...@sourceauditor.com>>
Cc: d...@reliableenergyanalytics.com<mailto:d...@reliableenergyanalytics.com>; 
SPDX Technical Mailing List 
mailto:Spdx-tech@lists.spdx.org>>; Emrick Donadei 
mailto:edona...@google.com>>; Tyler Pirtle 
mailto:r...@google.com>>
Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field

I think one follow-up question is around whether it is recognized in the 
specification.. For example, package supplier 
(https://spdx.github.io/spdx-spec/v2.3/package-information/#75-package-supplier-field)
 it is stated clearly that NOASSERTION is within the format, but not in the 
case of VersionInfo

I think the question is NOASSERTION usable in any text field? Or does there 
need to be explicit indication within the spec where a NOASSERTION can be used?

On Fri, Aug 18, 2023 at 1:22 PM Gary O'Neall 
mailto:g...@sourceauditor.com>> wrote:
My opinion is that it would be useful to be able to express a “known unknown” 
on the version if the version can’t be determined.

I also agree we should strive to always have a version available.  This is 
especially important in tracking vulnerability information.  I just know that 
there are several situations where this just isn’t possible (e.g. source files 
copied from an upstream project where no one kept track of the original 
version).  It would be better to have the imperfect package information than no 
information at all.

The NOASSERTION approach seems like a consistent way to represent the “known 
unknown”.

Gary

From: Spdx-tech@lists.spdx.org<mailto:Spdx-tech@lists.spdx.org> 
mailto:Spdx-tech@lists.spdx.org>> On Behalf Of Dick 
Brooks
Sent: Friday, August 18, 2023 9:53 AM
To: l...@google.com<mailto:l...@google.com>; 'SPDX Technical Mailing List' 
mailto:Spdx-tech@lists.spdx.org>>
Cc: 'Emrick Donadei' mailto:edona...@google.com>>; 'Tyler 
Pirtle' mailto:r...@google.com>>
Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field

Brandon,

REA applies the NOASSERTION value when a PackageVersion is indeterminant, based 
on guidance provided by the NTIA work effort.

This is not an issue with “file components” as no version is required.



Thanks,

Dick Brooks
[cid:image001.png@01D9D42E.B1B31CF0]  [cid:image002.png@01D9D42E.B1B31CF0]
Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council – A Public-Private Partnership

Never trust software, always verify and 
report!<https://reliableenergyanalytics.com/products> ™
http://www.reliableenergyanalytics.com<http://www.reliableenergyanalytics.com/>
Email: d...@reliableenergyanalytics.com<mailto:d...@reliableenergyanalytics.com>
Tel: +1 978-696-1788


From: Spdx-tech@lists.spdx.org<mailto:Spdx-tech@lists.spdx.org> 
mailto:Spdx-tech@lists.spdx.org>> On Behalf Of 
Brandon Lum via lists.spdx.org<http://lists.spdx.org>
Sent: Friday, August 18, 2023 12:16 PM
To: SPDX Technical Mailing List 
mailto:Spdx-tech@lists.spdx.org>>
Cc: Emrick Donadei mailto:edona...@google.com>>; Tyler 
Pirtle mailto:r...@google.com>>
Subject: [spdx-tech] NOASSERTION on PackageVersion field

Hi,

In generating some of our SPDX documents, we've (Tyler/Emrick CC'ed) run into 
situations where the version informatio

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Gary O'Neall]

My initial thought is that NOASSERTION should only be applicable to certain 
fields where a “known unknown” assertion is valuable.

 

In the RDF / OWL / semantic web SPDX spec., we would add a NOASSERTION value in 
the range of possible values for that property.  This would allow computer 
semantic reasoning to answer questions like “what packages in this distribution 
have ‘known unknown’ version?”.

 

The downside is that we would need to do more updates to the spec. 

 

Best,
Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Brandon 
Lum via lists.spdx.org
Sent: Friday, August 18, 2023 10:38 AM
To: Gary O'Neall 
Cc: d...@reliableenergyanalytics.com; SPDX Technical Mailing List 
; Emrick Donadei ; Tyler Pirtle 

Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field

 

I think one follow-up question is around whether it is recognized in the 
specification.. For example, package supplier 
(https://spdx.github.io/spdx-spec/v2.3/package-information/#75-package-supplier-field)
 it is stated clearly that NOASSERTION is within the format, but not in the 
case of VersionInfo

 

I think the question is NOASSERTION usable in any text field? Or does there 
need to be explicit indication within the spec where a NOASSERTION can be used?

 

On Fri, Aug 18, 2023 at 1:22 PM Gary O'Neall mailto:g...@sourceauditor.com> > wrote:

My opinion is that it would be useful to be able to express a “known unknown” 
on the version if the version can’t be determined.

 

I also agree we should strive to always have a version available.  This is 
especially important in tracking vulnerability information.  I just know that 
there are several situations where this just isn’t possible (e.g. source files 
copied from an upstream project where no one kept track of the original 
version).  It would be better to have the imperfect package information than no 
information at all.

 

The NOASSERTION approach seems like a consistent way to represent the “known 
unknown”.

 

Gary

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of Dick 
Brooks
Sent: Friday, August 18, 2023 9:53 AM
To: l...@google.com <mailto:l...@google.com> ; 'SPDX Technical Mailing List' 
mailto:Spdx-tech@lists.spdx.org> >
Cc: 'Emrick Donadei' mailto:edona...@google.com> >; 
'Tyler Pirtle' mailto:r...@google.com> >
Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field

 

Brandon,

 

REA applies the NOASSERTION value when a PackageVersion is indeterminant, based 
on guidance provided by the NTIA work effort.

 

This is not an issue with “file components” as no version is required.

 

 

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788  

 

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of 
Brandon Lum via lists.spdx.org <http://lists.spdx.org> 
Sent: Friday, August 18, 2023 12:16 PM
To: SPDX Technical Mailing List mailto:Spdx-tech@lists.spdx.org> >
Cc: Emrick Donadei mailto:edona...@google.com> >; Tyler 
Pirtle mailto:r...@google.com> >
Subject: [spdx-tech] NOASSERTION on PackageVersion field

 

Hi,

 

In generating some of our SPDX documents, we've (Tyler/Emrick CC'ed) run into 
situations where the version information of a package is unknown. What comes to 
mind is to set the version to NOASSERTION. However, this is not currently spelt 
out in the spec 
(https://spdx.github.io/spdx-spec/v2.3/package-information/#73-package-version-field).
 

 

Although semantically, in terms of usage of information, it should be similar, 
it still lacks the ability to say that "This information is incomplete", with 
exception of having NOASSERTION be set on the DEPENDS_ON relationship more 
broadly - which may perhaps be a different discussion altogether. 

 

Wanted to get thoughts on this.

 

Cheers

Brandon





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5305): https://lists.spdx.org/g/Spdx-tech/message/5305
Mute This Topic: https://lists.spdx.org/mt/100823660/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Brandon Lum via lists.spdx.org]

I think one follow-up question is around whether it is recognized in the
specification.. For example, package supplier (
https://spdx.github.io/spdx-spec/v2.3/package-information/#75-package-supplier-field)
it is stated clearly that NOASSERTION is within the format, but not in the
case of VersionInfo

I think the question is NOASSERTION usable in any text field? Or does there
need to be explicit indication within the spec where a NOASSERTION can be
used?

On Fri, Aug 18, 2023 at 1:22 PM Gary O'Neall  wrote:

> My opinion is that it would be useful to be able to express a “known
> unknown” on the version if the version can’t be determined.
>
>
>
> I also agree we should strive to always have a version available.  This is
> especially important in tracking vulnerability information.  I just know
> that there are several situations where this just isn’t possible (e.g.
> source files copied from an upstream project where no one kept track of the
> original version).  It would be better to have the imperfect package
> information than no information at all.
>
>
>
> The NOASSERTION approach seems like a consistent way to represent the
> “known unknown”.
>
>
>
> Gary
>
>
>
> *From:* Spdx-tech@lists.spdx.org  *On Behalf Of
> *Dick Brooks
> *Sent:* Friday, August 18, 2023 9:53 AM
> *To:* l...@google.com; 'SPDX Technical Mailing List' <
> Spdx-tech@lists.spdx.org>
> *Cc:* 'Emrick Donadei' ; 'Tyler Pirtle' <
> r...@google.com>
> *Subject:* Re: [spdx-tech] NOASSERTION on PackageVersion field
>
>
>
> Brandon,
>
>
>
> REA applies the NOASSERTION value when a PackageVersion is indeterminant,
> based on guidance provided by the NTIA work effort.
>
>
>
> This is not an issue with “file components” as no version is required.
>
>
>
>
>
>
>
> 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!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: d...@reliableenergyanalytics.com
>
> Tel: +1 978-696-1788 <(978)%20696-1788>
>
>
>
>
>
> *From:* Spdx-tech@lists.spdx.org  *On Behalf Of
> *Brandon Lum via lists.spdx.org
> *Sent:* Friday, August 18, 2023 12:16 PM
> *To:* SPDX Technical Mailing List 
> *Cc:* Emrick Donadei ; Tyler Pirtle 
> *Subject:* [spdx-tech] NOASSERTION on PackageVersion field
>
>
>
> Hi,
>
>
>
> In generating some of our SPDX documents, we've (Tyler/Emrick CC'ed) run
> into situations where the version information of a package is unknown. What
> comes to mind is to set the version to NOASSERTION. However, this is not
> currently spelt out in the spec (
> https://spdx.github.io/spdx-spec/v2.3/package-information/#73-package-version-field
> ).
>
>
>
> Although semantically, in terms of usage of information, it should be
> similar, it still lacks the ability to say that "This information is
> incomplete", with exception of having NOASSERTION be set on the DEPENDS_ON
> relationship more broadly - which may perhaps be a different discussion
> altogether.
>
>
>
> Wanted to get thoughts on this.
>
>
>
> Cheers
>
> Brandon
>
> 
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5304): https://lists.spdx.org/g/Spdx-tech/message/5304
Mute This Topic: https://lists.spdx.org/mt/100823660/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Gary O'Neall]

My opinion is that it would be useful to be able to express a “known unknown” 
on the version if the version can’t be determined.

 

I also agree we should strive to always have a version available.  This is 
especially important in tracking vulnerability information.  I just know that 
there are several situations where this just isn’t possible (e.g. source files 
copied from an upstream project where no one kept track of the original 
version).  It would be better to have the imperfect package information than no 
information at all.

 

The NOASSERTION approach seems like a consistent way to represent the “known 
unknown”.

 

Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Dick 
Brooks
Sent: Friday, August 18, 2023 9:53 AM
To: l...@google.com; 'SPDX Technical Mailing List' 
Cc: 'Emrick Donadei' ; 'Tyler Pirtle' 
Subject: Re: [spdx-tech] NOASSERTION on PackageVersion field

 

Brandon,

 

REA applies the NOASSERTION value when a PackageVersion is indeterminant, based 
on guidance provided by the NTIA work effort.

 

This is not an issue with “file components” as no version is required.

 

 

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:d...@reliableenergyanalytics.com> 
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org>  
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of 
Brandon Lum via lists.spdx.org
Sent: Friday, August 18, 2023 12:16 PM
To: SPDX Technical Mailing List mailto:Spdx-tech@lists.spdx.org> >
Cc: Emrick Donadei mailto:edona...@google.com> >; Tyler 
Pirtle mailto:r...@google.com> >
Subject: [spdx-tech] NOASSERTION on PackageVersion field

 

Hi,

 

In generating some of our SPDX documents, we've (Tyler/Emrick CC'ed) run into 
situations where the version information of a package is unknown. What comes to 
mind is to set the version to NOASSERTION. However, this is not currently spelt 
out in the spec 
(https://spdx.github.io/spdx-spec/v2.3/package-information/#73-package-version-field).
 

 

Although semantically, in terms of usage of information, it should be similar, 
it still lacks the ability to say that "This information is incomplete", with 
exception of having NOASSERTION be set on the DEPENDS_ON relationship more 
broadly - which may perhaps be a different discussion altogether. 

 

Wanted to get thoughts on this.

 

Cheers

Brandon





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5303): https://lists.spdx.org/g/Spdx-tech/message/5303
Mute This Topic: https://lists.spdx.org/mt/100823660/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Dick Brooks]

Brandon,

 

REA applies the NOASSERTION value when a PackageVersion is indeterminant, based 
on guidance provided by the NTIA work effort.

 

This is not an issue with “file components” as no version is required.

 

 

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:   
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Brandon 
Lum via lists.spdx.org
Sent: Friday, August 18, 2023 12:16 PM
To: SPDX Technical Mailing List 
Cc: Emrick Donadei ; Tyler Pirtle 
Subject: [spdx-tech] NOASSERTION on PackageVersion field

 

Hi,

 

In generating some of our SPDX documents, we've (Tyler/Emrick CC'ed) run into 
situations where the version information of a package is unknown. What comes to 
mind is to set the version to NOASSERTION. However, this is not currently spelt 
out in the spec 
(https://spdx.github.io/spdx-spec/v2.3/package-information/#73-package-version-field).
 

 

Although semantically, in terms of usage of information, it should be similar, 
it still lacks the ability to say that "This information is incomplete", with 
exception of having NOASSERTION be set on the DEPENDS_ON relationship more 
broadly - which may perhaps be a different discussion altogether. 

 

Wanted to get thoughts on this.

 

Cheers

Brandon





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5302): https://lists.spdx.org/g/Spdx-tech/message/5302
Mute This Topic: https://lists.spdx.org/mt/100823660/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Anthony Harrison]

I think using a package where you can't determine the version is a very bad
idea. So adding NOASSERTION is sending a message that determining the
version isn't that important. It is very important!

Whilst I appreciate that it maybe difficult in some cases to find all the
details required for a package, I think we need to encourage behaviour
where we expect the metadata for a package to be complete.

Just my opinion...

Anthony

On Fri, 18 Aug 2023, 17:34 Keith Zantow via lists.spdx.org,  wrote:

> We just had a talk about this yesterday due to a Syft issue that came in:
> https://github.com/anchore/syft/issues/2038 (from Emrick). Currently,
> we're thinking about excluding packages without name and version
> information, but the NOASSERTION idea is also something that seems to solve
> the problem fairly well.
>
> I suppose I'm giving a plus-one on adding this as a specific value for the
> version when we cannot determine it, but also welcome thoughts on how best
> to handle this situation.
>
> Cheers,
> -Keith
>
> On Fri, Aug 18, 2023 at 12:15 PM Brandon Lum via lists.spdx.org  google@lists.spdx.org> wrote:
>
>> Hi,
>>
>> In generating some of our SPDX documents, we've (Tyler/Emrick CC'ed) run
>> into situations where the version information of a package is unknown. What
>> comes to mind is to set the version to NOASSERTION. However, this is not
>> currently spelt out in the spec (
>> https://spdx.github.io/spdx-spec/v2.3/package-information/#73-package-version-field
>> ).
>>
>> Although semantically, in terms of usage of information, it should be
>> similar, it still lacks the ability to say that "This information is
>> incomplete", with exception of having NOASSERTION be set on the DEPENDS_ON
>> relationship more broadly - which may perhaps be a different discussion
>> altogether.
>>
>> Wanted to get thoughts on this.
>>
>> Cheers
>> Brandon
>>
>> 
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5301): https://lists.spdx.org/g/Spdx-tech/message/5301
Mute This Topic: https://lists.spdx.org/mt/100823660/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] NOASSERTION on PackageVersion field

[Keith Zantow via lists.spdx.org]

We just had a talk about this yesterday due to a Syft issue that came in:
https://github.com/anchore/syft/issues/2038 (from Emrick). Currently, we're
thinking about excluding packages without name and version information, but
the NOASSERTION idea is also something that seems to solve the problem
fairly well.

I suppose I'm giving a plus-one on adding this as a specific value for the
version when we cannot determine it, but also welcome thoughts on how best
to handle this situation.

Cheers,
-Keith

On Fri, Aug 18, 2023 at 12:15 PM Brandon Lum via lists.spdx.org  wrote:

> Hi,
>
> In generating some of our SPDX documents, we've (Tyler/Emrick CC'ed) run
> into situations where the version information of a package is unknown. What
> comes to mind is to set the version to NOASSERTION. However, this is not
> currently spelt out in the spec (
> https://spdx.github.io/spdx-spec/v2.3/package-information/#73-package-version-field
> ).
>
> Although semantically, in terms of usage of information, it should be
> similar, it still lacks the ability to say that "This information is
> incomplete", with exception of having NOASSERTION be set on the DEPENDS_ON
> relationship more broadly - which may perhaps be a different discussion
> altogether.
>
> Wanted to get thoughts on this.
>
> Cheers
> Brandon
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5300): https://lists.spdx.org/g/Spdx-tech/message/5300
Mute This Topic: https://lists.spdx.org/mt/100823660/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Thoughts on the issues of NamespaceMap and SpdxDocument

[Gary O'Neall]

.org  On Behalf Of David 
Kemp
Sent: Thursday, August 17, 2023 12:15 PM
To: spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] Thoughts on the issues of NamespaceMap and SpdxDocument

 

The net-net of my thoughts on these matters is the following:

*   The current SpdxDocument class should be removed from the model

 

+1 to Gary's proposal to defer naming the class currently called SpdxDocument.
 

*   Bills of material should be represented with Bom (or its subclasses) 
instances

 

Definitely, and other element collections such as Bundle are subclasses of 
ElementCollection

*   Metadata for specific serialization instances should be represented 
with File class instances


Name not chosen yet.
 

*   A new special direct subclass of ElementCollection should be defined (a 
couple of name suggestions above but not "SpdxDocument") to be an "outer layer" 
collection enforced with a constraint on the 'element' property of 
ElementCollection that it cannot contain this new "outer layer" type of 
collection thus preventing layering


Definitely not.  A pile (rhymes with "file") of serialized element values is 
not an ElementCollection, nor is the unnamed "X" element that describes it.  A 
set of elements can be parsed from one, two, or more serialized piles; there is 
no association of a single element to a particular pile in the model.  A single 
element can be in and be parsed from many piles, which can have the same or 
different data formats.

*   The NamespaceMap should be placed on the new "outer layer" type of 
collection class thus avoiding the potential conflicts and complexities of 
prefix layering


A NamespaceMap exists in the pile to enable compact serialized data to 
reconstruct full element instances. An "X" element class does not need to exist 
at all to parse a pile into full element instances.  If an X element does 
exist, its namespace map has nothing to do with element instances, only how 
much compaction is applied to other piles - a given SpdxId instance is 
serialized into: full IRI, short namespace + long local id, or long namespace + 
short local id.

*   NamespaceMap does not exist at all in element instances (the logical 
model).
*   I agree with Max's proposal that a consumer can create an "X" element 
for a particular pile that it parses some elements from. The consumer can then 
include that "X" element in piles that it produces, to allow external 
references from the produced pile to the consumed pile.
*   There is no such thing as "external" in the element graph; an instance 
with an id exists or it doesn't.  "External" is a concept that applies only to 
serialized data piles, it doesn't exist in the logical model
*   The use case of Payload A -> Logical Element Store -> Payload A` where 
A is destroyed but A' must use the same namespace map as A would require that 
namespace map be included in an element.  But I question the validity of 
requiring that Payload A be destroyed. If that were true, source integrity from 
the Producer of all elements in A would be lost.  Not to mention that it's as 
illogical as saying that a File element must be able to reconstruct the 
original content in file A' from the element store if original file A is 
destroyed.

 

On Thu, Aug 17, 2023 at 10:45 AM Sean Barnum mailto:sbar...@mitre.org> > wrote:

All,

 

After our discussions around NamespaceMap and SpdxDocument in our Aug 8th tech 
meeting I put a little more thought into these challenges. I recognize the 
implementation complexities around prefix layering that Gary and others were 
expressing deep concern with and respect their perspective. Given these 
expressed concerns but still remaining issues in the current approach, after 
some further thought I believe I have a compromise to propose that seems to 
address all of these issues cleanly.

 

Summarization of my thoughts are:

 

*   There have been previous discussions that putting NamespaceMap on 
ElementCollection gets very complicated because collections can contain 
collections (to an undefined depth) and there is a potential for prefix 
conflict. I would concur that this is a challenge of significant complexity to 
fully address.
*   There is existing confusion even from people in the tech working group 
on the relationship/difference between SpdxDocument and Bom. This includes 
questions on whether SpdxDocument is needed in the model. It was conveyed on 
the call that the purpose of SpdxDocument was to convey metadata for a specific 
serialization instance of SPDX content.
*   Having SpdxDocument in the model if it is intended to convey metadata 
for a specific serialization instance creates a messy situation as it conflates 
the model with specific serialization which is a separation that is very 
important to maintain for simplicity, flexibility, consi

Re: [spdx-tech] Thoughts on the issues of NamespaceMap and SpdxDocument

[David Kemp]

>
> The net-net of my thoughts on these matters is the following:
>
>- The current SpdxDocument class should be removed from the model
>
>
+1 to Gary's proposal to defer naming the class currently called
SpdxDocument.


>
>- Bills of material should be represented with Bom (or its subclasses)
>instances
>
>
Definitely, and other element collections such as Bundle are subclasses of
ElementCollection


>- Metadata for specific serialization instances should be represented
>with File class instances
>
>
Name not chosen yet.


>
>- A new special direct subclass of ElementCollection should be defined
>(a couple of name suggestions above but not "SpdxDocument") to be an "outer
>layer" collection enforced with a constraint on the 'element' property of
>ElementCollection that it cannot contain this new "outer layer" type of
>collection thus preventing layering
>
>
Definitely not.  A pile (rhymes with "file") of serialized element values
is not an ElementCollection, nor is the unnamed "X" element that describes
it.  A set of elements can be parsed from one, two, or more serialized
piles; there is no association of a single element to a particular pile in
the model.  A single element can be in and be parsed from many piles, which
can have the same or different data formats.


>- The NamespaceMap should be placed on the new "outer layer" type of
>collection class thus avoiding the potential conflicts and complexities of
>prefix layering
>
>
A NamespaceMap exists in the pile to enable compact serialized data to
reconstruct full element instances. An "X" element class does not need to
exist at all to parse a pile into full element instances.  If an X element
does exist, its namespace map has nothing to do with element instances,
only how much compaction is applied to other piles - a given SpdxId
instance is serialized into: full IRI, short namespace + long local id, or
long namespace + short local id.

   - NamespaceMap does not exist at all in element instances (the logical
   model).
   - I agree with Max's proposal that a consumer can create an "X" element
   for a particular pile that it parses some elements from. The consumer can
   then include that "X" element in piles that it produces, to allow external
   references from the produced pile to the consumed pile.
   - There is no such thing as "external" in the element graph; an instance
   with an id exists or it doesn't.  "External" is a concept that applies only
   to serialized data piles, it doesn't exist in the logical model
   - The use case of Payload A -> Logical Element Store -> Payload A` where
   A is destroyed but A' must use the same namespace map as A would require
   that namespace map be included in an element.  But I question the validity
   of requiring that Payload A be destroyed. If that were true, source
   integrity from the Producer of all elements in A would be lost.  Not to
   mention that it's as illogical as saying that a File element must be able
   to reconstruct the original content in file A' from the element store if
   original file A is destroyed.


On Thu, Aug 17, 2023 at 10:45 AM Sean Barnum  wrote:

> All,
>
>
>
> After our discussions around NamespaceMap and SpdxDocument in our Aug 8th
> tech meeting I put a little more thought into these challenges. I recognize
> the implementation complexities around prefix layering that Gary and others
> were expressing deep concern with and respect their perspective. Given
> these expressed concerns but still remaining issues in the current
> approach, after some further thought I believe I have a compromise to
> propose that seems to address all of these issues cleanly.
>
>
>
> Summarization of my thoughts are:
>
>
>
>- There have been previous discussions that putting NamespaceMap on
>ElementCollection gets very complicated because collections can contain
>collections (to an undefined depth) and there is a potential for prefix
>conflict. I would concur that this is a challenge of significant complexity
>to fully address.
>- There is existing confusion even from people in the tech working
>group on the relationship/difference between SpdxDocument and Bom. This
>includes questions on whether SpdxDocument is needed in the model. It was
>conveyed on the call that the purpose of SpdxDocument was to convey
>metadata for a specific serialization instance of SPDX content.
>- Having SpdxDocument in the model if it is intended to convey
>metadata for a specific serialization instance creates a messy situation as
>it conflates the model with specific serialization which is a separation
>that is very important to maintain for simplicity, flexibility,
>consistency, etc.
>   - Details about how to serialize and specific instances of
>   serialization should be specified and managed outside of the model.
>   - If we want to convey verifiedUsing details of a specific instance
>  

Re: [spdx-tech] Thoughts on the issues of NamespaceMap and SpdxDocument

[Brandon Lum via lists.spdx.org]

I haven't been able to catch up too closely with the discussions - (but am
going to start doing that now). I do find the ability to not have a
canonical representation of each element within the specification of the
graph difficult for parsing, ideally the SPDX ID namespace mapping would be
available during the first round of parsing. I do see the ease of this
format where you could easily combine multiple documents into one, but we'd
run into ID collisions in this case where we can't disambiguate between two
IDs referenced from different SPDXDocuments.

Elements in SPDXDocument feels like a special case, which I think would be
nice to be able to have easily retrievable at the start, and rootElements
seems like a relationship as well (feels like the shortcut fields again)...

I look forward to being corrected though :).

On Thu, Aug 17, 2023 at 10:45 AM Sean Barnum  wrote:

> All,
>
>
>
> After our discussions around NamespaceMap and SpdxDocument in our Aug 8th
> tech meeting I put a little more thought into these challenges. I recognize
> the implementation complexities around prefix layering that Gary and others
> were expressing deep concern with and respect their perspective. Given
> these expressed concerns but still remaining issues in the current
> approach, after some further thought I believe I have a compromise to
> propose that seems to address all of these issues cleanly.
>
>
>
> Summarization of my thoughts are:
>
>
>
>- There have been previous discussions that putting NamespaceMap on
>ElementCollection gets very complicated because collections can contain
>collections (to an undefined depth) and there is a potential for prefix
>conflict. I would concur that this is a challenge of significant complexity
>to fully address.
>- There is existing confusion even from people in the tech working
>group on the relationship/difference between SpdxDocument and Bom. This
>includes questions on whether SpdxDocument is needed in the model. It was
>conveyed on the call that the purpose of SpdxDocument was to convey
>metadata for a specific serialization instance of SPDX content.
>- Having SpdxDocument in the model if it is intended to convey
>metadata for a specific serialization instance creates a messy situation as
>it conflates the model with specific serialization which is a separation
>that is very important to maintain for simplicity, flexibility,
>consistency, etc.
>   - Details about how to serialize and specific instances of
>   serialization should be specified and managed outside of the model.
>   - If we want to convey verifiedUsing details of a specific instance
>   of serialization then we should use a File Element to represent the
>   serialized file and assert the verifiedUsing details on it. We could 
> also
>   then relate that File to the content Elements it contains (hopefully
>   typically a single wrapping collection) with a "contains" Relationship.
>   This is an appropriate way to handle metadata for a specific 
> serialization
>   instance and not confuse the model.
>   - There are cases where instances of serialization may not involve
>   a file and this would call for the need for a ContentData (chunk-o-bits)
>   Element which we have in prior discussions scoped to after 3.0 so for 
> 3.0
>   instances of serialization would only be Files.
>- To simplify a solution for NamespaceMap in layered collections it
>does make sense to specify a special subclass (directly) of
>ElementCollection that is intended to be a collection that no other
>collection can reference as an Element (thus preventing layering). This
>special subclass should not be thought of as specific to serialization but
>rather just a special kind of collection in the model. This layer
>prevention would need explicit assertion in the RDFS/OWL and in the SHACL
>such that the range of the 'element' property on ElementCollection would be
>Element but NOT the outer-shell collection. I would propose not using
>"SpdxDocument" as the name of this class as it has a lot of history and
>would have the potential for a lot of confusion. We should choose another
>name for this class that conveys that it is an outer-shell-only collection
>and namespaceMap can be a property on it. We could go with something simple
>like "EnclosingCollection" though that name does not inherently convey lack
>of layering. Another more esoteric but explicit possibility could be to
>maybe borrow from chemistry and we could call it "ValenceShellCollection"
>given the universal usage of the term 'valence shell' to be the outermost
>layer of electrons in any atomic element and the layer that reacts with
>content outside the atom. This seems pretty close to what we are trying to
>convey.
>
>
>
> The net-net of my thoughts on these matters is the following:
>
>- The 

Re: [spdx-tech] Tomorrow's serialization meeting

[Nisha Kumar]

I'm ok with skipping this meeting.

nisha

On 8/2/23 21:06, Gary O'Neall wrote:


In looking at my calendar, I just realized our regularly scheduled 
serialization meeting this week conflicts with the monthly SPDX 
general meeting.


I would suggest we skip tomorrow’s meeting – there’s also a few folks 
on vacation this week as well.


I’m also open to rescheduling to Friday if there is enough interest.

Best,

Gary





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5283): https://lists.spdx.org/g/Spdx-tech/message/5283
Mute This Topic: https://lists.spdx.org/mt/100520286/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] Discussing Change Proposal regarding DataLicense / CC0-1.0

[Steve Winslow]

Hello spdx-legal / spdx-tech,

The minutes from the joint discussion last week about the Change Proposal 
regarding DataLicense and CC0-1.0 can be found at [1].

Briefly, there was significant agreement from the meeting attendees that the 
present requirement (from SPDX 2.3 and earlier) to mandate a DataLicense of 
CC0-1.0 should be changed for SPDX 3.0. In a straw poll at the end of the 
meeting, no attendees expressed interest in keeping this requirement as-is.

The attendees were generally split across two possible alternatives:

1) Keep the DataLicense field, but permit it to contain any valid SPDX 
license expression
2) Get rid of the DataLicense field altogether

The original Change Proposal [2] was focused on option #1, but option #2 was 
raised during the meeting and had significant support from several of the 
attendees as well.

I’d encourage those of you with a view on this and a preference for one option 
over the other to share your thoughts, preferably in the Change Proposal thread 
at [2]. I’d strongly encourage that anyone who does so should read through the 
meeting minutes at [1] if they weren’t in the meeting, in order to get the 
context for the discussion that occurred.

If a consensus emerges for the preferred path forward through follow-ups in the 
Change Proposal thread, then we may move forward with that option. If not, then 
we may schedule a subsequent joint meeting to try to resolve this in the coming 
weeks.

Steve

[1] https://github.com/spdx/meetings/blob/main/legal/2023-07-27.md
[2] https://github.com/spdx/change-proposal/issues/8


> On Jul 26, 2023, at 7:19 PM, J Lovejoy  wrote:
> 
> Just want to reiterate that we have an SPDX-legal call tomorrow and will be 
> discussion the Change Proposal related to data license. Please see Steve's 
> summary below and associated links and come prepared!
> 
> Thanks,
> Jilayne
> 
> On 7/14/23 12:16 PM, Steve Winslow wrote:
>> Hello spdx-legal and spdx-tech teams,
>> 
>> As you may be aware, all SPDX specification versions since 1.1 have required 
>> that SPDX documents have a “DataLicense” value of CC0-1.0. Details about 
>> this in the latest-released spec are available at [1] and additional 
>> background about the SPDX community’s past decisions is available at [2].
>> 
>> Ria Schalnat has put together a draft Change Proposal at [3] proposing that 
>> future versions of the SPDX specification remove the requirement that SPDX 
>> documents and data be licensed under CC0-1.0. Further discussion and a 
>> variety of opinions are available in the discussion thread in that issue.
>> 
>> To move the discussion forward, we would like to invite interested 
>> participants from the SPDX legal team and tech team communities to discuss 
>> this Change Proposal at the next regularly scheduled Legal Team call, on 
>> Thursday, July 27th, at 12:00 noon Eastern US time. Meeting information is 
>> available at [4].
>> 
>> For anyone who plans to attend and participate in the discussion, I would 
>> ask that you please read [1], [2] and [3] prior to the call to familiarize 
>> yourself with the details of the present state and the proposed changes. 
>> Please also feel free to weigh in with your own thoughts in the thread at 
>> [3] prior to the meeting.
>> 
>> Best,
>> Steve
>> 
>> 
>> [1] 
>> https://spdx.github.io/spdx-spec/v2.3/document-creation-information/#62-data-license-field
>> [2] https://wiki.spdx.org/images/SPDX-TR-2014-1.v1.1.pdf
>> [3] https://github.com/spdx/change-proposal/issues/8
>> [4] https://github.com/spdx/meetings/tree/main#legal-team-meetings
>> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5282): https://lists.spdx.org/g/Spdx-tech/message/5282
Mute This Topic: https://lists.spdx.org/mt/100146787/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] FW: Some fodder for the discussion of blank nodes

[Kate Stewart]

Hi Sean & Bob,
 Your emails were making it through to the tech list.
see: https://lists.spdx.org/g/Spdx-tech/message/5277

To look and see the ones that have been posted this month
see:  https://lists.spdx.org/g/Spdx-tech/messages?start=8:2023:300

Thanks,
Kate

On Wed, Aug 2, 2023 at 2:51 PM Martin, Robert A  wrote:

> And this one also doesn't seem to have made it to the list.
>
> Bob
>
> *From: *Sean Barnum  
> *Date: *Tuesday, August 1, 2023 at 2:06 PM
> *To: *Spdx-tech@lists.spdx.org 
> 
> *Subject: *FW: Some fodder for the discussion of blank nodes
>
> I just noticed that this has still not shown up in my inbox though it
> looks like it made it out of my outbox.
>
> This is the email I was referring to during the call thinking that you all
> had it already.
>
> Sorry about that.
>
>
>
> Hopefully it makes it past the spdx list server this time.
>
>
>
> sean
>
>
>
> *From: *Sean Barnum  
> *Date: *Tuesday, August 1, 2023 at 11:50 AM
> *To: *Spdx-tech@lists.spdx.org 
> 
> *Subject: *Some fodder for the discussion of blank nodes
>
> All,
>
>
>
> I apologize for the lateness of this. I threw it together yesterday and
> sent it to the list but just noticed that it never left my outbox so I must
> have messed something up.
>
>
>
> This is a VERY simple overview of some of the aspects of blank nodes we
> should consider when discussing whether they should be used for SPDX 3.0
>
> It is VERY informal and quickly thrown together so please do not interpret
> it as anything too rigorous. Rather than me spending time writing up
> rigorous argumentation I instead took an approach of pulling together
> several reference links addressing various aspects and let those do the
> talking with only a simple summarization of the aspect issue from me.
>
>
>
>- Some VERY quick and short notes on the question of using blank nodes
>or not
>-
>- The below short outline includes several relevant links to resources
>on various aspects of this issue. All of these links were found within 20
>mins of very simple Google querying and all were within the first 5-10
>results for each Google query.
>-
>- There is broad consensus on the existence of significant issues and
>challenges with using blank nodes. 15-30 mins of googling will yield scores
>of papers, blog posts, articles, etc. calling out various reasons that
>blank nodes are problematic and should be avoided wherever possible in the
>large majority of situations. Defined semantics and specifications
>regarding Bnodes are inconsistent and contradictory leading to
>inconsistency between tools, ambiguity in how they will be processed,
>interpreted or queried.
>
>
>-
>   http://richard.cyganiak.de/blog/2011/03/blank-nodes-considered-harmful/
>   - https://aidanhogan.com/docs/blank_nodes_jws.pdf
>   - https://marceloarenas.cl/publications/iswc11.pdf
>   - https://terminusdb.com/blog/blank-nodes-in-rdf/
>   - https://terminusdb.com/blog/blank-nodes-in-rdf/
>
>
>1. When blank nodes are used it is typically for the convenience of
>   the producer but often comes at significant cost to the consumer in the
>   form of ambiguity, uncertainty, complexity, and resources (time and
>   computing resources)
>   2. *IF* they are decided to be used they are *ONLY* for a single
>   scope of a single datastore or single serialized document and *NOT*
>   for global or cross-scope use. This is explicitly stated in all of the 
> W3C
>   specs dealing with Bnodes. Using them for cross-scope use as SPDX 3.0 is
>   intended leads to significant potential data integrity issues.
>
>
>- https://www.w3.org/wiki/BlankNodes
>  - https://www.w3.org/TR/rdf11-concepts/#section-blank-nodes
>  - https://www.w3.org/TR/rdf-mt/#unlabel
>  - https://en.wikipedia.org/wiki/Blank_node
>
>
>1. Avoiding these significant potential issues typically requires
>   skolemization (replacing the localized ids with globally unique IRIs) of
>   the Bnodes. This extra effort is forced on the consumer and is often 
> done
>   by processors and graph stores as part of deserialization/ingestion.
>   However, due to the inconsistencies in the specs regarding Bnodes this 
> is
>   not consistent. Some processors and stores do not perform skolemization 
> an
>   simply utilize the localized Bnode ids (especially if they are producer
>   asserted in any way). This leads to significant integrity issues as 
> these
>   ids collide (simple example is even explicitly in some W3C docs/specs 
> and
>   on the Wikipedia page) and increases significantly with the volume of
>   cross-scope content ingested. Skolemization also does not provide any
>   id-related context for the source of the nodes such as that provided by
>   namespaces in producer specified IRIs.
>
>
>-
>  
> 

Re: [spdx-tech] FW: Some fodder for the discussion of blank nodes

[Martin, Robert A]

  
  
And this one also doesn't seem to have made it to the list.
Bob
   


  

  

  From:
  Sean Barnum 
  Date: Tuesday, August 1, 2023 at 2:06 PM
  To: Spdx-tech@lists.spdx.org
  
  Subject: FW: Some fodder for the discussion of
  blank nodes

I just noticed that this has
still not shown up in my inbox though it looks like it
made it out of my outbox.
This is the email I was referring
to during the call thinking that you all had it already.
Sorry about that.
 
Hopefully it makes it past the
spdx list server this time.
 
sean
 

  

  From:
  Sean Barnum
  
  Date: Tuesday, August 1, 2023 at 11:50 AM
  To: Spdx-tech@lists.spdx.org
  
  Subject: Some fodder for the discussion of
  blank nodes

All,
 
I apologize for the lateness
of this. I threw it together yesterday and sent it
to the list but just noticed that it never left my
outbox so I must have messed something up.
 
This is a VERY simple
overview of some of the aspects of blank nodes we
should consider when discussing whether they should
be used for SPDX 3.0
It is VERY informal and
quickly thrown together so please do not interpret
it as anything too rigorous. Rather than me spending
time writing up rigorous argumentation I instead
took an approach of pulling together several
reference links addressing various aspects and let
those do the talking with only a simple
summarization of the aspect issue from me.
  
 

  Some VERY quick and short
  notes on the question of using blank nodes or not
   
  The below short outline
  includes several relevant links to resources on
  various aspects of this issue. All of these links
  were found within 20 mins of very simple Google
  querying and all were within the first 5-10
  results for each Google query.
   
  There is broad consensus
  on the existence of significant issues and
  challenges with using blank nodes. 15-30 mins of
  googling will yield scores of papers, blog posts,
  articles, etc. calling out various reasons that
  blank nodes are problematic and should be avoided
  wherever possible in the large majority of
  situations. Defined semantics and specifications
  regarding Bnodes are inconsistent and
  contradictory leading to inconsistency between
  tools, ambiguity in how they will be processed,
  interpreted or queried.


  
http://richard.cyganiak.de/blog/2011/03/blank-nodes-considered-harmful/
https://aidanhogan.com/docs/blank_nodes_jws.pdf
https://marceloarenas.cl/publications/iswc11.pdf
https://terminusdb.com/blog/blank-nodes-in-rdf/
https://terminusdb.com/blog/blank-nodes-in-rdf/
  


  
When blank nodes are
used it is typically for the convenience of the
producer but often comes at significant cost to
the consumer in the form of ambiguity,
uncertainty, complexity, and resources (time and
computing resources)
IF
they are decided to be used they are
ONLY for a single scope of a single
datastore or single serialized document and
NOT for global or cross-scope use. This
is explicitly stated in all of the W3C specs
dealing with Bnodes. Using them for cross-scope
use as SPDX 3.0 is intended leads to significant